Removinig CVS/GIT version from bugzilla

[Vitaliy Margolen]

I'm copying my response here to continue the conversation.

Please don't remove cvs/git version.

What should be done is:
1. Leave old bugs alone or modify them case-by-case
2. All bugs with "cvs/git" version from now on can be filed on the 
development branch between releases only.
3. After the next release, if the bug is still present, modify version to 
that release. Of course no modifying of old bugs.


Vitaliy.

[Scott Ritchie]

Vitaliy Margolen wrote:
> 3. After the next release, if the bug is still present, modify version to 
> that release. Of course no modifying of old bugs.

Sounds like a simple addition to Alexandre's (scripted?) closing of all
fixed bugs on release day.

Thanks,
Scott Ritchie

[Maarten Lankhorst]

Hello Scott,

2008/4/22 Scott Ritchie <scott(a)open-vote.org>:
> Vitaliy Margolen wrote:
> > 3. After the next release, if the bug is still present, modify version to
> > that release. Of course no modifying of old bugs.
>
> Sounds like a simple addition to Alexandre's (scripted?) closing of all
>  fixed bugs on release day.
> I don't think that is needed, all that is needed is to rename git to
> wine-0.9.XX and and then create a new git tag.

Cheers,
Maarten.

[Vitaliy Margolen]

Maarten Lankhorst wrote:
> Hello Scott,
>
> 2008/4/22 Scott Ritchie <scott(a)open-vote.org>:
> > Vitaliy Margolen wrote:
> > > 3. After the next release, if the bug is still present, modify version to
> > > that release. Of course no modifying of old bugs.
> >
> > Sounds like a simple addition to Alexandre's (scripted?) closing of all
> >  fixed bugs on release day.
> > I don't think that is needed, all that is needed is to rename git to
> > wine-0.9.XX and and then create a new git tag.

Well that will affect closed bugs - which is not good. However I don't have 
a strong objection here - whatever works. It would be even better if we can 
add the version automatically with release scripts.

Vitaliy.

[Maarten Lankhorst]

Hello Vitaily,

2008/4/22 Vitaliy Margolen <wine-devel(a)kievinfo.com>:
> Maarten Lankhorst wrote:
> > Hello Scott,
> >
> > 2008/4/22 Scott Ritchie <scott(a)open-vote.org>:
> > > Vitaliy Margolen wrote:
> > > > 3. After the next release, if the bug is still present, modify version to
> > > > that release. Of course no modifying of old bugs.
> > >
> > > Sounds like a simple addition to Alexandre's (scripted?) closing of all
> > >  fixed bugs on release day.
> > > I don't think that is needed, all that is needed is to rename git to
> > > wine-0.9.XX and and then create a new git tag.
>
> Well that will affect closed bugs - which is not good. However I don't have
>  a strong objection here - whatever works. It would be even better if we can
>  add the version automatically with release scripts.

If it is a true rename operation it will. However this will only occur
once so I think we can live with that. Any bugzilla admins ok with
this way of doing bug reports? It would make the version a whole lot
more accurate in the longer run.

Cheers,
Maarten.

[Jan Zerebecki]

On Wed, Apr 23, 2008 at 12:58:44AM -0700, Maarten Lankhorst wrote:
> 2008/4/22 Vitaliy Margolen <wine-devel(a)kievinfo.com>:
> > Well that will affect closed bugs - which is not good. However I don't have
> >  a strong objection here - whatever works. It would be even better if we can
> >  add the version automatically with release scripts.

Yea adding it's version on release by the scripts would be nice. The
scripts are in one of the git repos on winehq...
> If it is a true rename operation it will. However this will only occur
> once so I think we can live with that. Any bugzilla admins ok with
> this way of doing bug reports? It would make the version a whole lot
> more accurate in the longer run.

Yes versions can be renamed and any bugs that reference them then show
the new name of the version without beeing modified.

We could rename "CVS/GIT" to pre-1.0-git/cvs (or whatever the next
release is). And then for each release e.g. for 1.0.12 we would have
1.0.12 and post-1.0.12-git (for anything that occurs and is fixed before
the release after that).


Jan