Re: Suggestion for a new GNATS policy

Re: Suggestion for a new GNATS policy

[Volker Reichelt]

On 11 May, S. Bosscher wrote:
> Dan wrote:
>> On Sunday, May 11, 2003, at 04:30  PM, Volker Reichelt wrote:
>> > 1) The state "analyzed" does not help much, because the requirements 
>> > are too weak: It just means that somebody has looked at it and agrees
>> > that there's a bug in GCC. Very often not even the class of the PR is
>> > set correctly. Preprocessed files (especially for C++ bugs) are often 
>> > huge so that somebody who tries to fix a bug has to do major work 
>> > (which could be done by somebody else) before being able to tackle
>> > the core of the problem.
> 
> I agree.  For many PRs, "analyzed" now just means "yup, I see it, too",
> which is not what I call analysis :-)
> 
>> > So IMHO we need some stricter requirements for reports in state 
>> > "analyzed". Knowing that any analyzed PR is in the right class and
>> > has a simple testcase attached and a suitable synopsis line would 
>> > help the bug fixers to do their work efficiently.
> 
> We should have a "confirmed" state, which would mean that somebody with GCC
> PR DB write access can reproduce the bug (possibly after receiving
> feedback).  "analyzed" should mean that at least the category is set and
> that a reduced test case is available.
> 
>> Analyzed does not exist in Bugzilla (analyzed becomes "ASSIGNED"
>> if assigned to someone, "NEW" otherwise).
> 
> Aieee, please no.  There are so many analyzed PRs that are
> unassigned, so what you say here would only make things harder.

Me too: Aieee, please no!
We would lose a *lot* of valuable information and would force much more
work on the bug fixers, leaving the "bug report preprocessors" unemployed.

> We should have "NEW" for new and unconfirmed PRs and "CONFIRMED"
> for confirmed PRs.  PRs should have the "ANALYZED" status when
> somebody has zoomed in at the problem a bit closed.  PRs that are
> "analyzed" now should stay "ANALYZED" in bugzilla IMHO.
> 
> I don't know how many states you defined,  gcc.gnu.org/bugzilla
> used to work but now it fails...  (Does Bugzilla allow you to
> define your own states at all???)  But I suppose we should have
> "NEW", "FEEDBACK", "CONFIRMED", "ANALYZED", "ASSIGNED", "CLOSED",
> "REOPENED" (yes this happens), and "SUSPENDED".

I don't know if we really need REOPENED. A PR should go into "CONFIRMED"
or "ANALYZED" then, IMHO.

If we cannot get these states into bugzilla, we could make dummy
maintainers called "CONFIRMED" and "ANALYZED" etc. to whom we assign
the PRs, but that's only an ugly kludge.

> (Yes that's very much like what we have in GNATS now, but that's because
> GNATS is not so bad, really.  It just misses one or two states and its user
> interface is very poor.)
> 
>> > 2) To close the PRs that got fixed silently the PRs have to
>> > be revisited from time to time. But there should be some way
>> > to give the PR's a time stamp so that one can easily see
>> > (without having to read the whole audit-trail) when a PR
>> > should be revisited again.
> 
> There's also the "Last-Modified" field, what is wrong with that?

Because a new addition to the audit-trail doesn't mean that the
PR was really rechecked. Modified doesn't imply reconfirmed.

> Now all the synopses are being cluttered with date stamps, and
> that is IMHO just wrong.  The markers like [New parser], 
> [<some_target>], etc. are useful, because they make it so much
> easier to find related PRs real quick.  The date stamps don't
> do anything that can't be done with basic GNATS functionality,
> at least AFAICT.

I'd prefer shorter synopsis lines, too. So, if we can have a seperate
field for the date stamp in bugzilla, I'm in for it. But as long as we
don't have one the information should be stored in the synopsis line IMHO.

>> In most cases, there is no need. One just has to remember to
>> put the right thing in the CVS commit message, and it'll get
>> added to the PR as a comment.
> 
> It's not unusual for a PR to be fixed without anyone noticing.
> For 3.3, I closed some PRs that got fixed by some patch, but
> the CVS commit message didn't mention the PR (probably because
> nobody knew about the PR...) so the PR stayed open.  I think
> everybody has seen PRs like that.

Right. That's the reason for the time stamps.

>> You can easily query for bugs that haven't (or have) been
>> touched in x days in Bugzilla, so there is no need to put
>> timestamps on bugs and whatnot.
>
> You can do that with GNATS, too.  Just not very user friendly,
> it _can_ be done.

Once again: "touched" doesn't mean "reconfirmed".

> 
> Greetz
> Steven

Regards,
Volker

Re: Suggestion for a new GNATS policy

[Daniel Berlin]

>> Aieee, please no.  There are so many analyzed PRs that are
>> unassigned, so what you say here would only make things harder.
>
> Me too: Aieee, please no!
> We would lose a *lot* of valuable information and would force much more
> work on the bug fixers, leaving the "bug report preprocessors" 
> unemployed.
>

Use bug flags, not states.
The bug is still fundamentally the same state (around but unfixed), 
regardless of whether verified or the testcase is minimized.
They are boolean flags, not states.

> If we cannot get these states into bugzilla, we could make dummy

We don't *need* these states. You need to add a few boolean flags.

> maintainers called "CONFIRMED" and "ANALYZED" etc. to whom we assign
> the PRs, but that's only an ugly kludge.

>> (Yes that's very much like what we have in GNATS now, but that's 
>> because
>> GNATS is not so bad, really.  It just misses one or two states and 
>> its user
>> interface is very poor.)
>>
>>>> 2) To close the PRs that got fixed silently the PRs have to
>>>> be revisited from time to time. But there should be some way
>>>> to give the PR's a time stamp so that one can easily see
>>>> (without having to read the whole audit-trail) when a PR
>>>> should be revisited again.
>>
>> There's also the "Last-Modified" field, what is wrong with that?
>
> Because a new addition to the audit-trail doesn't mean that the
> PR was really rechecked. Modified doesn't imply reconfirmed.
>
Hence the need for a boolean flag.
I can have it auto-reset them every 30 days a bug isn't touched or 
something, if you like, as a cronjob.
There's still no need for a full timestamp, because it knows when the 
flag was changed anyway.
>>
>> You can do that with GNATS, too.  Just not very user friendly,
>> it _can_ be done.
>
> Once again: "touched" doesn't mean "reconfirmed".
>
I've already addressed this with a flag.

Re: Suggestion for a new GNATS policy

[Giovanni Bajo]

Daniel Berlin <dberlin@dberlin.org> wrote:

>> Because a new addition to the audit-trail doesn't mean that the
>> PR was really rechecked. Modified doesn't imply reconfirmed.
>>
> Hence the need for a boolean flag.
> I can have it auto-reset them every 30 days a bug isn't touched or
> something, if you like, as a cronjob.
> There's still no need for a full timestamp, because it knows when the
> flag was changed anyway.


It's not a boolean flag. Either a bug has been confirmed 2 day ago, 2 weeks
ago, 2 months ago or 2 years go, they're all different situations. Since
GNATS doesn't have a field for this, we're putting it into the synopsis. I
would not mind Bugzilla to have such a timestamp.

Giovanni Bajo

Re: Suggestion for a new GNATS policy

[Daniel Berlin]

On Sunday, May 11, 2003, at 10:03  PM, Giovanni Bajo wrote:

> Daniel Berlin <dberlin@dberlin.org> wrote:
>
>>> Because a new addition to the audit-trail doesn't mean that the
>>> PR was really rechecked. Modified doesn't imply reconfirmed.
>>>
>> Hence the need for a boolean flag.
>> I can have it auto-reset them every 30 days a bug isn't touched or
>> something, if you like, as a cronjob.
>> There's still no need for a full timestamp, because it knows when the
>> flag was changed anyway.
>
>
> It's not a boolean flag.

Yes it is. Reconfirmed is either true or false. There is no "kinda 
reconfirmed".
The time when something was reconfirmed is just extra info about *when* 
the state happened, not information stored in the state itself.
>  Either a bug has been confirmed 2 day ago, 2 weeks
> ago, 2 months ago or 2 years go, they're all different situations.

You've just missed the last sentence apparently, or aren't really 
thinking about it.
We know it was reconfirmed (a boolean, since it's only ever true or 
false that something has been reconfirmed)
Bugzilla knows *when* it was reconfirmed.

Thus you *have* a timestamp.
Just not one *you* need to explicitly fill in. You just set the flag or 
not. It records the timestamp on the change for you when you do.
You can query *when* the reconfirmed flag was set, or *whether* it is 
set.
This is what the flag allows you to do.
Hell, you can make the flag requestable if you want, so you can request 
that someone reconfirm the bug on your own.
It can auto-cc someone on requests, too.

>  Since
> GNATS doesn't have a field for this, we're putting it into the 
> synopsis.

Please put it somewhere else, since
1. It is as a temporary measure (since we are moving soon)
2. I can't remove it during conversion easily, and it'll uglify reading 
bug lists since some bugs have them, and others don't. Adding it to the 
front will also cause it to truncate some of the actual description.
Already we have crap like:
"[2003-05-03] [diagnostic] Bug in template type in error m..."

Showing up in queries.

Nobody can even tell what this is a bug about anymore.  The fact that 
it was confirmed 2003-05-03 doesn't help anybody, but the fact that 
[2003-05-03][diagnostic] takes up 33% of the summary line hurts 
everyone.

diagnostic should be a keyword (or component), but i can handle this in 
the converter easily.

I can't easily remove or convert the [2003-05-03] part, because other 
people have dates in summary lines for other reasons.




> I
> would not mind Bugzilla to have such a timestamp.
>

You already have one when you define the flag.


--Dan

Re: Suggestion for a new GNATS policy

[Giovanni Bajo]

Daniel Berlin <dberlin@dberlin.org> wrote:

>> It's not a boolean flag.

> Yes it is. Reconfirmed is either true or false. There is no "kinda
> reconfirmed". The time when something was reconfirmed is just extra info
about *when*
> the state happened, not information stored in the state itself.

The bug is confirmed in the moment it gets analyzed. So, with the new
bugzilla convention, whenever the bug switches to NEW it's already
implicitally "confirmed". I'm not sure what a different boolean flag would
be for.

> You've just missed the last sentence apparently, or aren't really
> thinking about it.

I don't usually reply without thinking. There might be exceptions of course.

