[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: bodhi 0.4.10 features

On 29/01/2008, Alex Lancaster <alexl users sourceforge net> wrote:
> >>>>> "CB" == Christopher Brown  writes:
> [...]
> >> I also agree.  It seems like overkill and increases the bug load
> >> unless there are tools as suggested above.  Sometimes a bug is
> >> reported in F-7 but fixed in F-8 and there is nobody who can
> >> investigate whether the F-8 fix works in F-7.  Is it really
> >> necessary to create a new bug just for that purpose?  It's seems
> >> better to move the bug to F-8, and push a new update for both
> >> branches.  If it doesn't fix things in the F-7 branch somebody will
> >> re-open the bug.  No big deal.
> CB> Actually it can be. Once a bug gets more than two or three people
> CB> commenting and supplying feedback, things get awfully complicated
> CB> and you end up in a situation where no-one knows what version
> CB> someone is running and it becomes time-consuming to track back
> CB> over closed bugs to review who is running what.
> [...]
> Agreed there are certainly many situations where you need to clone the
> bug and have separate bugs for each branch, especially, as you note
> for kernel bugs.  I was simply arguing that it shouldn't be an
> absolute hard requirement to create a new bug in every instance when a
> bug is fixed in more than one branch.

You are right. Splitting bugs in the first instance into three
(7,8,rawhide) serves no purpose as we are not sure that all three
versions have the bug. We cannot expect reporters or even maintainers
to test against all versions either. Basically,

Duplicating bugs into all three version - bad
Closing of same version dupes - good
Closing of different version dupes - discretion of maintainer/triager

This is what I would like to see and what I have up until now been doing.


Christopher Brown


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]