emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: debbugs tracker builds character


From: Eric Abrahamsen
Subject: Re: debbugs tracker builds character
Date: Fri, 22 Jul 2016 06:50:24 -0400
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/25.1.50 (gnu/linux)

Eric Abrahamsen <address@hidden> writes:

> Stefan Monnier <address@hidden> writes:
>
>> 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.
>>
>> So, we could start by setting up a Gitlab or Kallithea instance for
>> Emacs and use it for pull-requests, while we keep using Debbugs for
>> issue tracking.
>>
>> This lets us move forward on the pull-request and code-review front
>> without having to solve the "issue" of switching to another bug-tracker.
>>
>> 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.
>>
>> I also like this idea.  Patches welcome,
>
> Here's a patch. I hope I've used all the proper utility functions for
> finding libraries and extracting headers.
>
> So far as I can tell, debbugs doesn't keep track of "bug subscriptions",
> and putting the package maintainer in the Cc header is all we need to
> do, right?
>
> Anyhow, I'm sure this will require tweaking, but take a look and let me
> know.
>
> Also, I've included a second patch to `lm-maintainer', which is (I hope)
> a fairly minor fix.

Please ignore this second patch, this was a brain fart.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]