Another others for maintainer?

Another others for maintainer?

[John Wiegley]

Since the earlier thread on "New maintainer" turned into a massive discussion,
it may have stifled the opportunity for others to volunteer as the new Emacs
maintainer.

My own qualifications are by no means ideal. First and foremost, there is a
potential for friction with the FSF; and second, I may not have the time to
give this position the attention it deserves.

So if anyone else would like to drive Emacs forward into the future, please
speak up! We need more diverse options if we are to make a good choice.

John

Re: Another others for maintainer?

[David Kastrup]

"John Wiegley" <johnw@newartisans.com> writes:

> Since the earlier thread on "New maintainer" turned into a massive
> discussion, it may have stifled the opportunity for others to
> volunteer as the new Emacs maintainer.
>
> My own qualifications are by no means ideal. First and foremost, there
> is a potential for friction with the FSF; and second, I may not have
> the time to give this position the attention it deserves.
>
> So if anyone else would like to drive Emacs forward into the future,
> please speak up! We need more diverse options if we are to make a good
> choice.

Like with our views about how multiple maintainers can arrive at a
single decision, it appears to me like the thrust of this discussion was
not as much "making a good choice" but "converging to a good choice":
the choices after the discussion are different because the people after
the discussion are different.

To me this was mostly about "can we make ends meet?" and I tried putting
the spotlight on those ends so that we deal with this realistically and
don't set up ourselves for obvious failure.  And the answer appears to
me "it's definitely worth trying".  Not more, not less.  I see enough
willingness on all sides to make this work that I don't see much of a
point in not trying it.

Of course, I cannot speak for anyone but myself here.

-- 
David Kastrup

Re: Another others for maintainer?

[Nicolas Petton]

[-- Attachment #1: Type: text/plain, Size: 586 bytes --]

John Wiegley <johnw@newartisans.com> writes:

> Since the earlier thread on "New maintainer" turned into a massive discussion,
> it may have stifled the opportunity for others to volunteer as the new Emacs
> maintainer.
>
> My own qualifications are by no means ideal. First and foremost, there is a
> potential for friction with the FSF; and second, I may not have the time to
> give this position the attention it deserves.

You would be a great maintainer I think.  And while I can't volunteer
for the position, I'd be glad to help and could very well take care of
some tasks.

Nico

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 512 bytes --]

Re: Another others for maintainer?

[John Wiegley]

>>>>> Nicolas Petton <nicolas@petton.fr> writes:

> You would be a great maintainer I think. And while I can't volunteer for the
> position, I'd be glad to help and could very well take care of some tasks.

Thanks, Nico and David, for the support.

The thing is, *I* want better options to choose from. As those who follow my
free software developments well know, I become distracted easily. And when
work ramps up near a deadline, my volunteer contributions often come to a
halt.

Emacs deserves someone with a bit more time and energy. I'm happy to
participate in the "meta" role I have been over the past couple weeks, but
that may be the best I can offer with any consistency.

John

Re: Another others for maintainer?

[Dmitry Gutov]

On 10/20/2015 06:25 PM, John Wiegley wrote:

> Emacs deserves someone with a bit more time and energy. I'm happy to
> participate in the "meta" role I have been over the past couple weeks, but
> that may be the best I can offer with any consistency.

We might have to face the fact that the current emacs-devel regulars 
already have enough on their plates, and most people who usually stay 
out, are unlikely to suddenly ramp up their involvement.

Re: Another others for maintainer?

[Nicolas Petton]

