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?


On Thu, Mar 15, 2012 at 10:35 AM, Andreas Jaeger <aj@suse.com> wrote:
>> I could see a couple of use cases:
>>
>> * User forgets to set version, and default is "unspecified."
>>
>> * User is filling a bug for someone else and they don't know the
>> version (yet) so they use "unspecified."
>>
>> * User consciously sets version to "trunk" to indicate they used the
>> tip of master on the day the bug was filed.
>
> I see the risk that this might not be the day the bug was filled and the
> developer checking the bug might not check the day the bug was filed...
>
> What about adding 2.15.90? That what's in version.h.

I like that idea.

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

Do we keep 2.15.90 around once 2.16 is released?

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?"

The first answer is "Anything that is not fixed and has target
milestone 2.16 should be reviewed."

However, that requires having set the milestone.

To set the milestone you have to have made either a blanket query of
new-ish bugs, or have had help from users to track down "What bugs did
we find during development?"

Giving the users a chance to say "This is broken on trunk" is helpful
because it's the first place you go to look before making the release.

Does that make sense?

Cheers,
Carlos.


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