Public SourceMage Discussion List

[Bor Kraljič <pyrobor AT ver.si>]

On 25. of Oct 2011 12:34:20 David Kowis <dkowis AT shlrm.org> wrote:
> 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)
That would be ideal. But perhaps we could set some kind of expiration time. 
If 
we resolve it and don't get feed back from reporter for 1 (or 3) months we 
should just mark it as closed.

> > * 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.

The problem I see is that that would be job of grimoire lead. As he should 
decide what bugs need to be fixed. However our grimoire lead seems to be very 
busy in real life...
Or someone else could be in charge of bugs? Does Chili project maybe have a 
some kind of voting system for issues or features?

> 
> 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.

I agree that your suggestions is better. But anything is better than nothing.