[-- Attachment #1: Type: text/plain, Size: 1213 bytes --]

John Wiegley <johnw@newartisans.com> writes:

>>>>>> Nicolas Petton <nicolas@petton.fr> writes:
>
>> You would be a great maintainer I think. And while I can't volunteer for the
>> position, I'd be glad to help and could very well take care of some tasks.
>
> Thanks, Nico and David, for the support.
>
> The thing is, *I* want better options to choose from. As those who follow my
> free software developments well know, I become distracted easily. And when
> work ramps up near a deadline, my volunteer contributions often come to a
> halt.
>
> Emacs deserves someone with a bit more time and energy. I'm happy to
> participate in the "meta" role I have been over the past couple weeks, but
> that may be the best I can offer with any consistency.

The thing is, doing all of the work Stefan has been doing is obviously a
lot, that's why I'm offering to help, and focusing on specific tasks
would make that easier (like the release process).

Also, Eli has been doing a wonderful job, he's dealing with issues in
the bug tracker really well for instance, and is obviously dedicating a
lot of time maintaining Emacs already.  Together, I think you'd be a
great team, if he was willing to be co-maintainer.

Nico

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 512 bytes --]

Re: Another others for maintainer?

[Jay Belanger]

Nicolas Petton <nicolas@petton.fr> writes:
...
> Also, Eli has been doing a wonderful job, he's dealing with issues in
> the bug tracker really well for instance, and is obviously dedicating a
> lot of time maintaining Emacs already.

Yes; Eli has always done a great job with Emacs.  Has he weighed in on
his willingness to be a (co)maintainer?

Re: Another others for maintainer?

[Eli Zaretskii]

> From: Jay Belanger <jay.p.belanger@gmail.com>
> Date: Tue, 20 Oct 2015 11:18:30 -0500
> Cc: jay.p.belanger@gmail.com
> 
> Yes; Eli has always done a great job with Emacs.

Thanks.

> Has he weighed in on his willingness to be a (co)maintainer?

No, he hasn't.  Primarily because I don't know what is expected of a
(co)maintainer that I don't already do.  If the answer is NOTHING,
then you already have me, albeit unannounced.  In that case, I can
give up the title.