> We know it was reconfirmed (a boolean, since it's only ever true or
> false that something has been reconfirmed)
> Bugzilla knows *when* it was reconfirmed.
>
> Thus you *have* a timestamp.
> Just not one *you* need to explicitly fill in. You just set the flag or
> not. It records the timestamp on the change for you when you do.
> You can query *when* the reconfirmed flag was set, or *whether* it is
> set.
> This is what the flag allows you to do.
> Hell, you can make the flag requestable if you want, so you can request
> that someone reconfirm the bug on your own.
> It can auto-cc someone on requests, too.

I'm doing my best to understand this, given that I'm unexperienced with
Bugzilla. But I still fail to see how I can update this flag to reflect a
new confirmation. In other words, it's not important when it was "first"
reconfirmed, but it's necessarry to check when it was "last" reconfirmed.
Because every single bug could get silently fixed meanwhile, so we need to
know when the bug was reconfirmed last time.

We confirm each bug many times, and every time we bump the date field. How
are we supposed to do this in Bugzilla? I'm not saying it cannot be done
with a flag, I just saying that the information we do care about is not
"reconfirmation true/false" but only "reconfirmation when (LAST time, not
FIRST time)".

Were you implying that we should remove the confirmation flag and re-set it
everytime we re-confirm a bug so that Bugzilla will log when the flag was
(last) set?

>>  Since GNATS doesn't have a field for this, we're putting it into the
>> synopsis.
>
> Please put it somewhere else, since
>
> 2. I can't remove it during conversion easily, and it'll uglify reading
> bug lists since some bugs have them, and others don't. Adding it to the
> front will also cause it to truncate some of the actual description.
> Already we have crap like:
> "[2003-05-03] [diagnostic] Bug in template type in error m..."
>
> Showing up in queries.

Queries should show the full synopsis. We have synopsyses which contain more
characters than the one you wrote here, even without any [....] stamp.
Otherwise, if the synopsys has to be like "ICE with templates", it's mostly
useless. An useful synopsis is "Even when used within typeid(), a
template-id generating an overload set with only one function should
silently decay to a pointer to function", and I was expecting Bugzilla to
show the whole synopsis after queries, just like GNATS do.

> Nobody can even tell what this is a bug about anymore.

This is because the synopsis is cut off, it's not because of the stamps.
GNATS does not have such a problem because the whole synopsis is always
shown.

> The fact that
> it was confirmed 2003-05-03 doesn't help anybody,

False, it's very important for us GNATS workers, because it means that it's
a bug which does not need further work for a long while. And it's important
for GCC developers because it says that it's a bug which is still actual in
late GCC versions (there are bugs which are open since 2 years or more, so
this is an important piece of information).

I'm not saying that this _must_ go into the synopsis. I'm saying that we
badly need to store, somewhere, the date when the bug was LAST reconfirmed
(as I explained previously).

> but the fact that
> [2003-05-03][diagnostic] takes up 33% of the summary line hurts
> everyone.

Again, it's 33% because it's cut off. It's not so important in GNATS right
now.

> diagnostic should be a keyword (or component), but i can handle this in
> the converter easily.
> I can't easily remove or convert the [2003-05-03] part, because other
> people have dates in summary lines for other reasons.


I will be more than happy to convert everything to a format that makes
transition to Bugzilla easier, once we understand how this information
should be stored in Bugzilla.

>> I
>> would not mind Bugzilla to have such a timestamp.
>
> You already have one when you define the flag.

Yup, but we need one that we can update anytime we want. And if we could do
that with a single mouse click, it would be even better.

Giovanni Bajo

Re: Suggestion for a new GNATS policy

[Daniel Berlin]

>
>> We know it was reconfirmed (a boolean, since it's only ever true or
>> false that something has been reconfirmed)
>> Bugzilla knows *when* it was reconfirmed.
>>
>> Thus you *have* a timestamp.
>> Just not one *you* need to explicitly fill in. You just set the flag 
>> or
>> not. It records the timestamp on the change for you when you do.
>> You can query *when* the reconfirmed flag was set, or *whether* it is
>> set.
>> This is what the flag allows you to do.
>> Hell, you can make the flag requestable if you want, so you can 
>> request
>> that someone reconfirm the bug on your own.
>> It can auto-cc someone on requests, too.
>
> I'm doing my best to understand this, given that I'm unexperienced with
> Bugzilla. But I still fail to see how I can update this flag to 
> reflect a
> new confirmation. In other words, it's not important when it was 
> "first"
> reconfirmed, but it's necessarry to check when it was "last" 
> reconfirmed.
It records *every* time the flag is set/unset, not just the first time.
I can make it easy to query the *last* time if that's your bag of tea, 
it's trivial.

> Because every single bug could get silently fixed meanwhile, so we 
> need to
> know when the bug was reconfirmed last time.

> We confirm each bug many times, and every time we bump the date field. 
> How
> are we supposed to do this in Bugzilla?


That's the easy (for me) way:
You can unset-reset the flag.
Then the bug activity looks like:
Who					When			    Removed	Added
root@danberlin.com  	2003-05-11 23:42  			Flag minimized+
root@danberlin.com		2003-05-11 23:42	Flag minimized+
root@danberlin.com 	2003-05-11 23:43 			Flag minimized+


>  I'm not saying it cannot be done
> with a flag, I just saying that the information we do care about is not
> "reconfirmation true/false" but only "reconfirmation when (LAST time, 
> not
> FIRST time)".

It records *every* time the flag was set, not just the first time.
It's trivial to query for all bugs where the flag has not been set in 
the past x days.
I just need to know *what* type of query you want to do on this flag, 
so i can make it appear on the query form for you (for your 
convenience, since you can constructs queries the hard way using the 
boolean charts).

>
> Were you implying that we should remove the confirmation flag and 
> re-set it
> everytime we re-confirm a bug so that Bugzilla will log when the flag 
> was
> (last) set?
It's easier (from my coding perspective) to do this, if this is a pain 
in the ass, i can come up with alternatives.

>
>>>  Since GNATS doesn't have a field for this, we're putting it into the
>>> synopsis.
>>
>> Please put it somewhere else, since
>>
>> 2. I can't remove it during conversion easily, and it'll uglify 
>> reading
>> bug lists since some bugs have them, and others don't. Adding it to 
>> the
>> front will also cause it to truncate some of the actual description.
>> Already we have crap like:
>> "[2003-05-03] [diagnostic] Bug in template type in error m..."
>>
>> Showing up in queries.
>
> Queries should show the full synopsis. We have synopsyses which 
> contain more
> characters than the one you wrote here, even without any [....] stamp.
> Otherwise, if the synopsys has to be like "ICE with templates", it's 
> mostly
> useless. An useful synopsis is "Even when used within typeid(), a
> template-id generating an overload set with only one function should
> silently decay to a pointer to function",

That's a useful *description*, not a useful *summary*.
The summary field is what is displayed on the bug lists by default.
The description field is display on the full bug display.
A useful summary of this bug would be "template-id not silently 
decaying to PTF" or something.
Who wants to read half a paragraph for each bug to determine if it's 
something they want to even click on to see more about?


>  and I was expecting Bugzilla to
> show the whole synopsis after queries, just like GNATS do.
I could make it do so, but we have some awfully long synopses.

>
>> Nobody can even tell what this is a bug about anymore.
>
> This is because the synopsis is cut off, it's not because of the 
> stamps.
> GNATS does not have such a problem because the whole synopsis is always
> shown.
I can do this trivially, but i haven't heard any complaints except from 
you (counting this as a complaint).

>
> I'm not saying that this _must_ go into the synopsis. I'm saying that 
> we
> badly need to store, somewhere, the date when the bug was LAST 
> reconfirmed
> (as I explained previously).
>
I realize this. I'm just stating i can't handle it automatically for 
you when it's there, because of collateral damage.

>
>> diagnostic should be a keyword (or component), but i can handle this 
>> in
>> the converter easily.
>> I can't easily remove or convert the [2003-05-03] part, because other
>> people have dates in summary lines for other reasons.
>
>
> I will be more than happy to convert everything to a format that makes
> transition to Bugzilla easier, once we understand how this information
> should be stored in Bugzilla.
>
>>> I
>>> would not mind Bugzilla to have such a timestamp.
>>
>> You already have one when you define the flag.
>
> Yup, but we need one that we can update anytime we want. And if we 
> could do
> that with a single mouse click, it would be even better.
as i said, 6 mouse clicks.

If this is too many, it makes more sense to modify the template 
displaying the editing form for you guys, that has buttons or 
checkboxes to make these changes.
They'd only display for people in a certain group (I'm at a lost what 
to call you guys as a group. "Bugmasters"?), so it wouldn't clutter it 
for developers bug editing.

To make it concrete:
go to http://dberlin.org/bugzilla/show_bug.cgi?id=10734

