This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Bugzilla: Version = unspecified vs. trunk?


> Does filling against 2.15.90 mean that you tested it on ~trunk?

It should.

> Do we keep 2.15.90 around once 2.16 is released?

No, we don't want multiple unreleased versions going in bugzilla.

I think we should have a protocol whereby 2.xx.90 bugs get some
standard treatment en masse that requires that someone retest them
against the new release and either update to the release version or
close them.  If nobody retests a bug, it gets put into some clear
state indicating that (perhaps closed but with a special keyword).

The way bugzilla deals with deleting versions (I think) is to delete all
the bugs that still have that version.  So that says either we need to
change the version fields en masse, or else actually use something
unchanging like "trunk".

Off hand, my inclination is to say that we should just use a single one
called "trunk", just to avoid the weirdness of old bugs having a version
field that no longer exists so that we have to change it to something
ahistorical to avoid them being deleted.  But we don't want old trunk bugs
to sit around in indeterminate states once the release exists.  So in any
event we need a thorough protocol by which trunk bugs get changed en masse
in some formulaic way when the new release exists.

I guess another way to slice it is to create the new version field
immediately, and use that for all the trunk bugs before the release.
That way the default bit-rot state is an open bug for the new release,
even if the bug never occurred at any point on that release branch.

> I'm looking for a way to review bugs submitted by developers, and
> answer questions like "Before we release 2.16 what high priority bugs
> do we still have open?"

Actual developers can be expected to maintain some discipline with bugzilla
fields, and set the milestone on any bug they file unless they really don't
care when in the future it gets attention.

For casual contributors or testers reporting bugs on the trunk, those bugs
need triage just like end-user bugs for release versions do.  So triagers
can be expected to set milestones according to some protocol if we specify
it clearly.


Thanks,
Roland


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]