rawhide bugs becoming F-9 bugs

[Patrice Dumas]

On Thu, May 15, 2008 at 03:11:30AM -0700, Andrew Farris wrote:
> Patrice Dumas wrote:
>> On Wed, May 14, 2008 at 08:37:23PM -0700, Andrew Farris wrote:
>>> There were MANY duplicate bugs and some new bugs filed against rawhide 
>>> which are F9 bugs in the last week before release... doing that change 
>>
>> But aren't they rawhide bugs too?
>
> Maybe, maybe not.
>
>> It is much better to have those bugs
>> opened against the latest version of fedora, having to go through
>> bugzilla just to say "hey, don't close my bug" as unfrequently as
>> possible seems better to me.
>
> Sure that makes sense in the short term, but how/when do you change them?  
> Thats  precisely the problem (not ever changing rawhide bugs to a release 
> version) which resulted in several year old bugs being open against 
> 'rawhide' for code that will never be touched again.  Searching 'rawhide' 
> bugs is much less useful when its that cluttered... and thats very bad for 
> testers trying not to report duplicate bugs.

You are misunderstanding what I say, I am not against changing from
rawhide to a release, for the reason you state, that rawhide is a moving
target. But I think that it is better to make a mistake by filling a bug 
against a more recent version than against an old version, because in
case of an old version, the packager will have to move his bug one more
time when the release becomes EOL. So to avoid having time lost in
changing releases it is better to make mistake in the direction of the
next release than in the direction of past releases, and I explained in
the remaining of my mail why it was much more likely that a bug filed in
the time of uncertainy between release and rawhide it is likely that
rawhide is right.

> So the question is, if not NOW at release, then when should those open bugs 
> be changed to a release version?  How much harder would it be to do later 
> than it is now?

As I said before, I think that the right time is when a rawhide branch is 
created in CVS, and not at release time.

--
Pat