Fate of our tracker bugs

Andrea Musuruane musuruan at gmail.com
Sat Jan 17 09:56:35 CET 2009


On Fri, Jan 16, 2009 at 7:42 PM, Orcan Ogetbil <oget.fedora at gmail.com> wrote:
> I was doing some bugzilla cleanup today. At some point Thorsten warned
> me about removing the blocker #4 from accepted bugs.
> Currently the guidelines state that:
> "Once package built successfuly, go back to your bug review and add a
> comment to the review to notify
> the import and build have been done correctly, remove the blocker on
> RF_ACCEPT and close the bug as RESOLVED FIXED. "
>
> where RF_ACCEPT=4
>
> This raises the question. What do we need bug#4 for? Only for those
> packages that are to be imported to CVS? This guideline needs changed
> if we want to keep track of the review requests for the packages that
> are in our repo. I don't think being able to keep track of them is a
> bad idea.

The first draft of this workflow was written before our infrastructure
was completed and it comes mainly from the one we used in Dribble:
http://www.dribble.org.uk/documentation.html

There, the purpose of DRB_ACCEPT was to gain the attention of Dribble
admin to push the package through the build system. As a matter of
fact, Dribble didn't have a public repository and all the packages had
to be built by the admin.

After sometime, we introduced the tracker bug RF_CVSsync to gain the
attention of a CVS admin to create a branch.

Therefore it seems that RF_ACCEPT hasn't got a clear meaning right now.

> What do you think? Shall we keep our review bugs block #4 for good?
> Another question is, what about obsolete packages? Afaik we don't have
> any obsolete package yet, but in the future, should an obsolete
> package block #4 or some other tracker bug?

Fedora has fedora-review flags to track review status and therefore
approved packages. If we could use the same system it would be better.
Otherwise, I think we could use RF_ACCEPT to track approved packages.

Other opinions always welcome :)

Bye,

Andrea.


More information about the rpmfusion-developers mailing list