I can make a radio button labeled "Reconfirm" (right under "Leave as 
NEW") for you  guys if you want, so it's just "select reconfirm, click 
commit".


>
> Giovanni Bajo
>

Re: Suggestion for a new GNATS policy

[Christian Ehrhardt]

On Mon, May 12, 2003 at 12:16:06AM -0400, Daniel Berlin wrote:
> >We confirm each bug many times, and every time we bump the date field. 
> >How
> >are we supposed to do this in Bugzilla?
> 
> 
> That's the easy (for me) way:
> You can unset-reset the flag.

How am I supposed to store the fact that I reconfirmed a bug with a
two day old cvs-Snapshot? Also unsetting and resetting a flag
to achieve this is just plain ugly. This information is just fundamentally
NOT a flag. Actually it is not even a timestamp of some bugzilla action,
it is the date of a CVS-Snapshot. And it is IMHO much less
important to be able to compare these fields, they are mainly there
for human inspection.

> It records *every* time the flag was set, not just the first time.
> It's trivial to query for all bugs where the flag has not been set in 
> the past x days.

Again, if we can query for the field in questions, that's nice, but
its much more important IMHO that this information is visible in the
result of a query.

> I just need to know *what* type of query you want to do on this flag, 
> so i can make it appear on the query form for you (for your 
> convenience, since you can constructs queries the hard way using the 
> boolean charts).

Being able to do text queries would suffice. The imporant thing is, that
this information is visible in the result of a query.

> >>Please put it somewhere else, since
> >>
> >>2. I can't remove it during conversion easily, and it'll uglify 
> >>reading
> >>bug lists since some bugs have them, and others don't. Adding it to 
> >>the
> >>front will also cause it to truncate some of the actual description.
> >>Already we have crap like:
> >>"[2003-05-03] [diagnostic] Bug in template type in error m..."
> >>
> >>Showing up in queries.

That's exactly why we put it into the synopsis: It SHOULD show up in queries
at least if I request this when doing a query.
If conversion is a problem, I hereby volunteer to extract a list containing
PR number and desired contents of the "last-confirmed" field for all open
PRs at the time of the switch over to bugzilla. This way you'd only have
to feed this to an SQL-query once.

   regards  Christian

-- 
THAT'S ALL FOLKS!

Re: Suggestion for a new GNATS policy

[Daniel Berlin]

On Monday, May 12, 2003, at 06:59  AM, Christian Ehrhardt wrote:

> On Mon, May 12, 2003 at 12:16:06AM -0400, Daniel Berlin wrote:
>>> We confirm each bug many times, and every time we bump the date 
>>> field.
>>> How
>>> are we supposed to do this in Bugzilla?
>>
>>
>> That's the easy (for me) way:
>> You can unset-reset the flag.
>
> How am I supposed to store the fact that I reconfirmed a bug with a
> two day old cvs-Snapshot?

By putting it in the comments?

Developers only care the bug is still valid, remember.

>
>> It records *every* time the flag was set, not just the first time.
>> It's trivial to query for all bugs where the flag has not been set in
>> the past x days.
>
> Again, if we can query for the field in questions, that's nice, but
> its much more important IMHO that this information is visible in the
> result of a query.

Add it to your default visible query result columns.

>
>> I just need to know *what* type of query you want to do on this flag,
>> so i can make it appear on the query form for you (for your
>> convenience, since you can constructs queries the hard way using the
>> boolean charts).
>
> Being able to do text queries would suffice. The imporant thing is, 
> that
> this information is visible in the result of a query.
This is something *you* control, not me.

> That's exactly why we put it into the synopsis: It SHOULD show up in 
> queries
> at least if I request this when doing a query.
> If conversion is a problem, I hereby volunteer to extract a list 
> containing
> PR number and desired contents of the "last-confirmed" field for all 
> open
> PRs at the time of the switch over to bugzilla. This way you'd only 
> have
> to feed this to an SQL-query once.
>
>    regards  Christian
>
> -- 
> THAT'S ALL FOLKS!

Re: Suggestion for a new GNATS policy

[Daniel Berlin]

On Monday, May 12, 2003, at 06:59  AM, Christian Ehrhardt wrote:

> On Mon, May 12, 2003 at 12:16:06AM -0400, Daniel Berlin wrote:
>>> We confirm each bug many times, and every time we bump the date 
>>> field.
>>> How
>>> are we supposed to do this in Bugzilla?
>>
>>
>> That's the easy (for me) way:
>> You can unset-reset the flag.
>
> How am I supposed to store the fact that I reconfirmed a bug with a
> two day old cvs-Snapshot? Also unsetting and resetting a flag
> to achieve this is just plain ugly. This information is just 
> fundamentally
> NOT a flag. Actually it is not even a timestamp of some bugzilla 
> action,
> it is the date of a CVS-Snapshot.

BTW, this is not what i was told at the beginning.
I was told it was simply a timestamp of when the bug was last 
confirmed, not the date of the version it was CVS snapshot it was last 
confirmed with.
These are two very different things.  In fact, it's not even a 
timestamp in the second case, it's a date-only field (IE no 
hour:minute:secs)
Can someone please clarify which is correct?

If it's the second, you'll need a new field, i'll add one and make it 
visible only to bug triagers.

You still do *not* need a new field for representing things like "this 
bug has a minimized testcase", however.


--Dan

Re: Suggestion for a new GNATS policy

[Wolfgang Bangerth]

About the reconfirmed thing:
- Basically, "reconfirmed" is a list of dates of snapshots.
- I'd say everybody agrees that a good approximation to this is a list of 
  dates at which it was reconfirmed: we may use snapshots that are a 
  couple of days old, but not more. So let's make it simpler and take the
  date/time of reconfirmation, since bugzilla can determine that by 
  itself.
- Just as much, nobody really cares about previous dates, so it would be
  ok to just store the last time something was reconfirmed

Why a separate field (and why we store it in the symposis at present):
- it needs to be visible (see below why); the audit trail is not, at least
  not in queries
- reconfirming should be simple; bumping a date was considered simpler 
  than sending an email
- by point 3 above, nobody cares about previous reconfirmations, so we'd 
  like not to clutter the audit trails with pages of reconfirmations.

Given the last point, I would very much dislike reconfirming a bug by 
clearing-resetting the flag, since that would add _two_ more (and above 
that: useless) entries to the audit trail.

My optimal solution would be a button "Reconfirmed" that I could click,
that bumps the date of a respective (queryable) field, and that otherwise
leaves no mark in what I will usually see when I look at the audit trail.


> Developers only care the bug is still valid, remember.

That's too simple, Dan. We are talking about different communities, and 
the community that spends the most time with GNATS/bugzilla are what you 
termed bugmasters. I tend to think they do valuable work and it would be 
unfair to neglect their needs. The "reconfirmed date" information is 
clearly important to them (otherwise we wouldn't go to such length to put 
it into the synposis of _every single_ C++ report), so please don't make 
it harder than necessary.

W.

-------------------------------------------------------------------------
Wolfgang Bangerth              email:            bangerth@ices.utexas.edu
                               www: http://www.ices.utexas.edu/~bangerth/

Re: Suggestion for a new GNATS policy

[Wolfgang Bangerth]

> That's the easy (for me) way:
> You can unset-reset the flag.
> Then the bug activity looks like:
> Who					When			    Removed	Added
> root@danberlin.com  	2003-05-11 23:42  			Flag minimized+
> root@danberlin.com		2003-05-11 23:42	Flag minimized+
> root@danberlin.com 	2003-05-11 23:43 			Flag minimized+

That's gross.


> I just need to know *what* type of query you want to do on this flag, 
> so i can make it appear on the query form for you

Two types of queries:
- never (re)confirmed
- not reconfirmed in last X days

Sorting by the last reconfirmation date would be fine, but if we don't 
have it, nobody will bother either.


> That's a useful *description*, not a useful *summary*.
> The summary field is what is displayed on the bug lists by default.
> The description field is display on the full bug display.
> A useful summary of this bug would be "template-id not silently 
> decaying to PTF" or something.
> Who wants to read half a paragraph for each bug to determine if it's 
> something they want to even click on to see more about?

Having looked at probably >1000 reports, the conclusion is: there's no 
short summary in most cases (believe me). "ICE with templates" is short 
but useless.

Truncating the summary line is really bad, since if there is no short 
summary, a truncated one is just as good as none at all.

> > This is because the synopsis is cut off, it's not because of the
> > stamps. GNATS does not have such a problem because the whole synopsis
> > is always shown.
> I can do this trivially, but i haven't heard any complaints except from 
> you (counting this as a complaint).

Here's #2.


> go to http://dberlin.org/bugzilla/show_bug.cgi?id=10734
> 
> I can make a radio button labeled "Reconfirm" (right under "Leave as 
> NEW") for you  guys if you want, so it's just "select reconfirm, click 
> commit".

That's cool. I also like the "minimized" and "verified" flags (which 
indeed are really boolean flags).

Thanks for you work and responsiveness on all this, Daniel!

W.

-------------------------------------------------------------------------
Wolfgang Bangerth              email:            bangerth@ices.utexas.edu
                               www: http://www.ices.utexas.edu/~bangerth/

Re: Suggestion for a new GNATS policy

[Wolfgang Bangerth]

> >  Since GNATS doesn't have a field for this, we're putting it into the
> > synopsis.
> 
> Please put it somewhere else, since
> 1. It is as a temporary measure (since we are moving soon)
> 2. I can't remove it during conversion easily, and it'll uglify reading 
> bug lists since some bugs have them, and others don't. Adding it to the 
> front will also cause it to truncate some of the actual description.
> Already we have crap like:
> "[2003-05-03] [diagnostic] Bug in template type in error m..."

I don't think we're changing our policies here -- this has been the result
of deliberate thinking. The need for [DATE] has been explained previoulsy, 
the fact that some bugs have and some don't have it just reflects whether 
someone has recently reconfirmed it. At least in the C++ category, if a 
bug doesn't have it, it will soon have it as we go through all of them.

Christian (or Volker) has proposed a way to transfer the information, so I 
guess we should keep with our habit here.


> Nobody can even tell what this is a bug about anymore.  The fact that 
> it was confirmed 2003-05-03 doesn't help anybody, but the fact that 
> [2003-05-03][diagnostic] takes up 33% of the summary line hurts 
> everyone.

I think that's wrong. I don't know how developers pick bugs they are going 
to fix, but I guess its by either
- looking at the list of regressions
- checking for a certain keyword in the synopsis ("friend", "typeof")
In any case, developers certainly spend less time in the bug database than 
"bugmasters". So by cluttering up the synopsis, we'd mainly hurt 
ourselves. I don't have the feeling we do.

This is all moot, though, I think we've already agreed that the [DATE] and 
[... regression] tags will go from the synopsis into fields of their own. 
I just made the point to stress again that we are talking about different 
communities and that for the bug database "developers" are probably not 
the main target.

W.

-------------------------------------------------------------------------
Wolfgang Bangerth              email:            bangerth@ices.utexas.edu
                               www: http://www.ices.utexas.edu/~bangerth/

Re: Suggestion for a new GNATS policy

[Christian Ehrhardt]

On Mon, May 12, 2003 at 09:53:31AM -0400, Daniel Berlin wrote:
> >How am I supposed to store the fact that I reconfirmed a bug with a
> >two day old cvs-Snapshot? Also unsetting and resetting a flag
> >to achieve this is just plain ugly. This information is just 
> >fundamentally
> >NOT a flag. Actually it is not even a timestamp of some bugzilla 
> >action,
> >it is the date of a CVS-Snapshot.
> 
> BTW, this is not what i was told at the beginning.
> I was told it was simply a timestamp of when the bug was last 
> confirmed, not the date of the version it was CVS snapshot it was last 
> confirmed with.

I agree that this wasn't perfectly clear from the discussion.

> These are two very different things.  In fact, it's not even a 
> timestamp in the second case, it's a date-only field (IE no 
> hour:minute:secs)
> Can someone please clarify which is correct?

I can't speak for others but hours, minutes and seconds are most
definitely irrelevant wrt. the "last confirmed"-field. Also it just
isn't useful to say, "I reconfirmed this at this date" unless the
date implies something about the snapshot/version used to reconfirm
the bug, hence we can use and IMHO should use the date of the snapshot in
the first place.

