Re: Suggestion for a new GNATS policy

[Daniel Berlin <dberlin at dberlin dot org>]

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