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