> If it's the second, you'll need a new field, i'll add one and make it 
> visible only to bug triagers.

That's all I'm asking for.

> You still do *not* need a new field for representing things like "this 
> bug has a minimized testcase", however.

I very much like the idea of having a boolean flag for this! Time will
show what other flags we might actually need. The main objections that people
currently have against encoding these as flags as far as I can see is,
that some of the information that is supposed to be in these flags is
now encoded in PR states and that this information would be lost during
conversion. This is unfortunate but not really a reason to continue
encoding boolean information in the states.

Side note: Is there an easy way to have tri-states instead of booleans?
The three states would be
* yes (has small testcase)
* no (needs small testcase)
* inappropriate (doesn't need small testcase (e.g. typos in comments))

If there isn't we should probably document what should be done with
flags if the flag is inappropriate for a certain bug.

    regards   Christian

-- 
THAT'S ALL FOLKS!

Re: Suggestion for a new GNATS policy

[Wolfgang Bangerth]

> I can't speak for others but hours, minutes and seconds are most
> definitely irrelevant wrt. the "last confirmed"-field. Also it just
> isn't useful to say, "I reconfirmed this at this date" unless the
> date implies something about the snapshot/version used to reconfirm
> the bug, hence we can use and IMHO should use the date of the snapshot in
> the first place.

I think that for everyone who sets these dates, the date of the snapshot 
is at most a couple of days old. Since we're not really interested in 
accuracy to the second, we might just as well be a little lenient on the 
exact date of the snapshot.

Let's please make it more convenient and let bugzilla choose the present 
date. Otherwise, we're back to filling in numbers by hand, which I think 
is stupid. All we want to know is: did anybody confirm this bug in the 
last month or so.

W.

-------------------------------------------------------------------------
Wolfgang Bangerth              email:            bangerth@ices.utexas.edu
                               www: http://www.ices.utexas.edu/~bangerth/

Re: Suggestion for a new GNATS policy

[Steven Bosscher]

Op ma 12-05-2003, om 16:39 schreef Wolfgang Bangerth:
> > I can make a radio button labeled "Reconfirm" (right under "Leave as 
> > NEW") for you  guys if you want, so it's just "select reconfirm, click 
> > commit".
> 
> That's cool. I also like the "minimized" and "verified" flags (which 
> indeed are really boolean flags).
> 
> Thanks for you work and responsiveness on all this, Daniel!

Wild idea:

What I'd really like to see is a "minimized test case" field (which may
be a pointer to an attachment) and an SQL query to extract them all.  

That way, people could put DejaGNU-ified test cases in the bug database,
rip them all out with the query, and test them on their target.  Even if
only a few people would to that, we would know much sooner if/when a bug
got fixed unnoticed (ie. PR not in CVS commit msg.), and to which target
the bug applies.

The idea is that we really would like to be able to batch-test PR
reports.  Janis and Wolfgang have talked about a PR testsuite, and this
idea was mentioned again earlier in this thread, but we really don't
want to litter the test suite that much.  With an easy way to extract
all minimized test cases, you'd effectively have the same thing without
even touching the testsuite.

Thoughts?

Greetz
Steven

Re: Suggestion for a new GNATS policy

[Steven Bosscher]

Op ma 12-05-2003, om 15:46 schreef Daniel Berlin:
> Developers only care the bug is still valid, remember.

Developers don't look as much at PRs as they should, remember? :-P

Greetz
Steven

Re: Suggestion for a new GNATS policy

[Wolfgang Bangerth]

On 12 May 2003, Steven Bosscher wrote:

> > Developers only care the bug is still valid, remember.
> 
> Developers don't look as much at PRs as they should, remember? :-P

I get the feeling they do much more so, recently :-)

W.

-------------------------------------------------------------------------
Wolfgang Bangerth              email:            bangerth@ices.utexas.edu
                               www: http://www.ices.utexas.edu/~bangerth/

Re: Suggestion for a new GNATS policy

[Daniel Berlin]

On Monday, May 12, 2003, at 10:28  AM, Wolfgang Bangerth wrote:

>
> About the reconfirmed thing:
> - Basically, "reconfirmed" is a list of dates of snapshots.
> - I'd say everybody agrees that a good approximation to this is a list  
> of
>   dates at which it was reconfirmed: we may use snapshots that are a
>   couple of days old, but not more. So let's make it simpler and take  
> the
>   date/time of reconfirmation, since bugzilla can determine that by
>   itself.

So you want a field that is just updated through button clicks,  
basically (IE you click reconfirm, it updates the date). That can be  
visible in queries, and is querieable in terms of "has it changed in  
the past x days " and "has it not changed in the past x days".
Right?

> - Just as much, nobody really cares about previous dates, so it would  
> be
>   ok to just store the last time something was reconfirmed
>
Okeydokey.
Otherwise it requires a new table.

> Why a separate field (and why we store it in the symposis at present):
> - it needs to be visible (see below why); the audit trail is not, at  
> least
>   not in queries

I forgot to mention, you guys can make the full summary line visible.
Click "Change columns" on a bug list.
Check "Full summary", uncheck "Summary (First 60 chars)".
It'll then give you the full summary.
It saves these preferences for you automatically (using cookies).

> - reconfirming should be simple; bumping a date was considered simpler
>   than sending an email
That's fine.

> - by point 3 above, nobody cares about previous reconfirmations, so  
> we'd
>   like not to clutter the audit trails with pages of reconfirmations.
>
That's fine too.

> Given the last point, I would very much dislike reconfirming a bug by
> clearing-resetting the flag, since that would add _two_ more (and above
> that: useless) entries to the audit trail.

That's fine.

>
> My optimal solution would be a button "Reconfirmed" that I could click,
> that bumps the date of a respective (queryable) field, and that  
> otherwise
> leaves no mark in what I will usually see when I look at the audit  
> trail.
>
That's fine too.
Can you guys at least do Minimized and whatnot by flag?
I really don't want to add *too* many fields, and it seems that *most*  
of these things are booleans.
Like the existence of a minimized testcase for a bug or attachment.


>
>> Developers only care the bug is still valid, remember.
>
> That's too simple, Dan. We are talking about different communities, and
> the community that spends the most time with GNATS/bugzilla are what  
> you
> termed bugmasters. I tend to think they do valuable work and it would  
> be
> unfair to neglect their needs. The "reconfirmed date" information is
> clearly important to them (otherwise we wouldn't go to such length to  
> put
> it into the synposis of _every single_ C++ report), so please don't  
> make
> it harder than necessary.

I'm not, i'm just trying to make sure they realize that the bug system  
is not *only* for them, and that the main complaint about GNATS is it's  
interface.
Cluttering the interface is something i don't take lightly.
I'm willing to make it look different for different communities if  
necessary, which is what will happen here (the reconfirm button will  
only appear for people in certain bug groups, for simplicity sake).
We have more than just Developers and bugmasters anyway. We have users  
too, and it needs to be usable for them, too.

I'm just trying to get a concrete set of what you are trying to do, so  
i can figure out the best way to do it.
It's almost never a case that i *won't* do it, it may just entail a  
discussion of what you really need to be able to do vs what is easiest  
to provide (and is it enough).


>
> W.
>
> ----------------------------------------------------------------------- 
> --
> Wolfgang Bangerth              email:             
> bangerth@ices.utexas.edu
>                                www:  
> http://www.ices.utexas.edu/~bangerth/
>
>

Re: Suggestion for a new GNATS policy

[Daniel Berlin]

On Monday, May 12, 2003, at 10:39  AM, Wolfgang Bangerth wrote:

>
>> That's the easy (for me) way:
>> You can unset-reset the flag.
>> Then the bug activity looks like:
>> Who					When			    Removed	Added
>> root@danberlin.com  	2003-05-11 23:42  			Flag minimized+
>> root@danberlin.com		2003-05-11 23:42	Flag minimized+
>> root@danberlin.com 	2003-05-11 23:43 			Flag minimized+
>
> That's gross.
>
>
>> I just need to know *what* type of query you want to do on this flag,
>> so i can make it appear on the query form for you
>
> Two types of queries:
> - never (re)confirmed
> - not reconfirmed in last X days
That's fine. These are easy queries, actually.

> Sorting by the last reconfirmation date would be fine, but if we don't
> have it, nobody will bother either.
I can add it to the "Sort results by" dropdown without any trouble.

>
>
>> That's a useful *description*, not a useful *summary*.
>> The summary field is what is displayed on the bug lists by default.
>> The description field is display on the full bug display.
>> A useful summary of this bug would be "template-id not silently
>> decaying to PTF" or something.
>> Who wants to read half a paragraph for each bug to determine if it's
>> something they want to even click on to see more about?
>
> Having looked at probably >1000 reports, the conclusion is: there's no
> short summary in most cases (believe me). "ICE with templates" is short
> but useless.
>
> Truncating the summary line is really bad, since if there is no short
> summary, a truncated one is just as good as none at all.

Like I said in an email a minute account, I forgot until i looked at  
the template that this is actually a preference defaulting to truncate,  
but you can change it through "change columns" to make it display the  
whole thing.

I changed the default white background to alternate between gray and  
white per row, so one doesn't get easily messed up trying to follow  
which values go with which multi-line summary.



>
>>> This is because the synopsis is cut off, it's not because of the
>>> stamps. GNATS does not have such a problem because the whole synopsis
>>> is always shown.
>> I can do this trivially, but i haven't heard any complaints except  
>> from
>> you (counting this as a complaint).
>
> Here's #2.
>
>
>> go to http://dberlin.org/bugzilla/show_bug.cgi?id=10734
>>
>> I can make a radio button labeled "Reconfirm" (right under "Leave as
>> NEW") for you  guys if you want, so it's just "select reconfirm, click
>> commit".
>
> That's cool. I also like the "minimized" and "verified" flags (which
> indeed are really boolean flags).

Should these two flags be requestable of people?
IE do you want to be able to request that Giovanni (or yourself) verify  
or minimize a bug?
It then does three things when you request it:
1. It emails him (obviously) saying you've requested it.
2. It shows up in the "My requests" report you can access through the  
link at the bottom.
3. The bug report has the flag listed like: "giovannibajo: verified?"  
while waiting for him to set it or not set it.

Gives you an explicit work queue, so to speak.

It can be turned on and off (the requestability that is), so you don't  
have to make a final decision about it, just a guess as to whether you  
think it's useful to start.  It may be a hassle, i'm not familiar with  
how much work it is for you guys to track this stuff on your own.


