Re: In support of Jonas Bernoulli's Magit

[Phillip Lord]

On Sat, July 8, 2017 6:57 am, Eli Zaretskii wrote:
>> From: address@hidden (Phillip Lord)
>> Date: Fri, 07 Jul 2017 23:08:52 +0100
>> Cc: address@hidden, address@hidden, Ken Manheimer
>> <address@hidden>,
>> address@hidden
>> 1) Get list of all contributors/contributor emails
>> 2) Email assign with full list to find out who needs doing
>> 3) Email each person with new debugs ticket
>> 4) One of:
>> address@hidden cc's electronic communication to debbugs address@hidden
>> acknowledges paper communication *in either direction* to debbugs.
>> assign would probably need to attach an ID number to outgoing assignment
>> forms.
>
> There's no need to rely on the FSF assignment clerk for tracking this
> process: you can ask me to do that instead.  I see all the steps of
> this process in my email inbox anyway, whether I want it or not.

No this is no good. If I am going to do this, I want notifications -- push
not pull. So, there needs to be a way to open this up beyond maintainers.

Having a system to maintain links to the package we are trying to get
assignment for would be good. Currently, we are talking about assignment
for Emacs, of course, but knowing that we are asking for assignment wrt to
magit, rather than any other package, would be helpful.

Having something which handles something like blocking would be nice also.
i.e. we start a bug wrt to magit for assignment, then all the assignment
requests would be blockers. Then we would know when we are finished.




>
> In general, people who bump into bureaucratic impediments related to
> GNU or FSF should ask for help.  Making this better/easier is part of
> my and John's duties, and we have access to resources others don't. You
> shouldn't need to try to solve these problems alone.
>
>> If you will get someone to set up debbugs to support this, help with
>> using it, and get address@hidden to buy into the process, I will test it out
>>  with the new assignments need to update dash. If you and GNU are
>> bought into improving the process, we can refine the details overtime.
>
> FWIW, I don't want this to be handled via debbugs, as debbugs is
> terribly unhelpful in little things that sometimes just make me mad.
> Having to cope with it for handling bug reports is bad enough.

I would agree. I don't like debbugs either. But, given the length of time,
for example, it has taken to discuss CI or project hosting alternatives,
it has the advantage of already existing.

Phil