6:42 p.m.
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.
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?
-Orcan
8:56 a.m.
On Fri, Jan 16, 2009 at 7:42 PM, Orcan Ogetbil <oget.fedora(a)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.
7:05 p.m.
On 17.01.2009 09:56, Andrea Musuruane wrote:
On Fri, Jan 16, 2009 at 7:42 PM, Orcan Ogetbil
<oget.fedora(a)gmail.com> wrote:
[...]
Fedora has fedora-review flags to track review status and therefore
approved packages. If we could use the same system it would be better.
Well, that's something some bugzilla hacker in RH coded up iirc. I don#t
think that's worth porting and maintenance work, as the benefits are small.
Otherwise, I think we could use RF_ACCEPT to track approved packages.
+1 -- But that was likely obvious from what oget already said ;-)
CU
knurd
5:02 a.m.
On Sun, Jan 18, 2009 at 2:05 PM, Thorsten Leemhuis wrote:
On 17.01.2009 09:56, Andrea Musuruane wrote:
>
> On Fri, Jan 16, 2009 at 7:42 PM, Orcan Ogetbil wrote:
> [...]
> Fedora has fedora-review flags to track review status and therefore
> approved packages. If we could use the same system it would be better.
Well, that's something some bugzilla hacker in RH coded up iirc. I don#t
think that's worth porting and maintenance work, as the benefits are small.
> Otherwise, I think we could use RF_ACCEPT to track approved packages.
+1 -- But that was likely obvious from what oget already said ;-)
CU
knurd
So... Is there any objection from anyone to the idea of keeping all
our closed review requests to block RF_ACCEPT?
Can anyone think of a case where this will cause trouble in the future?
If not, can we change the guideline accordingly?
Best,
-oget
4:58 a.m.
Orcan Ogetbil wrote:
So... Is there any objection from anyone to the idea of keeping all
our closed review requests to block RF_ACCEPT?
Can anyone think of a case where this will cause trouble in the future?
I would prefer them to stay easily searchable as a "have been reviewed"
by checking RF_ACCEPT.
The only issue I can forsee is the future once RPM Fusion has 5000
accepted packages ;-) would that make such a bugzilla query unusable ?
DaveT.
12:41 p.m.
On 24.01.2009 05:58, David Timms wrote:
Orcan Ogetbil wrote:
> So... Is there any objection from anyone to the idea of keeping all
> our closed review requests to block RF_ACCEPT?
> Can anyone think of a case where this will cause trouble in the future?
I would prefer them to stay easily searchable as a "have been reviewed"
by checking RF_ACCEPT.
Seems the idea is widely accepted, so I just changed the wiki and
removed the "[...]remove the blocker on `RF_ACCEPT` and[...]" part (
http://rpmfusion.org/Contributors?action=diff&rev2=25&rev1=24 ).
The only issue I can forsee is the future once RPM Fusion has 5000
accepted packages ;-) would that make such a bugzilla query unusable ?
We'll see ;-)
Cu
knurd
5570
days inactive
5578
days old
rpmfusion-developers@lists.rpmfusion.org
5 comments
4 participants
participants (4)
-
Agnes Jones -
Andrea Musuruane -
Orcan Ogetbil -
Thorsten Leemhuis