Re: debbugs tracker builds character

[Ted Zlatanov]

On Wed, 20 Jul 2016 12:56:54 -0400 Stefan Monnier <address@hidden> wrote: 

>> IMHO that's not an actual requirement. It's an implementation detail.
SM> I think at the time, working similarly to the old bug-gnu-emacs
SM> mailing-list was a clear desire.

SM> And I think it's probably still the case that we'd want our bug-tracker to
SM> be usable via email for those who want to (tho it's probably OK if only
SM> the main functions are available via this UI).

>> The actual requirement was probably about disconnected operation or
>> something like that.

SM> Yes, I agree that this is the crucial point.  That's my motivation for
SM> developing BugIt (https://gitlab.com/monnier/bugit).

SM> I haven't had much time to devote to it lately, tho, so it's stuck at
SM> the stage of "proof of concept" right now.

I'm not against a custom solution, but it's hard to justify the cost and
effort compared to something more standard. Do you think BugIt can
provide the features we've mentioned at some point?

>> The bug tracker should be aware of repositories, branches, commits,
>> contributors, and ticket links or mentions in commit messages.

SM> I've never seen a bug-tracker do anything really useful with those
SM> (other than what you can get by embedding URLs in the bug
SM> description/discussion), so I'd be interested to hear more (tho it could
SM> be difficult to retro-fit it into BugIt since BugIt is designed to be
SM> fundamentally an issue/ticket-tracking system not necessarily related to
SM> "code" or to any kind of VCS repository).

Well, clearly the level of integration can vary. JIRA for instance
doesn't have the deep Github integration that Github's issue tracker
offers, but it's also more flexible. People have written thick books on
these topics.

For me personally, if I can *see* the specific code that fixes a ticket
inside the ticket as a commit, and click my way to the wider commit and
then diff from before that commit against today's state of that code,
I've built a mental map of the code that would otherwise take me a lot
of work. That's one common workflow. Another is to view several commits
that fix a single ticket in one place. So it's not revolutionary, just
simpler and more straightforward for the user.

>> Contributors should be able to tag and notify each other.

SM> You mean to (re)assign bugs to particular persons and things like that?

Yes, plus ping someone or a team specifically: "hey, maybe the @gnus
team should look at this" in a comment.

>> Inline code comments should be easy, and linked to a commit (so an
>> updated commit can resolve the comment).

SM> How do you "update a commit"?  What does "resolve a comment" mean?

Rebase or amend+force push would update a branch destructively, which in
a pull request context should show you that a comment was for a commit
that's no longer in the branch. Furthermore some trackers allow you to
mark a comment as resolved (e.g. Github recently added reactions, which
can be used as ad-hoc markup).

The next link in the chain are CI/CD hooks. You can set up a Github
repo, for instance, to build every pull request before the reviewer ever
looks, which saves a lot of time with compiled languages. It will run
tests and so on, but most important is that it keeps the context inside
the pull request, you don't have to go elsewhere.

>> I think this is not something you can solve with patches or good UI.
>> It requires a tool architected correctly from the start.  Such tools
>> exist aplenty.

SM> Do you have a recommendation of something you consider well-designed
SM> (not necessarily for Emacs's use, so I could look at it)?

Github, Gitlab, BitBucket come immediately to mind as highly integrated
environments that could host Emacs development. But they all have
drawbacks you know. Gitlab seems closest to "acceptable" for the Emacs
team but it's not GPL:
https://gitlab.com/gitlab-org/gitlab-ce/blob/master/LICENSE

Ted