From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Ted Zlatanov Newsgroups: gmane.emacs.devel Subject: Re: debbugs tracker builds character Date: Wed, 20 Jul 2016 13:54:57 -0400 Organization: =?utf-8?B?0KLQtdC+0LTQvtGAINCX0LvQsNGC0LDQvdC+0LI=?= @ Cienfuegos Message-ID: <87eg6o8aa6.fsf@lifelogs.com> References: <4hd1rw1ubr.fsf@fencepost.gnu.org> <83vb50wxhv.fsf@gnu.org> <87y49vz4cg.fsf@acer.localhost.com> <87twg2g86g.fsf@lifelogs.com> <83eg76n5h5.fsf@gnu.org> <87y45eeoor.fsf@lifelogs.com> <577D42BB.1020500@cs.ucla.edu> <87oa694rfw.fsf@russet.org.uk> <837fcxlbay.fsf@gnu.org> <87lh1d2wg5.fsf@russet.org.uk> <83eg75jk5h.fsf@gnu.org> <87lh1cb6p0.fsf@lifelogs.com> <87oa5sa176.fsf_-_@lifelogs.com> <874m7kmkcm.fsf@gmx.de> <87zipc8gx2.fsf@lifelogs.com> Reply-To: emacs-devel@gnu.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1469040722 15462 80.91.229.3 (20 Jul 2016 18:52:02 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 20 Jul 2016 18:52:02 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Jul 20 20:51:53 2016 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1bPwb1-0007pS-OW for ged-emacs-devel@m.gmane.org; Wed, 20 Jul 2016 20:51:52 +0200 Original-Received: from localhost ([::1]:36429 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bPwb1-0002t0-0q for ged-emacs-devel@m.gmane.org; Wed, 20 Jul 2016 14:51:51 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:50519) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bPviG-0003xo-5j for emacs-devel@gnu.org; Wed, 20 Jul 2016 13:55:17 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bPviB-0001Ar-4K for emacs-devel@gnu.org; Wed, 20 Jul 2016 13:55:15 -0400 Original-Received: from plane.gmane.org ([80.91.229.3]:59851) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bPviA-0001AH-Pm for emacs-devel@gnu.org; Wed, 20 Jul 2016 13:55:11 -0400 Original-Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1bPvi4-0003mb-OQ for emacs-devel@gnu.org; Wed, 20 Jul 2016 19:55:04 +0200 Original-Received: from c-98-229-60-157.hsd1.ma.comcast.net ([98.229.60.157]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 20 Jul 2016 19:55:04 +0200 Original-Received: from tzz by c-98-229-60-157.hsd1.ma.comcast.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 20 Jul 2016 19:55:04 +0200 X-Injected-Via-Gmane: http://gmane.org/ Mail-Followup-To: emacs-devel@gnu.org Original-Lines: 84 Original-X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: c-98-229-60-157.hsd1.ma.comcast.net X-Face: bd.DQ~'29fIs`T_%O%C\g%6jW)yi[zuz6; d4V0`@y-~$#3P_Ng{@m+e4o<4P'#(_GJQ%TT= D}[Ep*b!\e,fBZ'j_+#"Ps?s2!4H2-Y"sx" Mail-Copies-To: never User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.1.50 (gnu/linux) Cancel-Lock: sha1:LOe4GCwX1SeaZTJvUdhmJ4rr72k= X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 80.91.229.3 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.org gmane.emacs.devel:205908 Archived-At: On Wed, 20 Jul 2016 12:56:54 -0400 Stefan Monnier 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