I also have serious doubts it's a good idea to upgrade my status in
any serious ways.  "A man's got to know his limitations"; here are
some of mine:

  . I know too little about some very important core parts of Emacs,
    so little that I will be unable to make decisions about changes
    there.

  . I have very little time to work on Emacs.  E.g., I will probably
    be unable to track the commits the way Stefan did (see also
    previous item), and can only review maybe one or 2 patches per
    day, sometimes none.  That's no way of keeping the QA standards
    high enough.  I'm not even sure my Lisp instincts are good enough
    for serious reviews of large non-trivial packages.

  . I tend to annoy some people, for reasons that I honestly don't
    understand (the latest episode is still unwinding here -- and also
    on IRC, I'm told).  My ideas are frequently rejected.  That's not
    a good starting point for leadership.

'Nough said.

Re: Another others for maintainer?

[Rasmus]

Eli Zaretskii <eliz@gnu.org> writes:

>   . I tend to annoy some people, for reasons that I honestly don't
>     understand (the latest episode is still unwinding here -- and also
>     on IRC, I'm told).  My ideas are frequently rejected.  That's not
>     a good starting point for leadership.

I find you quite reasonable, if not admirable.  Thanks for your hard work,
Eli!  it’s appreciated — at least by me.

Rasmus

-- 
To err is human. To screw up 10⁶ times per second, you need a computer

Re: Another others for maintainer?

[John Wiegley]

>>>>> Eli Zaretskii <eliz@gnu.org> writes:

> No, he hasn't. Primarily because I don't know what is expected of a
> (co)maintainer that I don't already do. If the answer is NOTHING, then you
> already have me, albeit unannounced. In that case, I can give up the title.

I have a strong feeling that in the future, we will need to become a more
distributed team, in terms of responsibility. The days of one overarching
maintainer who knows all and does all are, I think, now over.

My ideal scenario is this:

 - I'm willing to act as "project manager" in the non-technical sense. That
   is, charting the course, working with contributors, planning releases,
   keeping an eye on matters of concern, liaising with the FSF. This is a
   pleasant role for me, and doesn't require daily output.

 - Eli -- without whom even *imagining* this would be impossible -- would
   become our primary technical lead, the person I rely on most to keep the
   ship aright and stay on top of bug submissions and patches.

Eli and I, in turn, would start assigning responsibilities and delegating to
others, until we have a distributed team of hopefully 10-20 people, each with
their own time, energy, experiences and expertise. For example, asking Sacha
Chua to help us stay on top of community affairs.

"Many hands make light work", and I think these hands will be the only way we
can successfully move forward, given that we don't have Stefan Monniers or
Gerd Moellmann's jumping out of the woodwork these days.

My hope is that rather than having people like Eli stop contributing due to
burnout, we'll be able to support them with a steady influx of new blood. It's
just a matter now of finding those people. Maintainership should really be a
community burden, but with just enough hierarchy that we don't become stalled
by indecision.

John

Re: Another others for maintainer?

[Eli Zaretskii]

> From: "John Wiegley" <johnw@newartisans.com>
> Date: Tue, 20 Oct 2015 16:44:00 -0700
> Cc: jay.p.belanger@gmail.com, emacs-devel@gnu.org
> 
> My ideal scenario is this:
> 
>  - I'm willing to act as "project manager" in the non-technical sense. That
>    is, charting the course, working with contributors, planning releases,
>    keeping an eye on matters of concern, liaising with the FSF. This is a
>    pleasant role for me, and doesn't require daily output.
> 
>  - Eli -- without whom even *imagining* this would be impossible

Thanks, but you make this sound like if tomorrow I'm overrun by a bus,
Emacs will die, or at least stagnate.  Which of course is not true.
There are quite a few people here without whom Emacs development would
not have been what it is, let alone what it (hopefully) will be.

>                                                                   -- would
>    become our primary technical lead, the person I rely on most to keep the
>    ship aright and stay on top of bug submissions and patches.

If you don't have enough time to actively engage in technical issues,
like discussing development and design/implementation decisions,
reviewing patches, fixing bugs, etc. -- then the above scenario is not
viable.  There's no chance in the world I alone will be able to deal
with that workload: I have neither the time nor knowledge (nor talent,
to be honest) to do that.  So we will need at least some of the team
you describe here:

> Eli and I, in turn, would start assigning responsibilities and delegating to
> others, until we have a distributed team of hopefully 10-20 people, each with
> their own time, energy, experiences and expertise.

We need this as a _prerequisite_ for announcing that the new
maintenance team is in place and has assumed its responsibilities.
Without them, this simply won't work; we shouldn't even try.

10-20 people is probably an ambitious goal, but at least around 5 is
IMO the necessary minimum.  Those individuals will have to agree to be
part of the team, ideally also tell which areas they would like (or
consider themselves able) to be responsible for, so that many (most?)
issues will have a clear addressee in the team.

Lack of hands is crucial here.  If we don't collect enough hands to
routinely and efficiently perform the day-to-day duties -- reviewing
and approving patches, analyzing bugs, writing documentation -- we
will never be able to sustain the intensity and pace of development
we'd like to have.

P.S. I think many people don't realize how many simple, mundane tasks
are part of what we call "Emacs maintenance".  Stuff like fixing
spelling errors, committing auto-generated files, fixing unsafe or
sub-optimal code revealed by compiler warnings, closing bugs that were
resolved but left open, merging bug reports for the same bug, fixing
typos in generated log messages, managing our mailing lists and the
Web site -- all this is part of the job.  That we currently have a few
kind people like Glenn, Paul, Juanma, and others silently doing this
behind the scenes (look at "git log" to see what I mean) is sheer
luck.  People who want to help could start with these small but
important tasks.  With time and experience, they will gain confidence
in their talents and abilities, and -- no less important -- upgrade
their status within the community, and that will help them decide
which larger tasks they could take upon themselves.

Re: Another others for maintainer?

[Przemysław Wojnowski]

W dniu 22.10.2015 o 17:32, Eli Zaretskii pisze:
> [...] committing auto-generated files
If they are autogenerated why to commit them?

>People who want to help could start with these small but
> important tasks.
It would help if someone could list that tasks in a visible place 
(etc/CONTRIBUTE?). I'm on the list for a while and didn't know about 
them, so probably other emecs-devel newbies also don't know about it.

Re: Another others for maintainer?

[Eli Zaretskii]

> Cc: emacs-devel@gnu.org
> From: Przemysław Wojnowski <esperanto@cumego.com>
> Date: Thu, 22 Oct 2015 18:49:50 +0200
> 
> W dniu 22.10.2015 o 17:32, Eli Zaretskii pisze:
> > [...] committing auto-generated files
> If they are autogenerated why to commit them?

Some of them are needed for bootstrap, others (ChangeLog.2) we decided
to keep in the repository.

> >People who want to help could start with these small but
> > important tasks.
> It would help if someone could list that tasks in a visible place 
> (etc/CONTRIBUTE?). I'm on the list for a while and didn't know about 
> them, so probably other emecs-devel newbies also don't know about it.

Patches welcome (the file should be in admin/notes, I guess).

Re: Another others for maintainer?

[John Wiegley]

>>>>> Eli Zaretskii <eliz@gnu.org> writes:

> Thanks, but you make this sound like if tomorrow I'm overrun by a bus, Emacs
> will die, or at least stagnate. Which of course is not true. There are quite
> a few people here without whom Emacs development would not have been what it
> is, let alone what it (hopefully) will be.

A good point. I was referring more to your combination of consistency and
energy, with long experience in the project. That's more valuable than maybe
you give yourself credit for.

> If you don't have enough time to actively engage in technical issues, like
> discussing development and design/implementation decisions, reviewing
> patches, fixing bugs, etc. -- then the above scenario is not viable. There's
> no chance in the world I alone will be able to deal with that workload: I
> have neither the time nor knowledge (nor talent, to be honest) to do that.
> So we will need at least some of the team you describe here:

It's true, I don't have the time it would take to do what you do now, Eli.
We'll need to make building up our "development team" a first and crucial
task, as you say.

> P.S. I think many people don't realize how many simple, mundane tasks are
> part of what we call "Emacs maintenance". Stuff like fixing spelling errors,
> committing auto-generated files, fixing unsafe or sub-optimal code revealed
> by compiler warnings, closing bugs that were resolved but left open, merging
> bug reports for the same bug, fixing typos in generated log messages,
> managing our mailing lists and the Web site -- all this is part of the job.
> That we currently have a few kind people like Glenn, Paul, Juanma, and
> others silently doing this behind the scenes (look at "git log" to see what
> I mean) is sheer luck. People who want to help could start with these small
> but important tasks. With time and experience, they will gain confidence in
> their talents and abilities, and -- no less important -- upgrade their
> status within the community, and that will help them decide which larger
> tasks they could take upon themselves.

This paragraph is perfect. I'll draft up a call for volunteers as soon as I
can find some time this weekend, starting from what you've written here.

John

Re: Another others for maintainer?

[Rasmus]

Eli Zaretskii <eliz@gnu.org> writes:

> P.S. I think many people don't realize how many simple, mundane tasks
> are part of what we call "Emacs maintenance".  Stuff like fixing
> spelling errors, committing auto-generated files, fixing unsafe or
> sub-optimal code revealed by compiler warnings, closing bugs that were
> resolved but left open, merging bug reports for the same bug, fixing
> typos in generated log messages, managing our mailing lists and the
> Web site -- all this is part of the job.  That we currently have a few
> kind people like Glenn, Paul, Juanma, and others silently doing this
> behind the scenes (look at "git log" to see what I mean) is sheer
> luck.  People who want to help could start with these small but
> important tasks.  With time and experience, they will gain confidence
> in their talents and abilities, and -- no less important -- upgrade
> their status within the community, and that will help them decide
> which larger tasks they could take upon themselves.

Well, I have commit access and I contribute to Org fairly often (though
recently time is an issue).

Emacs is the most important program on my PC.  I would like to do more,
but Emacs-core is daunting.  It’s hard to get into Emacs-core, not only
because you are dealing with something that’s fairly complex and it’s hard
to even identify tasks (to me), but also because I’d be scared of messing
something up.

I’m not saying the information isn’t there, simply that it’s overwhelming,
especially if you are more interested in improving existing code, instead
of, say, providing new modules.

Rasmus

-- 
Dobbelt-A

Re: Another others for maintainer?

[Eli Zaretskii]

> From: Rasmus <rasmus@gmx.us>
> Date: Fri, 23 Oct 2015 00:06:18 +0200
> 
> Well, I have commit access and I contribute to Org fairly often (though
> recently time is an issue).

Thanks.

> Emacs is the most important program on my PC.  I would like to do more,
> but Emacs-core is daunting.  It’s hard to get into Emacs-core, not only
> because you are dealing with something that’s fairly complex and it’s hard
> to even identify tasks (to me), but also because I’d be scared of messing
> something up.

You shouldn't be scared.  You can always push a branch to Savannah and
let you and others use the modified code for a while, until you are
sure enough it has no adverse effects, and then take the plunge.

I know the feeling, believe me.  I was exactly at that place when I
needed to merge the bidirectional display engine onto master for what
became Emacs 24.1.  The display engine is one of the most complex
parts of Emacs, perhaps _the_ most complex part.  It is also central
to any Emacs operation.  The thought of screwing up everybody's Emacs
or have Emacs crash every few seconds absolutely petrified me.  I
remember debating and procrastinating for some time, unable to make
the final decision.

What made it happen was an email from Stefan and Chong saying they
absolutely trust me with this merge.  (They didn't see the code, so I
have no idea what could make them say that.)  The rest is history.

The lesson I took from that is clear: well-tested changes are safe to
merge.  Make sure you test your code as much as you can, run the test
suite, prepare your own test cases if the suite is not extensive
enough for your changes, use the modified version in real-life
sessions -- if all that passes without problems, you are good to go.

> I’m not saying the information isn’t there, simply that it’s overwhelming,
> especially if you are more interested in improving existing code, instead
> of, say, providing new modules.

My advice is not to try to comprehend all of it.  Instead, take some
specific problem that needs to be solved (the bug tracker has many
candidates, or maybe you have your own bug you want to fix or a
feature you'd like to add), and study the parts(s) relevant to that
single problem.  Don't hesitate to ask questions here where you are
unsure you understand the stuff.  Add helpful comments to the code
where the existing comments were not enough for you.  Keep going until
that single problem is solved.  Then take another one, preferably in
the same area of Emacs -- now you should feel more at home there, and
things will move quicker.  Rinse, repeat.  It really works.  You just
need to take the first step, then the second, then the third.  One
step at a time.  "Rome wasn't built in a day."

Thanks in advance!

Re: Another others for maintainer?

[John Wiegley]

>>>>> Eli Zaretskii <eliz@gnu.org> writes:

>> I’m not saying the information isn’t there, simply that it’s overwhelming,
>> especially if you are more interested in improving existing code, instead
>> of, say, providing new modules.

> My advice is not to try to comprehend all of it. Instead, take some specific
> problem that needs to be solved (the bug tracker has many candidates, or
> maybe you have your own bug you want to fix or a feature you'd like to add),
> and study the parts(s) relevant to that single problem. Don't hesitate to
> ask questions here where you are unsure you understand the stuff. Add
> helpful comments to the code where the existing comments were not enough for
> you. Keep going until that single problem is solved. Then take another one,
> preferably in the same area of Emacs -- now you should feel more at home
> there, and things will move quicker. Rinse, repeat. It really works. You
> just need to take the first step, then the second, then the third. One step
> at a time. "Rome wasn't built in a day."

I couldn't agree more here, Rasmus. Eli paints the picture of a successful
Emacs development experience very well.

Start small, pick a problem of meaning to you, and chip away until done. We
are here to help every step of the way. You don't even need to understand
everything in order to begin: ask us questions, and we'll help you fill in the
blanks as you go.

John

Re: Another others for maintainer?

[Bastien]

Eli Zaretskii <eliz@gnu.org> writes:

> 10-20 people is probably an ambitious goal, but at least around 5 is
> IMO the necessary minimum.  Those individuals will have to agree to be
> part of the team, ideally also tell which areas they would like (or
> consider themselves able) to be responsible for, so that many (most?)
> issues will have a clear addressee in the team.

I volunteer to continue being Org-mode's maintainer, definitely with
more time next year.  (I've been relying on the Org-mode team for most
of 2015, which worked okay, but the project needs to move forward.)

I also volunteer to try sorting out more mundane issues from the bug
tracking system.  As Eli pointed out, there is a lot already done in
this area, but a lot left to be done too.  I personally enjoy the
thrill of doing trivial tasks like fixing typos, closing dead bugs,
etc.  So you can count on me for this!

-- 
 Bastien

Re: Another others for maintainer?

[Eli Zaretskii]

> From: Bastien <bzg@gnu.org>
> Cc: John Wiegley <johnw@newartisans.com>,  jay.p.belanger@gmail.com,  emacs-devel@gnu.org
> Date: Sat, 24 Oct 2015 11:35:43 +0200
> 
> I volunteer to continue being Org-mode's maintainer, definitely with
> more time next year.  (I've been relying on the Org-mode team for most
> of 2015, which worked okay, but the project needs to move forward.)
> 
> I also volunteer to try sorting out more mundane issues from the bug
> tracking system.  As Eli pointed out, there is a lot already done in
> this area, but a lot left to be done too.  I personally enjoy the
> thrill of doing trivial tasks like fixing typos, closing dead bugs,
> etc.  So you can count on me for this!

Thanks a lot!

Re: Another others for maintainer?

[John Wiegley]

>>>>> Bastien  <bzg@gnu.org> writes:

> I volunteer to continue being Org-mode's maintainer, definitely with more
> time next year. (I've been relying on the Org-mode team for most of 2015,
> which worked okay, but the project needs to move forward.)

Fantastic!

> I also volunteer to try sorting out more mundane issues from the bug
> tracking system. As Eli pointed out, there is a lot already done in this
> area, but a lot left to be done too. I personally enjoy the thrill of doing
> trivial tasks like fixing typos, closing dead bugs, etc. So you can count on
> me for this!

This is amazing, Bastien; we could really use some good "bug shepherds". The
most often cited reason for disappointment with Emacs development I hear is
that bugs and patches "die on the vine", for want of time on the maintainer's
part to attend to them all.

So what I'd love to see happen first is to go through the bug tracker and find
every issue with a waiting patch. Confirm with the submitter that they believe
their patch is in final ready status, and that it works with current Git HEAD.
Then let's start moving these patches in and closing their associated bugs.

Let's harvest our low-hanging fruit!

John

Re: Another others for maintainer?

[Stephen Leake]

John Wiegley <johnw@newartisans.com> writes:

> So what I'd love to see happen first is to go through the bug tracker and find
> every issue with a waiting patch. Confirm with the submitter that they believe
> their patch is in final ready status, and that it works with current Git HEAD.
> Then let's start moving these patches in and closing their associated bugs.

On the monotone project, we occasionally ran a "bug squashing contest".
Someone would put up money for a small prize (usually monotone logo hats
or shirts), and whoever squashed the most bugs in a 24 hr period gets
the prize. It worked pretty well as a motivator; sometimes people only
need a little push to do the right thing.

We might want to occaisionally change the "win" metric to "most urgent
bugs" or something, otherwise only minor bugs get fixed.

-- 
-- Stephe