Public SourceMage Discussion List

[David Kowis <dkowis AT shlrm.org>]

On 10/25/2011 04:36 AM, Bor Kraljič wrote:
> Hi!
> 
> At this moment we don't have common work-flow of repairing bugs (at least 
> not 
> that I am aware of). Some developers mark bugs as "In progress" [1] when 
> bug 
> is already fixed in test. I mark it as "Resolved" when it is fixed in test 
> [2]. 
> Some of bugs are even closed [3]. 
> 
> My suggestions are:
> 
> BUG STATUS:
> * NEW: All bugs that are not fixed and nobody is working on it.
> * IN PROGRESS: We should use this status if you are working on a fix but 
> you 
> haven't fix it yet. 
> * RESOLVED:  Such status should have bugs that are already fixed in test 
> grimoire but NOT in stable.

I would add FEEDBACK to ensure that the bug is actually fixed. It's
possible that we can skip this in simple version bump updates, but I
think it would be good to get in the habit of having the reporter (or
someone) confirm that the bug is actually fixed. (To avoid "it works on
my box" type issues)

> * CLOSED: If bug is fixed in all grimoires. (stable and test). Developer 
> must 
> check if the bug affects stable grimoire before closing. Even if the bug 
> was 
> reported in test grimoire. 
> 
> ASSIGNEE:
> I'm not really fan of this. Because it is some kind of forcing and we are 
> group of volunteers. But if someone breaks something I think it is 
> reasonable 
> to expect that he will fix that.
> But you can always assign bug to yourself if you plan to work on it :)

Yeah, I think that's good. Assign it to yourself if you're going to work
on it. Of course, whatever the team decides is the best way to do it.

> 
> ROADMAP:
> This is pretty cool feature. But it needs to be used properly. We now have 
> roadmap for stable grimoire 0.60. But stable-0.60 was already released... 
> Not 
> really logical. So I think we should have roadmap for 0.60-1. But this is 
> just 
> a name and it can be easily changed.

Ideally the roadmap is for planning a release. A bit of time would need
to be spent putting bugs/features into a release and setting a date for
it. Then people would know what needs to be done for the next release.

For the grimoire, we've been doing a monthly release, because the
majority of the changes are simply version updates, or bug fixes to
rectify build problems.

I'd like to see a bit more planning regarding that, but I think it would
require splitting the grimoire into a core, supported one, and then the
other we're using for version bumps.

Keep the core grimoire with spells that only have the verifyable QA, and
any changes to those spells would require going through that Quality
Assurance process again, and would require sign offs to verify. And, as
we add more automated, or manual tests, we can add more spells to our
core grimoire, and get a rock solid grimoire. Then the planning would be
more valuable.

Having planned releases for things like version bumps feels like too
much work for little reward.

> 
> Now what bugs should be added to roadmap:
> * ALL RESOLVED bugs (based on previous definition) regardless what kind of 
> bug 
> it is [2].  Bug is a bug and if it affects stable it should be also fixed 
> in 
> stable.
> * NEW bugs. ONLY critical/high important bugs.
> 
> That way roadmap will only be a list of bugs for grimoire lead  (or 
> assistants) for integrating fixes into stable. And before releasing new 
> stable  
> ALL bugs on roadmap must be CLOSED! If any bugs  are not closed (new (we 
> hadn't have time to fix it) or resolved (if cherry-pick has conflicts...)) 
> should be moved to next target release.
> 
> This way we will use at least some functionality that is offered by 
> Chiliproject roadmap.

This is one way to do it, but it seems a backwards way of using the
roadmap to me. Instead of using the roadmap as a planning tool, we're
using it as a history. If this is what works best for the grimoire,
however, I'm all for it.

David

Attachment: signature.asc
Description: OpenPGP digital signature