>
> Thanks for you work and responsiveness on all this, Daniel!
Sorry if i seem argumentative or angry at times.
  Finally done with exams, and had massive headaches the past few days.
Don't take it personally.
:P
>
> W.
>
> ----------------------------------------------------------------------- 
> --
> Wolfgang Bangerth              email:             
> bangerth@ices.utexas.edu
>                                www:  
> http://www.ices.utexas.edu/~bangerth/
>
>

Re: Suggestion for a new GNATS policy

[Janis Johnson]

On Mon, May 12, 2003 at 06:33:59PM +0200, Steven Bosscher wrote:
> 
> What I'd really like to see is a "minimized test case" field (which may
> be a pointer to an attachment) and an SQL query to extract them all.  
> 
> That way, people could put DejaGNU-ified test cases in the bug database,
> rip them all out with the query, and test them on their target.  Even if
> only a few people would to that, we would know much sooner if/when a bug
> got fixed unnoticed (ie. PR not in CVS commit msg.), and to which target
> the bug applies.
> 
> The idea is that we really would like to be able to batch-test PR
> reports.  Janis and Wolfgang have talked about a PR testsuite, and this
> idea was mentioned again earlier in this thread, but we really don't
> want to litter the test suite that much.  With an easy way to extract
> all minimized test cases, you'd effectively have the same thing without
> even touching the testsuite.

Interesting idea, particularly if the query could be automated so the
tests could be run as part of nightly builds and testing.

Janis

Re: Suggestion for a new GNATS policy

[Wolfgang Bangerth]

> So you want a field that is just updated through button clicks,  
> basically (IE you click reconfirm, it updates the date). That can be  
> visible in queries, and is querieable in terms of "has it changed in  
> the past x days " and "has it not changed in the past x days".
> Right?

Yes, that would be optimal.


> I forgot to mention, you guys can make the full summary line visible.
> Click "Change columns" on a bug list.
> Check "Full summary", uncheck "Summary (First 60 chars)".
> It'll then give you the full summary.
> It saves these preferences for you automatically (using cookies).

Cool, another point that's cleared.


> Can you guys at least do Minimized and whatnot by flag?

I didn't see anyone against that. "Minimized" really is a boolean flag, 
"reconfirmed" wasn't.


> Cluttering the interface is something i don't take lightly.

Rightfully so. Thanks for having this in mind.


> It's almost never a case that i *won't* do it, it may just entail a  
> discussion of what you really need to be able to do vs what is easiest  
> to provide (and is it enough).

Your attempts to get us to the best of all worlds are very much 
appreciated. I see us really getting somewhere. Thanks a lot!

W.

-------------------------------------------------------------------------
Wolfgang Bangerth              email:            bangerth@ices.utexas.edu
                               www: http://www.ices.utexas.edu/~bangerth/

Re: Suggestion for a new GNATS policy

[Wolfgang Bangerth]

> > That's cool. I also like the "minimized" and "verified" flags (which
> > indeed are really boolean flags).
> 
> Should these two flags be requestable of people?
> IE do you want to be able to request that Giovanni (or yourself) verify  
> or minimize a bug?

I don't see much value in this. The only thing one might sometimes do is 
to assign something to myself, so that Giovanni knows I'm doing it right 
now and not starts it himself. When I'm done, would just de-assign myself.

So probably no increased sophistication necessary here.


> think it's useful to start.  It may be a hassle, i'm not familiar with  
> how much work it is for you guys to track this stuff on your own.

Not much. We usually work separately. If we have questions about a 
particular PR, we discuss it by email with CC: to the audit trail. 

W.

-------------------------------------------------------------------------
Wolfgang Bangerth              email:            bangerth@ices.utexas.edu
                               www: http://www.ices.utexas.edu/~bangerth/

Re: Suggestion for a new GNATS policy

[Daniel Berlin]

On Monday, May 12, 2003, at 12:33  PM, Steven Bosscher wrote:

> Op ma 12-05-2003, om 16:39 schreef Wolfgang Bangerth:
>>> I can make a radio button labeled "Reconfirm" (right under "Leave as
>>> NEW") for you  guys if you want, so it's just "select reconfirm, 
>>> click
>>> commit".
>>
>> That's cool. I also like the "minimized" and "verified" flags (which
>> indeed are really boolean flags).
>>
>> Thanks for you work and responsiveness on all this, Daniel!
>
> Wild idea:
>
> What I'd really like to see is a "minimized test case" field (which may
> be a pointer to an attachment) and an SQL query to extract them all.

Errr, you can have flags on attachments, so you can mark attachments 
with a  "minimized test case" flag, and query all of the existing ones.

It takes about 7 lines of perl to extract them:

# Include the Bugzilla CGI and general utility library.
use lib qw(.);
require "CGI.pl";

# Establish a connection to the database backend.
ConnectToDatabase();
use Bugzilla::Flag;
use Bugzilla::FlagType;
my (%criteria);
$criteria{"target_type"} = "attachment";

#This is the minimized flag id
$criteria{"type_id"} = "3";
my @results = Bugzilla::Flag::match(\%crit);


>
> That way, people could put DejaGNU-ified test cases in the bug 
> database,
> rip them all out with the query, and test them on their target.  Even 
> if
> only a few people would to that, we would know much sooner if/when a 
> bug
> got fixed unnoticed (ie. PR not in CVS commit msg.), and to which 
> target
> the bug applies.
>
> The idea is that we really would like to be able to batch-test PR
> reports.  Janis and Wolfgang have talked about a PR testsuite, and this
> idea was mentioned again earlier in this thread, but we really don't
> want to litter the test suite that much.  With an easy way to extract
> all minimized test cases, you'd effectively have the same thing without
> even touching the testsuite.
>
> Thoughts?
>
> Greetz
> Steven
>
>

Re: Suggestion for a new GNATS policy

[Daniel Berlin]

On Monday, May 12, 2003, at 10:50  AM, Wolfgang Bangerth wrote:

>
>>> Analyzed does not exist in Bugzilla (analyzed becomes "ASSIGNED"
>>> if assigned to someone, "NEW" otherwise).
>>
>> Aieee, please no.  There are so many analyzed PRs that are
>> unassigned, so what you say here would only make things harder.
>>
>> We should have "NEW" for new and unconfirmed PRs and "CONFIRMED"
>> for confirmed PRs.  PRs should have the "ANALYZED" status when
>> somebody has zoomed in at the problem a bit closed.  PRs that are
>> "analyzed" now should stay "ANALYZED" in bugzilla IMHO.

It's just renamed, not different.
ANALYZED is now NEW.
non-ANALYZED is UNCONFIRMED.

As i stated, i'm not going to rename existing bug states.
Too much code touching that will cause merge conflicts.

It's adequately described what each state means.
--Dan

Re: Suggestion for a new GNATS policy

[Janis Johnson]

On Mon, May 12, 2003 at 04:08:13AM +0200, Giovanni Bajo wrote:
> Joseph S. Myers <jsm28@cam.ac.uk> wrote:
> 
> > I'll reiterate that if we put these testcases in the testsuite, XFAILed
> > and with cross-references from testcase to bug number and from bug to
> > testcase, they would be automatically tested by many people on many
> > platforms and an accidental fix would be noticed immediately as an XPASS
> > when the patch accidentally fixing the bug is tested.  In that case the
> > keyword "monitored" could be used to mean "there is an XFAILed testcase in
> > the testsuite for this bug, and it isn't specific to a rarely tested
> > platform".
> 
> My only problem with this is that we would end up cluttering the testsuite
> with testcases which are not really bugs or are not completely correct, due
> to human mistakes / misinterpretations. Adding the testcase to the testsuite
> only when the bug is really fixed makes it sure that it's been "approved" as
> a real bug.
> In other words, XFAIL's meaning could be silently overloaded with "this is
> failing, but after all we're not 100% sure that this is a real bug".
> Of course, this applies to C/C++ standard interpretation. An ICE is of
> course always a bug.
> 
> In the end, I think that using the testsuite would not cover correctly _all_
> the PRs. Thus, some would have to still be manually checked. Hence, we can
> do that for everything and leave the testsuite "pure".

While I agree that we don't want to clutter up the testsuite, if these
tests were run regularly on a variety of platforms then we could easily
identify which platforms are affected and notice when a bug is magically
fixed.  Perhaps the PR tests could be in a separate testsuite that is
easy to plug into regular test runs (as with Mauve, for example) and
whose results could be reported in parallel to those of the regular
testsuite.  It would need to be easy for the people analyzing PRs to add
new tests to this suite.

Janis

Re: Suggestion for a new GNATS policy

[Nathanael Nerode]

> I was told it was simply a timestamp of when the bug was last 
>confirmed, not the date of the version it was CVS snapshot it was last 
>confirmed with.
> These are two very different things. In fact, it's not even a 
>timestamp 
>in the second case, it's a date-only field (IE no hour:minute:secs)
> Can someone please clarify which is correct?
This is nice.  A date-only field stating "Reconfirmed with snapshot of 
this date" is probably the correct way to indicate status (on mainline, 
anyway) for bug triage purposes.  Didn't know it was easy to add new 
fields. :-)

Doesn't deal with the other thing I'd really like to clean up, which is 
the 'which branches' issue, but it's a somewhat separate issue.

>If it's the second, you'll need a new field, i'll add one and make it 
>visible only to bug triagers.

Well, make it optionally visible to anyone who wants to look; you never 
know who will become a triager.  :-)

The classic search is for bugs with various other characteristics *plus* 
'reconfirmed before date Y (or never reconfirmed and originally 
confirmed before date Y)'.  This is the option which needs to be easy on 
the search screen.

Thanks for your hard work, Daniel...

--Nathanael

Re: Suggestion for a new GNATS policy

[Nathanael Nerode]

>>>>I
>>>>would not mind Bugzilla to have such a timestamp.
>>>
>>>You already have one when you define the flag. 
>>Yup, but we need one that we can update anytime we want. And if we could do
>>that with a single mouse click, it would be even better. 
>as i said, 6 mouse clicks.
 
This *is* too many.


>I can make a radio button labeled "Reconfirm" (right under "Leave as 
>NEW") for you guys if you want, so it's just "select reconfirm, click 
>commit".
 
That would rock.  :-)

--Nathanael

 

Re: Suggestion for a new GNATS policy

[Nathanael Nerode]

