On 07-02-13 16:35, John Ralls wrote:
On Feb 7, 2013, at 7:21 AM, David Carlson <carlson...@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@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
_______________________________________________
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
