resolved, fixed bugs since FOP1.0 that need to be closed

[Glenn Adams <gl...@skynav.com>]

I just noticed that there are 83 bugs [1] that, since the FOP 1.0 release
(2010-07-20), have been marked as *resolved* and *fixed*, but have not been
changed to *closed* status.

[1]
https://issues.apache.org/bugzilla/buglist.cgi?list_id=81930;resolution=FIXED;chfieldto=Now;query_format=advanced;chfield=bug_status;chfieldfrom=2010-07-20;bug_status=RESOLVED;product=Fop

I could change all these to closed, but it would be better if those who
filed or fixed the bug would do this in order to ensure that there is
proper closure, with any verification they think is needed.

Re: resolved, fixed bugs since FOP1.0 that need to be closed

[Glenn Adams <gl...@skynav.com>]

If there are no objections, say, within 24 hours, I will go ahead and
transition to CLOSED+FIXED all bugs currently in the RESOLVED+FIXED state.

On Wed, Mar 28, 2012 at 10:45 AM, Glenn Adams <gl...@skynav.com> wrote:

>
> On Wed, Mar 28, 2012 at 12:23 AM, Glenn Adams <gl...@skynav.com> wrote:
>
>> I just noticed that there are 83 bugs [1] that, since the FOP 1.0 release
>> (2010-07-20), have been marked as *resolved* and *fixed*, but have not
>> been changed to *closed* status.
>>
>> [1]
>> https://issues.apache.org/bugzilla/buglist.cgi?list_id=81930;resolution=FIXED;chfieldto=Now;query_format=advanced;chfield=bug_status;chfieldfrom=2010-07-20;bug_status=RESOLVED;product=Fop
>>
>> I could change all these to closed, but it would be better if those who
>> filed or fixed the bug would do this in order to ensure that there is
>> proper closure, with any verification they think is needed.
>>
>
> Thanks to Alex, Mehdi, and Peter for the quick response to close bugs they
> reported or fixed!
>
>

Re: resolved, fixed bugs since FOP1.0 that need to be closed

[Glenn Adams <gl...@skynav.com>]

On Wed, Mar 28, 2012 at 12:23 AM, Glenn Adams <gl...@skynav.com> wrote:

> I just noticed that there are 83 bugs [1] that, since the FOP 1.0 release
> (2010-07-20), have been marked as *resolved* and *fixed*, but have not
> been changed to *closed* status.
>
> [1]
> https://issues.apache.org/bugzilla/buglist.cgi?list_id=81930;resolution=FIXED;chfieldto=Now;query_format=advanced;chfield=bug_status;chfieldfrom=2010-07-20;bug_status=RESOLVED;product=Fop
>
> I could change all these to closed, but it would be better if those who
> filed or fixed the bug would do this in order to ensure that there is
> proper closure, with any verification they think is needed.
>

Thanks to Alex, Mehdi, and Peter for the quick response to close bugs they
reported or fixed!

Re: resolved, fixed bugs since FOP1.0 that need to be closed

[Glenn Adams <gl...@skynav.com>]

On Fri, Mar 30, 2012 at 2:46 AM, Vincent Hennebert <vh...@gmail.com>wrote:

> On 28/03/12 17:39, Glenn Adams wrote:
> <snip/>
> > If we did have a full QA process, we would assign resolved bugs to
> someone
> > to check and transition to verified state. Then one of the following
> would
> > be designated to transition the bug to closed state: (1) original
> > submitter, (2) fixer, (3) QA, or (4) PM.
> >
> > Leaving a bug in resolved state (according to the fixer's perspective)
> does
> > not close the loop on the bug (at least in my opinion). In fact, it
> remains
> > an open bug as far as bugzilla is concerned, e.g., closed bugs are
> > displayed in strike-out style, while resolved bugs are not.
> >
> > The reason I am raising this now is because I am reviewing the bug list
> > since the FOP 1.0 release in order to prepare information for a possible
> > upcoming FOP 1.1 release. In doing this review, I found some bugs marked
> as
> > resolved+fixed and others as closed+fixed. This makes it more difficult
> to
> > compile and classify the status of bugs, and results in inconsistent
> views
> > about the status of given bugs or FOP as a whole.
>
> The number of closed fixed bugs (54) is negligible compared to resolved
> fixed (908). I’d say that in our project, this is the closed fixed
> status that’s abnormal...
>

I agree that there appears to have been no policy to follow through on bug
transitions after reaching resolved state. I'm suggesting that we attempt
to agree on a policy and implement it, and I'm suggesting that we should
transition every bug to closed state.

If some devs prefer not to do this (e.g., because they don't see any need
to do so), I would be happy to perform the final steps as a service for the
group.


> I still don’t see what it brings you to close bugs? If we
> ‘automatically’ close them after 2 weeks have passed like you suggest
> below, then they wouldn’t be any more ‘verified’ than bugs that are
> simply ‘resolved’. ‘Verified’ implies that someone took out some steps
> to check that the bug was actually fixed, which wouldn’t be the case if
> it’s arbitrarily closed.
>

Ideally we would have sufficient resources to perform a separate
verification and review process for each resolved bug, after which the bug
is formally closed. However, we do not in have these resources, so that is
probably a more likely explanation for the current state of the FOP buglist.

I would suggest it is better to arbitrary close resolved bugs even if a
verification step has not been performed. This will be apparent from the
bug's history information, so it would be easy enough to go back and find
bugs that actually did go through the verified state.


> Are you trying to get a list of bugs that have been fixed since 1.0 was
> released?


Actually, it was fairly easy to do this by qualifying a search for
RESOLVED+FIXED with a condition that STATUS changed after 2010-07-20. The
search link I provided in my original posting above contained that
condition.


> Given that no attention is being paid to the ‘Version’ field,
> I don’t know how you can get that. Plus we may well have fixed bugs that
> were created at the time of 0.95, and not updated to include 1.0 after
> it was released, and if the bug was still present.
>

OK, that's a possibility.


> We can decide to be more diligent in managing our bugs database, but we
> would have to clean it up first, and given the number of open issues,
> that would be /a lot/ of work.
>

Actually, I very much want to clean up and triage our bug list. The task
I'm discussing now is just a first, and more innocuous step in this
process.


> In the meantime, we have a status.xml file at the root of the project
> that lists the issues that have been resolved, and that are worth
> mentioning in a release announcement. In my experience, this status.xml
> file is fairly well maintained, and can safely be relied upon. Much more
> safely than our Bugzilla, at any rate.


Understood. However, in the long term, I wonder if it is a good idea to
maintain two databases of changes. DRY. As an analogy, isn't this one of
the reasons that the use of @author is discouraged: because that
information is captured in SVN.

In any case, I'm not suggesting we eliminate status.xml, at least not any
time soon. Ideally, every status entry would make a reference to a bug #.
Most do (at least those changes since FOP1.0 release), but some do not. For
example, there a few "bug fix" entries that do not reference a bug #. I
expect this is because a committer noticed a bug and fixed it without
entering a bugzilla bug. I realize this takes a few more steps, but it
would be better for tracking purposes if *every* status entry referred to a
bug #.


> > I would prefer that we attempt to take the effort to allow the original
> > submitter to comment upon resolved+fix bugs and close the bug, and, if
> > after some time has passed (e.g., 2 weeks) without the submitter doing
> > this, then the fixer (or any committer) may close. One reason to do this
> is
> > that the original submitter may not agree that the fix actually fixes the
> > problem they reported.
>
> In which case they tend to react fairly quickly, and re-open the bug
> anyway. Sometimes (most of the time?) the original reporter is no longer
> involved, so it doesn’t really matter any more whether the bug has been
> fixed for them or not.
>

True.


> > If you or another committer prefers not to take the extra steps of
> closing
> > bugs you have fixed, then I would be happy to close them out so you don't
> > need to bother with it. Please let me know if you would like me to do
> this
> > for you.
>
> If I’m convinced that closing bugs brings us some benefit, I will
> certainly do it. ATM though, I still don’t see the interest. So yes, I’d
> be grateful if you could do that for me for the moment.
>

I understand you don't see a significant benefit at present; however, I see
sufficient benefit to do so, so if you don't mind, i'll go ahead and do the
closes for you and others that decline.

Regards,
G.

Re: resolved, fixed bugs since FOP1.0 that need to be closed

[Vincent Hennebert <vh...@gmail.com>]

On 28/03/12 17:39, Glenn Adams wrote:
<snip/>
> If we did have a full QA process, we would assign resolved bugs to someone
> to check and transition to verified state. Then one of the following would
> be designated to transition the bug to closed state: (1) original
> submitter, (2) fixer, (3) QA, or (4) PM.
> 
> Leaving a bug in resolved state (according to the fixer's perspective) does
> not close the loop on the bug (at least in my opinion). In fact, it remains
> an open bug as far as bugzilla is concerned, e.g., closed bugs are
> displayed in strike-out style, while resolved bugs are not.
> 
> The reason I am raising this now is because I am reviewing the bug list
> since the FOP 1.0 release in order to prepare information for a possible
> upcoming FOP 1.1 release. In doing this review, I found some bugs marked as
> resolved+fixed and others as closed+fixed. This makes it more difficult to
> compile and classify the status of bugs, and results in inconsistent views
> about the status of given bugs or FOP as a whole.

The number of closed fixed bugs (54) is negligible compared to resolved
fixed (908). I’d say that in our project, this is the closed fixed
status that’s abnormal...

I still don’t see what it brings you to close bugs? If we
‘automatically’ close them after 2 weeks have passed like you suggest
below, then they wouldn’t be any more ‘verified’ than bugs that are
simply ‘resolved’. ‘Verified’ implies that someone took out some steps
to check that the bug was actually fixed, which wouldn’t be the case if
it’s arbitrarily closed.

Are you trying to get a list of bugs that have been fixed since 1.0 was
released? Given that no attention is being paid to the ‘Version’ field,
I don’t know how you can get that. Plus we may well have fixed bugs that
were created at the time of 0.95, and not updated to include 1.0 after
it was released, and if the bug was still present.

We can decide to be more diligent in managing our bugs database, but we
would have to clean it up first, and given the number of open issues,
that would be /a lot/ of work.

In the meantime, we have a status.xml file at the root of the project
that lists the issues that have been resolved, and that are worth
mentioning in a release announcement. In my experience, this status.xml
file is fairly well maintained, and can safely be relied upon. Much more
safely than our Bugzilla, at any rate.


> I would prefer that we attempt to take the effort to allow the original
> submitter to comment upon resolved+fix bugs and close the bug, and, if
> after some time has passed (e.g., 2 weeks) without the submitter doing
> this, then the fixer (or any committer) may close. One reason to do this is
> that the original submitter may not agree that the fix actually fixes the
> problem they reported.

In which case they tend to react fairly quickly, and re-open the bug
anyway. Sometimes (most of the time?) the original reporter is no longer
involved, so it doesn’t really matter any more whether the bug has been
fixed for them or not.


> If you or another committer prefers not to take the extra steps of closing
> bugs you have fixed, then I would be happy to close them out so you don't
> need to bother with it. Please let me know if you would like me to do this
> for you.

If I’m convinced that closing bugs brings us some benefit, I will
certainly do it. ATM though, I still don’t see the interest. So yes, I’d
be grateful if you could do that for me for the moment.


Thanks,
Vincent

Re: resolved, fixed bugs since FOP1.0 that need to be closed

[Glenn Adams <gl...@skynav.com>]

On Wed, Mar 28, 2012 at 3:20 AM, Vincent Hennebert <vh...@gmail.com>wrote:

> On 28/03/12 09:58, mehdi houshmand wrote:
> >>
> >> I wouldn’t bother. Lacking of a proper QA process, we don’t use the
> >> ‘verified’ and ‘closed’ status and consider that a bug has been handled
> >> once its status has been changed to ‘fixed’.
> >>
> >> Vincent
> >>
> >
> >
> > Not sure I agree with you there Vincent. Giving a bug a "closed" status
> > allows us to perform queries, as Glenn has, to see what patches are left
> > outstanding and what needs to be applied.
>
> I don’t see what ‘closed’ brings you in this case. You can already,
> easily get the list of patches to be applied:
>
> https://issues.apache.org/bugzilla/buglist.cgi?list_id=81946;short_desc=patch;query_format=advanced;bug_status=NEW;bug_status=ASSIGNED;bug_status=REOPENED;bug_status=NEEDINFO;short_desc_type=allwordssubstr;product=Fop
>
> > It also gives creates a necessary
> > disparity between a [PATCH] which has "Resolved" and "Fixed" status, and
> > when that patch has been applied.
>
> Again, I don’t see what ‘closed’ brings you. A patch has been applied
> when its status has been changed to ‘resolved’.
>
> > Also, we are always going to lack the
> > "proper QA process" so I'm not sure that argument is valid.
>
> Who’s going to mark the issue as closed? The reporter? I don’t expect
> them to do that. The committer? This is an additional, unnecessary step
> to marking it as resolved.
>
> Really, I don’t see what we can get out of this.
>

If we did have a full QA process, we would assign resolved bugs to someone
to check and transition to verified state. Then one of the following would
be designated to transition the bug to closed state: (1) original
submitter, (2) fixer, (3) QA, or (4) PM.

Leaving a bug in resolved state (according to the fixer's perspective) does
not close the loop on the bug (at least in my opinion). In fact, it remains
an open bug as far as bugzilla is concerned, e.g., closed bugs are
displayed in strike-out style, while resolved bugs are not.

The reason I am raising this now is because I am reviewing the bug list
since the FOP 1.0 release in order to prepare information for a possible
upcoming FOP 1.1 release. In doing this review, I found some bugs marked as
resolved+fixed and others as closed+fixed. This makes it more difficult to
compile and classify the status of bugs, and results in inconsistent views
about the status of given bugs or FOP as a whole.

I would prefer that we attempt to take the effort to allow the original
submitter to comment upon resolved+fix bugs and close the bug, and, if
after some time has passed (e.g., 2 weeks) without the submitter doing
this, then the fixer (or any committer) may close. One reason to do this is
that the original submitter may not agree that the fix actually fixes the
problem they reported.

If you or another committer prefers not to take the extra steps of closing
bugs you have fixed, then I would be happy to close them out so you don't
need to bother with it. Please let me know if you would like me to do this
for you.

G.

Re: resolved, fixed bugs since FOP1.0 that need to be closed

[Vincent Hennebert <vh...@gmail.com>]

On 28/03/12 09:58, mehdi houshmand wrote:
>>
>> I wouldn’t bother. Lacking of a proper QA process, we don’t use the
>> ‘verified’ and ‘closed’ status and consider that a bug has been handled
>> once its status has been changed to ‘fixed’.
>>
>> Vincent
>>
> 
> 
> Not sure I agree with you there Vincent. Giving a bug a "closed" status
> allows us to perform queries, as Glenn has, to see what patches are left
> outstanding and what needs to be applied.

I don’t see what ‘closed’ brings you in this case. You can already,
easily get the list of patches to be applied:
https://issues.apache.org/bugzilla/buglist.cgi?list_id=81946;short_desc=patch;query_format=advanced;bug_status=NEW;bug_status=ASSIGNED;bug_status=REOPENED;bug_status=NEEDINFO;short_desc_type=allwordssubstr;product=Fop


> It also gives creates a necessary
> disparity between a [PATCH] which has "Resolved" and "Fixed" status, and
> when that patch has been applied.

Again, I don’t see what ‘closed’ brings you. A patch has been applied
when its status has been changed to ‘resolved’.


> Also, we are always going to lack the
> "proper QA process" so I'm not sure that argument is valid.

Who’s going to mark the issue as closed? The reporter? I don’t expect
them to do that. The committer? This is an additional, unnecessary step
to marking it as resolved.

Really, I don’t see what we can get out of this.


> Mehdi

Vincent

Re: resolved, fixed bugs since FOP1.0 that need to be closed

[mehdi houshmand <me...@gmail.com>]

>
> I wouldn’t bother. Lacking of a proper QA process, we don’t use the
> ‘verified’ and ‘closed’ status and consider that a bug has been handled
> once its status has been changed to ‘fixed’.
>
> Vincent
>


Not sure I agree with you there Vincent. Giving a bug a "closed" status
allows us to perform queries, as Glenn has, to see what patches are left
outstanding and what needs to be applied. It also gives creates a necessary
disparity between a [PATCH] which has "Resolved" and "Fixed" status, and
when that patch has been applied. Also, we are always going to lack the
"proper QA process" so I'm not sure that argument is valid.

Mehdi

Re: resolved, fixed bugs since FOP1.0 that need to be closed

[Vincent Hennebert <vh...@gmail.com>]

On 28/03/12 07:23, Glenn Adams wrote:
> I just noticed that there are 83 bugs [1] that, since the FOP 1.0 release
> (2010-07-20), have been marked as *resolved* and *fixed*, but have not been
> changed to *closed* status.
> 
> [1]
> https://issues.apache.org/bugzilla/buglist.cgi?list_id=81930;resolution=FIXED;chfieldto=Now;query_format=advanced;chfield=bug_status;chfieldfrom=2010-07-20;bug_status=RESOLVED;product=Fop
> 
> I could change all these to closed, but it would be better if those who
> filed or fixed the bug would do this in order to ensure that there is
> proper closure, with any verification they think is needed.

I wouldn’t bother. Lacking of a proper QA process, we don’t use the
‘verified’ and ‘closed’ status and consider that a bug has been handled
once its status has been changed to ‘fixed’.

Vincent