>Yes it is. Reconfirmed is either true or false. There is no "kinda 
>reconfirmed".
Sadly, this isn't actually true.  Explanation follows...

> The time when something was reconfirmed is just extra info about 
>*when* the state happened, not information stored in the state itself. 

The date something was reconfirmed indicates *which snapshot of GCC* it 
was confirmed with.  This turns out to be very important information.  
If I indicate "Reconfirmed on 3.2 branch, not present on 3.3 branch, 
present on mainline", *plus* the date on which I did this, it contains a 
lot of information.  This isn't boolean at all.  Also note that the 
timestamp isn't technically the date I confirmed it, it's the date of 
the CVS sources I confirmed it with, although those are usually the 
same.

Essentially, we're encoding, for each active branch, the state (present 
or not present) on that branch as of a particular date.  There are many 
correct ways to do this, but it's far from being  boolean information.  
I welcome suggestions from the other regular 'bug  managers' as to what 
would be best.

The audit trail entries for confirmations (as of particular dates) are 
useful for tracking *when* a bug was fixed, as well.

The simplest way is the date-in-the-title currently used.  Each time a 
branch dies (for instance, the 3.2 branch will die when 3.3 is 
released), all reports confirmed prior to the branch 'death date' should 
be checked to make sure that they weren't already confirmed fixed on the 
active branches.

--
Here's a more complex proposal, which I think actually gets at the 
heart of the issue:

For each active branch, there's a flag "Confirmed present in this 
branch" and a flag "Confirmed absent in this branch".  (There should 
also be corresponding flags for actual past releases.)  This is 
what maintainers generally will poke, rather than the bug state.  (Two 
flags are necessary because of the third state: uncertain.  Programmatically, 
setting one should unset the other.)

For automated maintenance, do the following.  Maintain a list 
of 'live' branches.  Confirmation on any live branch makes a bug 
confirmed ('NEW' rather than 'UNCONFIRMED').  Confirmation of 
absence from all live branches closes a bug.  When a branch dies, 
run a script through the bug database; any bug confirmed absent on all live
branches is closed as fixed.  When a branch splits, clone the tags from 
the branch it split from (usually mainline).  

It should be easy to query when (and by who!) the 'confirmed in branch 
X' flag was last set, so that you can easily check for:

* Reports never confirmed present or absent on branch X (need testing)
* Reports confirmed present on branch X, but only before date Y (need 
retesting)

This should be easy to combine with other tests, so that I can search 
for (for example) reports not tested or tested prior to date Y on the 
3.3 branch, but confirmed present on mainline as of date Y.

There's no need under this complex scheme for special regression 
markers; reports confirmed absent on an 'old release' and present on 
branch X are regressions for branch X, and it should be easy to do a 
search for that.

Can it be done?  Does it sound good?  :-)

--
Ugh.  I realized an alternative means of implementing the same thing: 
have a bug STATE field for *each* branch, which is unfortunately the 
correct thing, but is probably close to impossible in Bugzilla.

"Analyzed" (i.e. reduced) should certainly be a flag; it's not nearly so 
complicated as 'confirmed'.  :-)

--Nathanael

Re: Suggestion for a new GNATS policy

[Wolfgang Bangerth]

> I'll reiterate that if we put these testcases in the testsuite, XFAILed
> and with cross-references from testcase to bug number and from bug to
> testcase, they would be automatically tested by many people on many
> platforms and an accidental fix would be noticed immediately as an XPASS
> when the patch accidentally fixing the bug is tested.  In that case the
> keyword "monitored" could be used to mean "there is an XFAILed testcase in
> the testsuite for this bug, and it isn't specific to a rarely tested
> platform".

I had thought so, too, but I have changed my mind on this. We now have a 
quite active community of people just working on gnats, why bother them 
with the procedures of using CVS, make check, etc? I think we have 
successfully "modularized" the process into bug confirmation/reducting/
tracking on the one hand, and fixing on the other hand. Mixing these 
processes just makes things harder for everyone, and in particular raises 
the entry level for newcomers. I think the present process is pretty good.

W.

-------------------------------------------------------------------------
Wolfgang Bangerth              email:            bangerth@ices.utexas.edu
                               www: http://www.ices.utexas.edu/~bangerth/

RE: Suggestion for a new GNATS policy

[Wolfgang Bangerth]

> > Analyzed does not exist in Bugzilla (analyzed becomes "ASSIGNED"
> > if assigned to someone, "NEW" otherwise).
> 
> Aieee, please no.  There are so many analyzed PRs that are
> unassigned, so what you say here would only make things harder.
> 
> We should have "NEW" for new and unconfirmed PRs and "CONFIRMED"
> for confirmed PRs.  PRs should have the "ANALYZED" status when
> somebody has zoomed in at the problem a bit closed.  PRs that are
> "analyzed" now should stay "ANALYZED" in bugzilla IMHO.

Seconded.

-------------------------------------------------------------------------
Wolfgang Bangerth              email:            bangerth@ices.utexas.edu
                               www: http://www.ices.utexas.edu/~bangerth/

Re: Suggestion for a new GNATS policy

[Daniel Berlin]

On Sunday, May 11, 2003, at 10:00  PM, Giovanni Bajo wrote:

> Daniel Berlin <dberlin@dberlin.org> wrote:
>
>>>   "analyzed" should mean that at least the category is set and
>>> that a reduced test case is available.
>
>> Why?
>> you can mark them with a keyword or bug status flags.
>> Stop overloading bug states for this functionality.
>> Geez.
>
> No, in my opiniton it's totally the contrary. "Confirmed" should be 
> just a
> flag. I don't care if a bug is confirmed or not:

Because you only look at *bugs*, not other things tracked through the 
bug system, like enhancements.
>  confirming is a no-brain
> action: it means I downloaded the PR, run GCC on it, and verified the 
> bug.
> To push it, it could even be automated for 
> c++/c/middle-end/optimization
> bugs (especially ICEs). I don't think anybody really cares if it's been
> confirmed that a 300K file ICEs the compiler: the real problem is an
> effective analysys of the bug, which means testcase reduction, code 
> forming
> check, and such.
There are also bugs that are *not* bugs.
They can be about enhancements, patches, whatever.
Not everything is a bug.
> This is what it's really important. I don't really mind about the 
> name, but
> if Bugzilla doesn't have "analyzed" but only "uncorfimed" and "new", we
> should use "new" as analyzed.
The reason there is no "analyzed" is because not everything is a bug 
that needs any of these things done to them.
It's the wrong term.
>
> Otherwise, please explain us what is a state and what is a flag. 
> Usually, a
> bug which is not properly analyzed will not be considered for 
> bugfixing,

There are plenty of people who look at bugs without minimal testcases, 
or look at enhancements.
>  so
> this is where the stress should go.
> I call this a bug state.
>  Confirmation is
> not necessary a state (it's mostly useless),

Enhancements can be tracked *without* a testcase at all, but they need 
to be confirmed that they don't exist currently in bugzilla.

There are also people who use Bugzilla to track branch landings and 
whatnot ("meta bugs"), so that you can set a bug expected to be fixed 
by the branch merge as being dependent on the branch landing "bug".

There is more than just bugs in a bug database.
>  so I'm ok with it being just a
> flag.
>

Renaming or removing the built-in states is not something i will do.  
It requires trivial modifications to a lot of files, that cause merge 
problems later on.
I can add states with coding changes grudgingly, for the same reason. 
It's easier to add than rename or remove, but still causes some 
problems.
You can add/remove/edit available flags for bugs with a simple web 
based interface as much or as little as you want.

I don't understand why you seem to want tons of bug states. Nobody can 
juggle them in their head anyway.

To answer your question about the distinction between flags and states, 
there is no general distinction, so i'll make an arbitrary one for you:

In general, states are things  that most developers care about in the 
life cycle of a bug.
We are simple folk in this regard.
If it's a bug, we fix it.
An enhancement, we add the enhancement (or mark it as wontfix).
etc
When fixed, we mark it fixed.
We don't need to know whether a bug has a minimized testcase, or if 
it's been reconfirmed recently.
If these are requirements to something being a "NEW" (for lack of a 
better term) bug, that's fine.
It just means as far as we are concerned, it's not a bug we want to fix 
yet, because it's not "NEW".

Bug flags are things you guys can use to track your workings on a bug 
(like whether it's been reconfirmed recently, whether it's got a 
minimized testcase, etc), including things you use to determine when 
*you* move a bug from one state to another.  These are generally a set 
of requirements that can be expressed as booleans. "Does it have a 
minimized testcase?", or a combination of a boolean and a date/time 
when the boolean was last changed ("Has it been reconfirmed? When was 
it last reconfirmed?").
Developers aren't going to really care about the bug flags (If we use 
bugzilla for patch tracking or branch tracking or whatnot, we'd care 
about attachment flags, which are different).

I can go further with this arbitrary distinction if you like, but it 
suffices to keep developers from juggling 40 different bug states, and 
gives you guys a place to track things, without having to put them in 
the subject.

I'll note also Bugzilla allows attachments to have flags as well (it's 
a separate namespace of flags than bug flags).
Attachment flags can be set because of a new attachment (IE you can say 
obsolete was added to attachment x because of new attachment y).
You could simply mark the old attachment as obsolete (which is a 
built-in attachment flag), and flag the new attachment as "minimized", 
rather than flagging the *bug* as minimized, since it's the attached 
testcase that is minimized, not the bug.
YOu could also mark the original testcase attachment as minimized if it 
is minimized.
This is actually where minimized belongs, since it's a property of a 
testcase for a bug (which is supposed to be in an attachment, no?), not 
a bug itself.



> Giovanni Bajo
>

Re: Suggestion for a new GNATS policy

[Gabriel Dos Reis]

"Giovanni Bajo" <giovannibajo@libero.it> writes:

| Joseph S. Myers <jsm28@cam.ac.uk> wrote:
| 
| > I'll reiterate that if we put these testcases in the testsuite, XFAILed
| > and with cross-references from testcase to bug number and from bug to
| > testcase, they would be automatically tested by many people on many
| > platforms and an accidental fix would be noticed immediately as an XPASS
| > when the patch accidentally fixing the bug is tested.  In that case the
| > keyword "monitored" could be used to mean "there is an XFAILed testcase in
| > the testsuite for this bug, and it isn't specific to a rarely tested
| > platform".
| 
| My only problem with this is that we would end up cluttering the testsuite
| with testcases which are not really bugs or are not completely correct, due
| to human mistakes / misinterpretations. Adding the testcase to the testsuite
| only when the bug is really fixed makes it sure that it's been "approved" as
| a real bug.
| In other words, XFAIL's meaning could be silently overloaded with "this is
| failing, but after all we're not 100% sure that this is a real bug".
| Of course, this applies to C/C++ standard interpretation. An ICE is of
| course always a bug.

