Proposed change to development Process was Fw: [Bug 650598] Cannot Enter Nth Day of Month Scheduled Transactions

[Geert Janssens]

On 07-02-13 16:35, John Ralls wrote:
> On Feb 7, 2013, at 7:21 AM, David Carlson <carlson.dl at sbcglobal.net> wrote:
>
>> As I requested in this closed bug, which is not in the current program release and may not be in the current release for many more months, how about adding a status "Awaiting next Program Release" so the bug can be found in a search for unresolved bugs?
>>
>> This should reduce duplicate bug reports.
>>
> It might, but we don't control bugzilla, gnome.org's "Bug Squad" [1] does. We don't have the privs to modify the workflow.
>
> Regards,
> John Ralls
>
> [1] https://live.gnome.org/Bugsquad/
> _______________________________________________
> gnucash-devel mailing list
> gnucash-devel at gnucash.org
> https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Hmm, that's true and it shows that Gnome's bugzilla configuration is 
more oriented towards developers than it is to users. Or that may rather 
be a bugzilla trait in general. I must add that most developers I know 
don't seem to mind bug duplicates for already closed bugs. They usually 
prefer a duplicate over a bug not being reported. I can imagine on the 
other hand that users may get uncomfortable when they first carefully 
searched for an existing bug, didn't find one, submitted a new bug, only 
to find it being closed immediately as a duplicate. So there certainly 
is friction in this area.

Personally I often use Google instead of bugzilla's search feature when 
searching for bugs in projects where I'm just a user (like Red Hat's 
bugzilla for Fedora). Both can search for closed bugs, but it's my 
impression that Google's search capabilities are more advanced. It seems 
to have a better ranking system that tends to bring the more relevant 
bugreports closer to the top than bugzilla does.

 From there I can then quickly see in which (pending) release my bug has 
been fixed. Of course that assumes someone has taken the time to mark 
the release for which a given bug is fixed. I try to make it a habit to 
update the Target Milestone field when I close bugs for GnuCash for this 
purpose.

In the short term there isn't much we can do to improve this I think. 
But we could brainstorm for improvements in the long run.

What we have now is that users are encouraged to search the bugzilla 
database for existing reports before submitting a new one. By default 
bugzilla only searches for open bugs, so most users never search in the 
closed bugs. So we need
- either an additional search query to find closed bugs for unreleased 
software. A query on all closed bugs would not be useful because a user 
would get lost in the large quantity of closed bugs.
- or a mechanism to mark bugs as fixed without closing them. Something 
like David more or less proposed. That would keep the bugs visible in 
the default search query for users and yet would make it easy for 
developers to search for bugs that still require some attention.

I'm not sure if bugzilla can reliably be queried like the first option 
suggests. It would at least require some indication in bugzilla to show 
for which release (roughly milestones in bugzilla speak) a bug was 
closed. I doubt this has been done consistently for all bugs related to 
GnuCash. Secondly it would take a rather advanced query that has to be 
updated for each release we do. Bugzilla allows for saved queries but 
only on the user level, not the global level, let alone on the project 
level. So if we go this route we'd have to store the query somewhere in 
our own infrastructure like our bugzilla wiki page. While it can be 
useful to add some smart predefined queries there in general, it won't 
be a strong solution for the issue David raised here.

And that's only the technical aspect. For it to work it requires 
changing the habits of both users and developers: developers have to 
consistently set a release marker for each bug fixed, users must be 
trained to go to our bugzilla wiki first and start from the predefined 
queries there. Challenging to say the least.

The second option may be more workable. It only requires changes on the 
developers' side, not the users' side. For starters it's true we can't 
add another status option in Gnome's bugzilla. But there are other ways 
to indicate a bug is fixed but not released yet. The most simple one I'm 
thinking of is changing the bug's title. Like for example add a prefix 
"FPR", meaning "Fixed, pending release".

Drawback is again that all developers have to do this to make it work. 
On the bright side we could use tools to support this process and 
perhaps even automate part of it. I'm thinking for example of tighter 
integration between bugzilla and git using the git-bz tool and a clever 
set of special markers in the commit messages (similar to the BP commit 
marker we currently use).

Just a rough concept:
- Install git-bz on code.gnucash.org
- Add code in the post-receive hook to parse commit messages for pushed 
commits (which I ironically didn't feel like doing for the BP/AUDIT 
feature, but that was for several reasons, not all related to the code ;)
- If it finds certain markers related to a bugzilla bug, update that bug 
accordingly

This would at least require a marker in the commit message to inform the 
script that a bug is involved, for example "Bug 650598". That is the 
trigger for the script to do something with this commit related to the bug.

With no additional markers, at least the hook could add the commit 
summary to the bug. So all subscribers to the bug get informed a commit 
related to the bug was made.

With an additional marker (say "Fixed") the script would know it should 
update the bug's subject to mark it fixed. Optionally it also sets the 
target milestone. Perhaps the script could use some logic to determine 
in which release the fix will be expected or perhaps the user will have 
to mark this explicitly, like "Fixed [in] 2.4.12", "Fixed 2.5.0",... 
Those are design decisions to make whenever the idea is closer to 
realisation.

A final icing on the cake (is that how you say it in English?) would be 
that during the release process a single command would actually close 
all the bugs marked in this way. Obviously that can only be done if we 
manage to set target milestones consistently. Perhaps this can be 
triggered in the hook, when a release is tagged. The hook could scan for 
tag commits in which the comment has markers like "Release 2.5.0",...

Drawbacks so far:
- requires some serious modifications of the hook script
- developers still have to add the proper markers in their commit messages

That's it for the current brainstorm. Obviously this will require more 
thought and testing to make sure we're not actually creating more work 
instead of simplifying things for both users and developers.

Geert