Re: debbugs tracker builds character

[Ted Zlatanov <tzz@lifelogs.com>]

On Wed, 20 Jul 2016 20:48:07 +0200 Michael Albinus <michael.albinus@gmx.de> wrote: 

MA> Anyway, I believe this ship has sailed years ago. If somebody wants to
MA> replace debbugs, (s)he must do heavy lobbying for it. Don't know whether
MA> it could succeed, and whether it is worth the trouble. The better
MA> approach seems to be to exploit debbugs to its best. IMO.
...
MA> <http://thread.gmane.org/gmane.emacs.devel/60833/focus=60976>

MA> That thread is the 10 years old discussion on emacs-devel, which ended
MA> up in deciding for debbugs. And I find the reasoning for using email
MA> still convincing.

I don't care about the underlying bug tracker as much as I care about
getting things done. This is my underlying reason to start a discussion.

(Right now, I can set up an Emacs mirror on Github, do a pull request
there and accept comments there. It would work great and I can merge the
branch back into the Emacs Git repo. The only reason I haven't is
political: I believe the maintainers should guide the tool choices.)

>> The bug tracker should be aware of repositories, branches, commits,
>> contributors, and ticket links or mentions in commit messages.
>> Contributors should be able to tag and notify each other. Markdown etc.
>> should be well supported. Inline code comments should be easy, and
>> linked to a commit (so an updated commit can resolve the comment). This
>> is just the essential stuff.

MA> Some of this exist already (tags), maybe underdocumented. For the rest I
MA> must at least sleep one night :-)

It's hard to do the things I listed (especially VCS integration) with
the current Emacs bug tracker. These things were not so important 10
years ago. I think as a team, we have to be willing to reassess our tool
choices at least every 10 years (e.g. Bazaar and then Git were major
tool changes but didn't change the Emacs project).

As a practical choice, I'd rather lobby to use better tools than to
write them ourselves: it wastes resources, and I don't think bug and
issue tracking is our strongest area. I'd rather have you (Michael and
others) get some sleep or work on Emacs itself.

MA> A practical counter-argument: do you believe that debbugs is *such* bad
MA> that the vast majority of Emacs developers will follow you for a new bug
MA> tracker? I'm not a debbugs missionary, but in my daily work I found it
MA> sufficient. Somehow.

Well, I'm partly basing my view on the vitality of ELPA packages on
Github. There are hundreds (some end up on the GNU ELPA, some hosted
elsewhere). I've contributed to several like
https://github.com/Silex/docker.el and
https://github.com/flycheck/flycheck and the process is better for the
reasons I've described.

Will the Emacs developers follow me? I'd love to see them use a better
process. I'm happy to concede I'm wrong and the current process works
fine, but the evidence leads me to believe it can be improved with
better tools (similar to the evidence in favor of Git when we were using
Bazaar). I'm not going to spend the next 6 months talking about it; I'd
rather know if the maintainers (Eli and John) and other core developers
are willing to consider Gitlab or something similar. I think I've stated
the case clearly, and quite a few of us have experience with more
powerful bug/issue trackers so we know what we're missing.

If the decision is "no, we'll move on with whatever marginal
improvements to debbugs we can make" then I'll come back to the topic in
another 10 years :)

On Wed, 20 Jul 2016 16:43:08 -0400 Stefan Monnier <monnier@iro.umontreal.ca> wrote: 

>>> Yes, I agree that this is the crucial point.  That's my motivation for
>>> developing BugIt (https://gitlab.com/monnier/bugit).
>> IMHO it's not that important a goal. The old-timers have lived without it
>> for a while, and the youngsters have no idea that it's something to
>> be desired.

SM> The more I use BugIt, the more I find it important to be able to query
SM> the bug database while offline.  Being able to queue actions so they're
SM> executed when I get online is not too terrible, but it's not really
SM> good enough.

I don't disagree entirely, but in 2016 disconnected operation is much
less common than in 2006. There are tools that can synchronize database
replicas seamlessly. Fundamentally, though, I think the focus of bug and
issue tracking has shifted from individuals working on fixes, to teams
collaborating and reviewing each other's work, with the ability to
include and notify the entire community. IMHO this is the true value in
Github and its competitors, and the biggest reason why they've seen so
much adoption.

On Wed, 20 Jul 2016 16:40:01 -0400 Stefan Monnier <monnier@iro.umontreal.ca> wrote: 

SM> I think I'm starting to see what you mean.  You're talking about a tight
SM> integration where a pull-request is also itself an issue, so the comments
SM> can be directly on the patch itself.  As opposed to having issues and
SM> pull-request be two separate things that can refer to each other via
SM> an indirection.

Yes. Actually Github has both of these right now. When pull requests are
not true issues, they tend to be associated with issues: sometimes
1-to-N and sometimes N-to-1. People have different workflows, so it's
good to have flexibility built into the model. Sorry if this seems
ambivalent; it's really a degree of creative freedom that users
appreciate.

On Wed, 20 Jul 2016 17:25:33 -0400 Eric Abrahamsen <eric@ericabrahamsen.net> wrote: 

EA> A suggestion from a part-time package maintainer: make
EA> `report-emacs-bug' prompt for a package, and offer the results of
EA> `featurep' as completion. If the user picks a package that only exists
EA> in ELPA, email the package maintainer with the bug report.

That's a really good suggestion, regardless of the underlying bug tracker.

Thanks for the thoughtful comments
Ted