Agreed on both counts.

I think we would even end up with more duplicates than necessary.

-- Gaby

Re: Suggestion for a new GNATS policy

[Giovanni Bajo]

Joseph S. Myers <jsm28@cam.ac.uk> wrote:

> I'll reiterate that if we put these testcases in the testsuite, XFAILed
> and with cross-references from testcase to bug number and from bug to
> testcase, they would be automatically tested by many people on many
> platforms and an accidental fix would be noticed immediately as an XPASS
> when the patch accidentally fixing the bug is tested.  In that case the
> keyword "monitored" could be used to mean "there is an XFAILed testcase in
> the testsuite for this bug, and it isn't specific to a rarely tested
> platform".

My only problem with this is that we would end up cluttering the testsuite
with testcases which are not really bugs or are not completely correct, due
to human mistakes / misinterpretations. Adding the testcase to the testsuite
only when the bug is really fixed makes it sure that it's been "approved" as
a real bug.
In other words, XFAIL's meaning could be silently overloaded with "this is
failing, but after all we're not 100% sure that this is a real bug".
Of course, this applies to C/C++ standard interpretation. An ICE is of
course always a bug.

In the end, I think that using the testsuite would not cover correctly _all_
the PRs. Thus, some would have to still be manually checked. Hence, we can
do that for everything and leave the testsuite "pure".

Giovanni Bajo

Re: Suggestion for a new GNATS policy

[Giovanni Bajo]

Daniel Berlin <dberlin@dberlin.org> wrote:

>>   "analyzed" should mean that at least the category is set and
>> that a reduced test case is available.

> Why?
> you can mark them with a keyword or bug status flags.
> Stop overloading bug states for this functionality.
> Geez.

No, in my opiniton it's totally the contrary. "Confirmed" should be just a
flag. I don't care if a bug is confirmed or not: confirming is a no-brain
action: it means I downloaded the PR, run GCC on it, and verified the bug.
To push it, it could even be automated for c++/c/middle-end/optimization
bugs (especially ICEs). I don't think anybody really cares if it's been
confirmed that a 300K file ICEs the compiler: the real problem is an
effective analysys of the bug, which means testcase reduction, code forming
check, and such.
This is what it's really important. I don't really mind about the name, but
if Bugzilla doesn't have "analyzed" but only "uncorfimed" and "new", we
should use "new" as analyzed.

Otherwise, please explain us what is a state and what is a flag. Usually, a
bug which is not properly analyzed will not be considered for bugfixing, so
this is where the stress should go. I call this a bug state. Confirmation is
not necessary a state (it's mostly useless), so I'm ok with it being just a
flag.

Giovanni Bajo

Re: Suggestion for a new GNATS policy

[Daniel Berlin]

Here guys, as an example, i added a verified flag and a minimized flag 
for bugs.

Since Chris upgraded perl, and bugzilla on sources is currently thus 
out of order, try http://www.dberlin.org/bugzilla/

choose a random bug to see the flags.
There is an interface for adding keywords and flags to bugs/attachments.

I'll make it so the flags are queryable  easily



On Sunday, May 11, 2003, at 05:52  PM, S. Bosscher wrote:

> Dan wrote:
>> On Sunday, May 11, 2003, at 04:30  PM, Volker Reichelt wrote:
>>> 1) The state "analyzed" does not help much, because the requirements
>>> are too weak: It just means that somebody has looked at it and agrees
>>> that there's a bug in GCC. Very often not even the class of the PR is
>>> set correctly. Preprocessed files (especially for C++ bugs) are often
>>> huge so that somebody who tries to fix a bug has to do major work
>>> (which could be done by somebody else) before being able to tackle
>>> the core of the problem.
>
> I agree.  For many PRs, "analyzed" now just means "yup, I see it, too",
> which is not what I call analysis :-)
>
>>> So IMHO we need some stricter requirements for reports in state
>>> "analyzed". Knowing that any analyzed PR is in the right class and
>>> has a simple testcase attached and a suitable synopsis line would
>>> help the bug fixers to do their work efficiently.
>
> We should have a "confirmed" state, which would mean that somebody 
> with GCC
> PR DB write access can reproduce the bug (possibly after receiving
> feedback).  "analyzed" should mean that at least the category is set 
> and
> that a reduced test case is available.
>
>> Analyzed does not exist in Bugzilla (analyzed becomes "ASSIGNED"
>> if assigned to someone, "NEW" otherwise).
>
> Aieee, please no.  There are so many analyzed PRs that are
> unassigned, so what you say here would only make things harder.
>
> We should have "NEW" for new and unconfirmed PRs and "CONFIRMED"
> for confirmed PRs.  PRs should have the "ANALYZED" status when
> somebody has zoomed in at the problem a bit closed.  PRs that are
> "analyzed" now should stay "ANALYZED" in bugzilla IMHO.
>
> I don't know how many states you defined,  gcc.gnu.org/bugzilla
> used to work but now it fails...  (Does Bugzilla allow you to
> define your own states at all???)  But I suppose we should have
> "NEW", "FEEDBACK", "CONFIRMED", "ANALYZED", "ASSIGNED", "CLOSED",
> "REOPENED" (yes this happens), and "SUSPENDED".
>
> (Yes that's very much like what we have in GNATS now, but that's 
> because
> GNATS is not so bad, really.  It just misses one or two states and its 
> user
> interface is very poor.)
>
>>> 2) To close the PRs that got fixed silently the PRs have to
>>> be revisited from time to time. But there should be some way
>>> to give the PR's a time stamp so that one can easily see
>>> (without having to read the whole audit-trail) when a PR
>>> should be revisited again.
>
> There's also the "Last-Modified" field, what is wrong with that?
>
> Now all the synopses are being cluttered with date stamps, and
> that is IMHO just wrong.  The markers like [New parser],
> [<some_target>], etc. are useful, because they make it so much
> easier to find related PRs real quick.  The date stamps don't
> do anything that can't be done with basic GNATS functionality,
> at least AFAICT.
>
>> In most cases, there is no need. One just has to remember to
>> put the right thing in the CVS commit message, and it'll get
>> added to the PR as a comment.
>
> It's not unusual for a PR to be fixed without anyone noticing.
> For 3.3, I closed some PRs that got fixed by some patch, but
> the CVS commit message didn't mention the PR (probably because
> nobody knew about the PR...) so the PR stayed open.  I think
> everybody has seen PRs like that.
>
>> You can easily query for bugs that haven't (or have) been
>> touched in x days in Bugzilla, so there is no need to put
>> timestamps on bugs and whatnot.
>
> You can do that with GNATS, too.  Just not very user friendly,
> it _can_ be done.
>
> Greetz
> Steven
>

Re: Suggestion for a new GNATS policy

[Daniel Berlin]

>
>>> So IMHO we need some stricter requirements for reports in state
>>> "analyzed". Knowing that any analyzed PR is in the right class and
>>> has a simple testcase attached and a suitable synopsis line would
>>> help the bug fixers to do their work efficiently.
>
> We should have a "confirmed" state, which would mean that somebody 
> with GCC
> PR DB write access can reproduce the bug (possibly after receiving
> feedback).

This is "NEW".  There is an UNCONFIRMED state for UNCONFIRMED bugs.


>   "analyzed" should mean that at least the category is set and
> that a reduced test case is available.
>

Why?
you can mark them with a keyword or bug status flags.
Stop overloading bug states for this functionality.
Geez.

>> Analyzed does not exist in Bugzilla (analyzed becomes "ASSIGNED"
>> if assigned to someone, "NEW" otherwise).
>
> Aieee, please no.  There are so many analyzed PRs that are
> unassigned, so what you say here would only make things harder.
>
> We should have "NEW" for new and unconfirmed PRs and "CONFIRMED"
> for confirmed PRs.  PRs should have the "ANALYZED" status when
> somebody has zoomed in at the problem a bit closed.  PRs that are
> "analyzed" now should stay "ANALYZED" in bugzilla IMHO.
>
These should be bug flags, *not* states.

> I don't know how many states you defined,  gcc.gnu.org/bugzilla
> used to work but now it fails...

Chris upgraded perl today, apparently.
Needs to reinstall some packages.

>   (Does Bugzilla allow you to
> define your own states at all???)
Yes, but there is no need in this case.
>
>
>> In most cases, there is no need. One just has to remember to
>> put the right thing in the CVS commit message, and it'll get
>> added to the PR as a comment.
>
> It's not unusual for a PR to be fixed without anyone noticing.
> For 3.3, I closed some PRs that got fixed by some patch, but
> the CVS commit message didn't mention the PR (probably because
> nobody knew about the PR...) so the PR stayed open.  I think
> everybody has seen PRs like that.
>
>> You can easily query for bugs that haven't (or have) been
>> touched in x days in Bugzilla, so there is no need to put
>> timestamps on bugs and whatnot.
>
> You can do that with GNATS, too.  Just not very user friendly,
> it _can_ be done.
>
> Greetz
> Steven
>

Re: Suggestion for a new GNATS policy

[Daniel Berlin]

On Sunday, May 11, 2003, at 04:55  PM, Joseph S. Myers wrote:

> On Sun, 11 May 2003, Volker Reichelt wrote:
>
>> There has been some effort over the last year to clean up GCC's bug 
>> database.
>> One problem is that many bug reports have to be revisited several 
>> times
>> (which is just a waste of resources), because of two problems:
>
> I suggest working out what changes to the GCC Bugzilla configuration 
> would
> be helpful in this regard, so that they can be made before the 
> transition,
> especially if they might affect the conversion program (converting the
> described notations used in GNATS into an appropriate form for 
> Bugzilla).
>
> I believe (but <http://gcc.gnu.org/bugzilla/> presently gives an error
> message) that "open" is converted to UNCONFIRMED and "analyzed" to NEW 
> or
> ASSIGNED.  Usefully different types of confirmed bugs could get 
> different
> states in Bugzilla if that is useful.
>
> Date on which a bug was last verified could be a new Bugzilla field.

You can already determine when a bug was last modified.

--Dan

RE: Suggestion for a new GNATS policy

[S. Bosscher]

