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

[John Ralls]

On Feb 8, 2013, at 3:30 AM, Geert Janssens <janssens-geert at telenet.be> wrote:

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

The target milestone is actually intended for *open* bugs, to create a "roadmap" report which lists all of the bugs which are supposed to be fixed before a particular release. 

Here's an interesting factoid: Even though the Bugzilla workflow shows a "closed" phase after verified, it doesn't seem to actually exist. The "All Closed Bugs" report shows Resolved and Verified bugs, not closed, and if one goes to a Verified bug and clicks on the status listbox, the choices are Verified, Resolved, and Reopened (at bugzilla.gnome.org; newer versions of bugzilla have changed the workflow).

None of which is particularly germane to the matter at hand. 

I'm not very enthusiastic about an automated process which relies on parsing arcana from commit messages. That's way to easy to screw up, and there's no feedback until it's pushed to the main repository and thus too late. I suppose we could have a commit hook in everyone's private repos that "compiles" the commit message and blocks the commit if it's close-but-not-quite-right, but that doesn't do anything for me if I've forgotten to include the bug information at all, and it's not going to know that I transposed the last two digits of the bug number.

I'll also note that git-bz seems mostly aimed at attaching a commit as a patch to a bug. It would take some extending to do what you're proposing. 

Regards,
John Ralls