bodhi 0.4.10 features

[Christopher Brown]

On 28/01/2008, Alex Lancaster <alexl at users.sourceforge.net> wrote:
> >>>>> "DM" == Dominik 'Rathann' Mierzejewski  writes:
>
> [...]
>
> >>>> Do you want to force the reporter/maintainer to "clone" the bug
> >>>> for different branch?
>
> >>> Yep.  I just came up with a catchy slogan for this: "the rule of
> >>> ones" (OK, maybe not so catchy :) ).  ONE bug == ONE problem in
> >>> ONE release (F7, F8, and rawhide).  It's even got a big red box in
> >>> http://fedoraproject.org/wiki/JohnPoelstra/BugLifeCycle :)
>
> >> I strongly disagree. It just increases the number of bugs and has
> >> almost no benefit.
>
> DM> +1. One bug for one issue (even if it exists in more than one
> DM> release) is quite sufficient. And helps to keep the buglist
> DM> short.
>
> DM> OTOH, if you want us (the package maintainers) to follow the rule
> DM> of ones, please provide easy tools to do that. For example: one
> DM> click "clone for release X" button and the ability to sort the
> DM> bugs on bugzilla frontpage by Fedora release.
>
> DM> I'm sure there are more ways to make this easier. Otherwise I
> DM> strongly object to this unannounced change in bodhi behaviour.
>
> 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.

Actually it can be. Once a bug gets more than two or three people
commenting and supplying feedback, things get awfully complicated and
you end up in a situation where no-one knows what version someone is
running and it becomes time-consuming to track back over closed bugs
to review who is running what.

Take the kernel for example. The Fedora 7, 8 and rawhide kernels carry
differing patchsets and frequently the choice in point release
upgrades is to move latest release, then previous release. How can one
bug really be relevant to just one kernel? Do we make an exception for
major projects like OpenOffice, Firefox, kernel etc?

There are key arguments for both but although initially I leaned
towards a single bug report across all versions, the case for separate
bugs per version makes more sense in the long run as feedback from the
reporter is clearer.

Also consider that current policy indicates the bug with the most
information wins. This will often be the older version (e.g. F7).
However does the maintainer then attempt to resolve against the F8
version or F7?

Essentially this has been thought through with some care by the triage
team and I would recommend that this is the policy that is put into
place.

-- 
Christopher Brown

http://www.chruz.com