Dan wrote:
> On Sunday, May 11, 2003, at 04:30  PM, Volker Reichelt wrote:
> > 1) The state "analyzed" does not help much, because the requirements 
> > are too weak: It just means that somebody has looked at it and agrees
> > that there's a bug in GCC. Very often not even the class of the PR is
> > set correctly. Preprocessed files (especially for C++ bugs) are often 
> > huge so that somebody who tries to fix a bug has to do major work 
> > (which could be done by somebody else) before being able to tackle
> > the core of the problem.

I agree.  For many PRs, "analyzed" now just means "yup, I see it, too",
which is not what I call analysis :-)

> > So IMHO we need some stricter requirements for reports in state 
> > "analyzed". Knowing that any analyzed PR is in the right class and
> > has a simple testcase attached and a suitable synopsis line would 
> > help the bug fixers to do their work efficiently.

We should have a "confirmed" state, which would mean that somebody with GCC
PR DB write access can reproduce the bug (possibly after receiving
feedback).  "analyzed" should mean that at least the category is set and
that a reduced test case is available.

> Analyzed does not exist in Bugzilla (analyzed becomes "ASSIGNED"
> if assigned to someone, "NEW" otherwise).

Aieee, please no.  There are so many analyzed PRs that are
unassigned, so what you say here would only make things harder.

We should have "NEW" for new and unconfirmed PRs and "CONFIRMED"
for confirmed PRs.  PRs should have the "ANALYZED" status when
somebody has zoomed in at the problem a bit closed.  PRs that are
"analyzed" now should stay "ANALYZED" in bugzilla IMHO.

I don't know how many states you defined,  gcc.gnu.org/bugzilla
used to work but now it fails...  (Does Bugzilla allow you to
define your own states at all???)  But I suppose we should have
"NEW", "FEEDBACK", "CONFIRMED", "ANALYZED", "ASSIGNED", "CLOSED",
"REOPENED" (yes this happens), and "SUSPENDED".

(Yes that's very much like what we have in GNATS now, but that's because
GNATS is not so bad, really.  It just misses one or two states and its user
interface is very poor.)

> > 2) To close the PRs that got fixed silently the PRs have to
> > be revisited from time to time. But there should be some way
> > to give the PR's a time stamp so that one can easily see
> > (without having to read the whole audit-trail) when a PR
> > should be revisited again.

There's also the "Last-Modified" field, what is wrong with that?

Now all the synopses are being cluttered with date stamps, and
that is IMHO just wrong.  The markers like [New parser], 
[<some_target>], etc. are useful, because they make it so much
easier to find related PRs real quick.  The date stamps don't
do anything that can't be done with basic GNATS functionality,
at least AFAICT.
 
> In most cases, there is no need. One just has to remember to
> put the right thing in the CVS commit message, and it'll get
> added to the PR as a comment.

It's not unusual for a PR to be fixed without anyone noticing.
For 3.3, I closed some PRs that got fixed by some patch, but
the CVS commit message didn't mention the PR (probably because
nobody knew about the PR...) so the PR stayed open.  I think
everybody has seen PRs like that.

> You can easily query for bugs that haven't (or have) been
> touched in x days in Bugzilla, so there is no need to put
> timestamps on bugs and whatnot.

You can do that with GNATS, too.  Just not very user friendly,
it _can_ be done.

Greetz
Steven

Re: Suggestion for a new GNATS policy

[Joseph S. Myers]

On Sun, 11 May 2003, Volker Reichelt wrote:

> There has been some effort over the last year to clean up GCC's bug database.
> One problem is that many bug reports have to be revisited several times
> (which is just a waste of resources), because of two problems:

I suggest working out what changes to the GCC Bugzilla configuration would 
be helpful in this regard, so that they can be made before the transition, 
especially if they might affect the conversion program (converting the 
described notations used in GNATS into an appropriate form for Bugzilla).

I believe (but <http://gcc.gnu.org/bugzilla/> presently gives an error 
message) that "open" is converted to UNCONFIRMED and "analyzed" to NEW or 
ASSIGNED.  Usefully different types of confirmed bugs could get different 
states in Bugzilla if that is useful.

Date on which a bug was last verified could be a new Bugzilla field.
"monitored" would probably be a keyword (and regression information
control the choice of milestones for bugs).

> +synopsis line. Some reports have a stamp "<strong>[monitored]</strong>"
> +instead of a date stamp in the synopsis line. This means that the PR is
> +checked automatically (currently against the 3.3 branch and mainline almost
> +daily by a program run by Volker Reichelt). These reports do not have to be
> +rechecked manually.</dd>

I'll reiterate that if we put these testcases in the testsuite, XFAILed
and with cross-references from testcase to bug number and from bug to
testcase, they would be automatically tested by many people on many
platforms and an accidental fix would be noticed immediately as an XPASS
when the patch accidentally fixing the bug is tested.  In that case the
keyword "monitored" could be used to mean "there is an XFAILed testcase in
the testsuite for this bug, and it isn't specific to a rarely tested
platform".

-- 
Joseph S. Myers
jsm28@cam.ac.uk

Re: Suggestion for a new GNATS policy

[Daniel Berlin]

On Sunday, May 11, 2003, at 04:30  PM, Volker Reichelt wrote:

> There has been some effort over the last year to clean up GCC's bug 
> database.
> One problem is that many bug reports have to be revisited several times
> (which is just a waste of resources), because of two problems:
>
> 1) The state "analyzed" does not help much, because the requirements 
> are
>    too weak: It just means that somebody has looked at it and agrees 
> that
>    there's a bug in GCC. Very often not even the class of the PR is set
>    correctly. Preprocessed files (especially for C++ bugs) are often 
> huge
>    so that somebody who tries to fix a bug has to do major work (which
>    could be done by somebody else) before being able to tackle the core
>    of the problem.
>    So IMHO we need some stricter requirements for reports in state 
> "analyzed".
>    Knowing that any analyzed PR is in the right class and has a simple 
> testcase
>    attached and a suitable synopsis line would help the bug fixers to 
> do their
>    work efficiently.

Analyzed does not exist in Bugzilla (analyzed becomes "ASSIGNED" if 
assigned to someone, "NEW" otherwise).
Remember we are moving to Bugzilla rather soon (I stated within a  week 
or two after 3.3 is released, which is RSN).

>
> 2) To close the PRs that got fixed silently the PRs have to be 
> revisited from
>    time to time. But there should be some way to give the PR's a time 
> stamp
>    so that one can easily see (without having to read the whole 
> audit-trail)
>    when a PR should be revisited again.

In most cases, there is no need. One just has to remember to put the 
right thing in the CVS commit message, and it'll get added to the PR as 
a comment.

Even saying "May fix Bug <x>" should make it do this.  Then you'll see 
the notice on gcc-bugs of the added comment, and there's your reminder.


You can easily query for bugs that haven't (or have) been touched in x 
days in Bugzilla, so there is no need to put timestamps on bugs and 
whatnot.

Given that i'd just have to remove the advice in bugs/management.html 
in a few weeks when we move, why should we add it in the first place?

--Dan

Suggestion for a new GNATS policy

[Volker Reichelt]

There has been some effort over the last year to clean up GCC's bug database.
One problem is that many bug reports have to be revisited several times
(which is just a waste of resources), because of two problems:

1) The state "analyzed" does not help much, because the requirements are
   too weak: It just means that somebody has looked at it and agrees that
   there's a bug in GCC. Very often not even the class of the PR is set
   correctly. Preprocessed files (especially for C++ bugs) are often huge
   so that somebody who tries to fix a bug has to do major work (which
   could be done by somebody else) before being able to tackle the core
   of the problem.
   So IMHO we need some stricter requirements for reports in state "analyzed".
   Knowing that any analyzed PR is in the right class and has a simple testcase
   attached and a suitable synopsis line would help the bug fixers to do their
   work efficiently.

2) To close the PRs that got fixed silently the PRs have to be revisited from
   time to time. But there should be some way to give the PR's a time stamp
   so that one can easily see (without having to read the whole audit-trail)
   when a PR should be revisited again.

To tackle both of the problems, Wolfgang Bangerth and Giovanni Bajo are
wading through the PR's to meet the requirements mentioned in 1) for each
analyzed PR (for C++ category first, but C, optimization and middle-end will
hopefully follow). And they are putting time stamps on those PRs.

In addition, I've collected quite a number of testcases that are tested
automatically almost daily so that the related PRs do not require manual
rechecking. Therefore, I want to give them a special stamp "[monitored]"
instead of a date stamp.

To keep the shape of the bug database from deteriorating again, I'd like
to formalize the strategy above by suggesting the following change to
"bugs/management.html":

===============================================================================
--- management.html	Fri May  9 11:44:50 2003
+++ management.html.new	Fri May  9 17:26:09 2003
@@ -105,11 +105,25 @@ some fields. The State field should be u
 <dd>The PR has been filed and the responsible person(s) notified.</dd>
 
 <dt>analyzed</dt>
-
-<dd>A maintainer has verified that this is indeed a bug in GCC. Every
-once in a while, old reports will need to be rechecked, to find out
-whether the bug still exists. At that time, an indication should be
-left in the report who tested the bug and when.</dd>
+<dd>A maintainer has verified that this is indeed a bug in GCC.
+All analyzed reports should
+<ul>
+<li>contain a <strong>small testcase</strong>,</li>
+<li>be in the <strong>right category and class</strong>,</li>
+<li>have a suitable <strong>synopsis</strong>,</li>
+<li>have a stamp "<strong>[... regression]</strong>" in the synopsis line
+if it is indeed a regression (see "Procedures and Policies")</strong>,</li>
+<li>have a date stamp "<strong>[YYYY-MM-DD]</strong>" in the synopsis line
+that indicates when the report was last checked.</li>
+</ul>
+Otherwise the PR should remain open.<br />
+Every once in a while, old reports will need to be rechecked, to find out
+whether the bug still exists. At that time, please bump the date in the
+synopsis line. Some reports have a stamp "<strong>[monitored]</strong>"
+instead of a date stamp in the synopsis line. This means that the PR is
+checked automatically (currently against the 3.3 branch and mainline almost
+daily by a program run by Volker Reichelt). These reports do not have to be
+rechecked manually.</dd>
 
 <dt>feedback</dt>
 <dd>The submitter was asked for further information, or asked to try
===============================================================================

The requirement of a short testcase is probably only feasible for some
categories like C++, but not for others like bootstrap.

One last remark: It's easy to decide whether a PR was analyzed according
to the new or old rules by just looking for the date stamp in the synopsis
line.

Regards,
Volker Reichelt