From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Malk'Zameth" Newsgroups: gmane.emacs.devel Subject: Re: New maintainer Date: Wed, 7 Oct 2015 18:47:39 +0200 Message-ID: References: <560CCEBA.9080607@online.de> <874miapdhs.fsf@openmailbox.org> <87pp0yktyx.fsf@fencepost.gnu.org> <22029.59130.54156.957525@turnbull.sk.tsukuba.ac.jp> <87io6pnujl.fsf@red-bean.com> <874mi840si.fsf@wanadoo.es> <561034C3.2060101@cumego.com> <838u7j2lq0.fsf@gnu.org> <5610CF32.6080701@cumego.com> <83vban14y5.fsf@gnu.org> <56144409.5070501@cumego.com> <83k2qyem18.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=089e0149c57e4ba10b0521868256 X-Trace: ger.gmane.org 1444236502 3469 80.91.229.3 (7 Oct 2015 16:48:22 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 7 Oct 2015 16:48:22 +0000 (UTC) Cc: emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Oct 07 18:48:13 2015 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 1Zjrsx-00054m-OL for ged-emacs-devel@m.gmane.org; Wed, 07 Oct 2015 18:48:12 +0200 Original-Received: from localhost ([::1]:58626 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zjrsw-0000Xd-Rq for ged-emacs-devel@m.gmane.org; Wed, 07 Oct 2015 12:48:10 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:60787) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zjrsq-0000TC-2A for emacs-devel@gnu.org; Wed, 07 Oct 2015 12:48:05 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Zjrsl-0002a2-RR for emacs-devel@gnu.org; Wed, 07 Oct 2015 12:48:03 -0400 Original-Received: from mail-ig0-f169.google.com ([209.85.213.169]:37468) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zjrsl-0002Zc-MI for emacs-devel@gnu.org; Wed, 07 Oct 2015 12:47:59 -0400 Original-Received: by igcpe7 with SMTP id pe7so19015594igc.0 for ; Wed, 07 Oct 2015 09:47:59 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=PVSkZeDoKhjG//S80SnENzLuoTToV/tDB4Y11NMg2Zg=; b=hRun6uc3EVbn52uqYkA4GtDi2uXFp4GTRx1lN1KgQK8xuCvbzN3q4sAucNyIQwZkU+ HvBDjH3pPy6LfVExiuhOQNAKflvboNBjzZpUC7DBCalteF7h2AKKnoI6LNHL8WiBxmFx AX0/1F61Bf8Rx8HckevMBv0D0d6FGYFjm9dwG8MYBBAu0yX5xwZYPHorB5ka2SteUJZE +fRdLza0h/9h85A4p9fcVOli/7hjTly0SdcB5mM14cGHpDPiz5YEXL1/Xc11REq/4y/s R22ypVfaLxS+4Toz9wWUv2TfwZHTiiE28ZPaw6nfPpqQkCvVoZPgHRZKirV0Z4+npgZk nX0w== X-Gm-Message-State: ALoCoQmqD0yCYsHesvA/2ZgLVD1wTxV1fufScXC4tmkFRfbohsnmsNl3i88AvvHKWxEjQQ/uecL6 X-Received: by 10.50.178.172 with SMTP id cz12mr971817igc.76.1444236478865; Wed, 07 Oct 2015 09:47:58 -0700 (PDT) Original-Received: by 10.64.59.105 with HTTP; Wed, 7 Oct 2015 09:47:39 -0700 (PDT) X-Originating-IP: [87.240.91.203] In-Reply-To: <83k2qyem18.fsf@gnu.org> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] [fuzzy] X-Received-From: 209.85.213.169 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 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-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:191049 Archived-At: --089e0149c57e4ba10b0521868256 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi all, Pardon my ignorance and, I presume my raging na=C3=AFvet=C3=A9 possible onl= y out of a lack of the whole context, here (if answering me would derail the subject, please ignore) 1 - the GCCvsClang issue touches features of Emacs itself (impacting 100% of Emacsers) or just people using GCC/Clang for dev? 2 - If the latter: If we where to move CC-mode from the emacs core to Elpa would that cut the debate from the core Emacs point of view? we have an amazing module/package system now right? And probably the C devs are no longer the majority ? 3 - On more abstract level: If we where, hypothetically, to slim down the Core Emacs as much as possible and rely heavily on the packaging system itself: what contention points between Freedom and Technical Evolution would remain on the core itself? Thanks, Romeu On Wed, Oct 7, 2015 at 5:27 PM, Eli Zaretskii wrote: > > Cc: emacs-devel@gnu.org > > From: Przemys=C5=82aw Wojnowski > > Date: Tue, 6 Oct 2015 23:58:33 +0200 > > > > >> W dniu 04.10.2015 o 08:26, Eli Zaretskii pisze: > > >>>> IMHO one problem might be that, due to lack of roadmap and clear > > >>>> priorities, a lot of different things are developed at the same > time, > > >>> > > >>> I don't think you can prevent that in a project as multi-faceted an= d > > >>> multi-discipline as Emacs, nor do I think you should want to. > > I'm not saying that people should stop work on things that would not be > > on a roadmap or in the next release. My point was that there should be = a > > vision of Emacs in 5-10-15 years (what we would like it to be?), a > > roadmap based on that - list of features that bring us closer to that > > vision, etc. All written down. > > I already agreed that it would be a good thing to have such a > roadmap. But it's entirely not easy to come up with. > > It's not that we didn't try before. The best result we could come up > with is in etc/TODO. It's an undeservedly forgotten resource. > > > Based on that maintainers would be able to plan releases with features > > from a roadmap - with consensus with developers. Maybe not many feature= s > > would make it into the next release. Maybe just one of them. > > This assumes that there will be some sufficient correlation between > the roadmap and the significant features being developed each year. > However, such an assumption will only hold if the roadmap is > coordinated with the existing developers before it becomes official. > Otherwise, you have only luck on your side, which IME is not a good > plan. > > > [roadmap] would make it clear what we want and were are we going > > (the vision). It would also make developers to focus on the next > > release. > > That's the hope, but it won't happen by itself, IME. > > For this reason, we have been doing until now the exact opposite: > decided on a major release when enough significant new features became > available. I cannot say it worked badly, btw. You can review the > major releases and see for yourself. > > > Nobody wants to work on a project that goes nowhere. There always > > have to be some goal. > > I don't think there could be _a_ goal for Emacs. It will always be > quite a few significant ones, and then many more less significant, but > still important ones. In this sense, there's no single direction in > which Emacs is, or should be going. > > > For example I see Emacs in 5 years with strong tests that immediately > > catch bugs and make refactoring fun. To achieve that I would add a goal > > that can be started right now, especially by newcomers: > > 1. Write unit tests to learn how Emacs works. > > It's clear, very easy to do, very good for newcomers, and brings value > > to Emacs. :-) > > And it's already in etc/TODO, not very far from its beginning. > > Besides, "more tests" is hardly a development direction, it's a means > to an end. > > > Anyway, the beauty of Agile Software Development is its adaptability. > > Such teams try different things to improve their development process. > > Things that don't work are refined or rejected. It's like evolution. > > IMHO Emacs community could try to apply such process. :-) > > Reality check: we are not a team, in the Agile development sense. > > > > I just don't > > > think it could relieve the workload of the head maintainer and the > > > resulting burn-out, which is what you were suggesting, AFAIU. > > IMHO working on a concrete release would constraint number of topics > > and decisions to make, which would relieve the workload. > > I don't believe we will be able to constrain contributors to "working > on a release". Just watch the pressure we have every time we declare > a feature freeze to cut a release branch and end the freeze. > > > Here are other ideas: > > 1. Constraint maintenance term (for example 3 years) > > No need. Someone who feels burnt out will step down. Someone who > don't, and does a good job, should be allowed to proceed. > > > 2. Cut off-topics and end with action items. > > Cutting off-topics should be done be everyone on the list. It creates a > > flood of, maybe interesting, but irrelevant to the main topic, messages= . > > This is not a job with bosses and employees. There are no means for > anyone here, including the head maintainer, to shut anyone up or force > them to stop discussing something. Trying to do that wastes energy > and does little else. > > > Unrelated messages make it very hard to follow the main thread. > > Yes, liberal democracy is the worst of all regimes, except for all the > rest. > > > Even this topic has a number of unrelated threads (politics, keylogger, > > mac os, compiler support, etc.). How that help to find a "New > > maintainer"? > > There's nothing you can do against that. > > > --089e0149c57e4ba10b0521868256 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi all,

Pardon my ignorance and, I presume my raging na=C3=AFvet=C3=A9= possible only out of a lack of the whole context, here
(if answering me would = derail the subject, please ignore)

1 - the GCCvsClang issue touches features = of Emacs itself (impacting 100% of Emacsers) or just people using GCC/Clang= for dev?

2 - If the latter: If we where to move CC-mode from the emacs core t= o Elpa would that cut the debate from the core Emacs point of view?

<= div class=3D"gmail_default" style=3D"font-family:garamond,serif">we have an= amazing module/package system now right? And probably the C devs are no lo= nger the majority ?

3 - On more abstract level: If we where, hypothetically, t= o slim down the Core Emacs as much as possible and rely heavily on the pack= aging system itself: what contention points between Freedom and Technical E= volution would remain on the core itself?

Thanks,

Romeu


On Wed, Oct 7, 2015 at 5:27 PM= , Eli Zaretskii <eliz@gnu.org> wrote:
> Cc: emacs-devel@gnu.org<= /a>
> From: Przemys=C5=82aw Wojnowski <esperanto@cumego.com>
> Date: Tue, 6 Oct 2015 23:58:33 +0200
>
> >> W dniu 04.10.2015 o 08:26, Eli Zaretskii pisze:
> >>>> IMHO one problem might be that, due to lack of roadma= p and clear
> >>>> priorities, a lot of different things are developed a= t the same time,
> >>>
> >>> I don't think you can prevent that in a project as mu= lti-faceted and
> >>> multi-discipline as Emacs, nor do I think you should want= to.
> I'm not saying that people should stop work on things that would n= ot be
> on a roadmap or in the next release. My point was that there should be= a
> vision of Emacs in 5-10-15 years (what we would like it to be?), a
> roadmap based on that - list of features that bring us closer to that<= br> > vision, etc. All written down.

I already agreed that it would be a good thing to have such a
roadmap.=C2=A0 But it's entirely not easy to come up with.

It's not that we didn't try before.=C2=A0 The best result we could = come up
with is in etc/TODO.=C2=A0 It's an undeservedly forgotten resource.

> Based on that maintainers would be able to plan releases with features=
> from a roadmap - with consensus with developers. Maybe not many featur= es
> would make it into the next release. Maybe just one of them.

This assumes that there will be some sufficient correlation between<= br> the roadmap and the significant features being developed each year.
However, such an assumption will only hold if the roadmap is
coordinated with the existing developers before it becomes official.
Otherwise, you have only luck on your side, which IME is not a good
plan.

> [roadmap] would make it clear what we want and were are we going
> (the vision). It would also make developers to focus = on the next
> release.

That's the hope, but it won't happen by itself, IME.

For this reason, we have been doing until now the exact opposite:
decided on a major release when enough significant new features became
available.=C2=A0 I cannot say it worked badly, btw.=C2=A0 You can review th= e
major releases and see for yourself.

> Nobody wants to work on a project that goes nowhere. There always
> have to be some goal.

I don't think there could be _a_ goal for Emacs.=C2=A0 It will a= lways be
quite a few significant ones, and then many more less significant, but
still important ones.=C2=A0 In this sense, there's no single direction = in
which Emacs is, or should be going.

> For example I see Emacs in 5 years with strong tests that immediately<= br> > catch bugs and make refactoring fun. To achieve that I would add a goa= l
> that can be started right now, especially by newcomers:
> 1. Write unit tests to learn how Emacs works.
> It's clear, very easy to do, very good for newcomers, and brings v= alue
> to Emacs. :-)

And it's already in etc/TODO, not very far from its beginning.
Besides, "more tests" is hardly a development direction, it's= a means
to an end.

> Anyway, the beauty of Agile Software Development is its adaptability.<= br> > Such teams try different things to improve their development process.<= br> > Things that don't work are refined or rejected. It's like evol= ution.
> IMHO Emacs community could try to apply such process. :-)

Reality check: we are not a team, in the Agile development sense.
> > I just don't
> > think it could relieve the workload of the head maintainer and th= e
> > resulting burn-out, which is what you were suggesting, AFAIU.
> IMHO working on a concrete release would constraint number of topics > and decisions to make, which would relieve the workload.

I don't believe we will be able to constrain contributors to &qu= ot;working
on a release".=C2=A0 Just watch the pressure we have every time we dec= lare
a feature freeze to cut a release branch and end the freeze.

> Here are other ideas:
> 1. Constraint maintenance term (for example 3 years)

No need.=C2=A0 Someone who feels burnt out will step down.=C2=A0 Som= eone who
don't, and does a good job, should be allowed to proceed.

> 2. Cut off-topics and end with action items.
> Cutting off-topics should be done be everyone on the list. It creates = a
> flood of, maybe interesting, but irrelevant to the main topic, message= s.

This is not a job with bosses and employees.=C2=A0 There are no mean= s for
anyone here, including the head maintainer, to shut anyone up or force
them to stop discussing something.=C2=A0 Trying to do that wastes energy and does little else.

> Unrelated messages make it very hard to follow the main thread.

Yes, liberal democracy is the worst of all regimes, except for all t= he
rest.

> Even this topic has a number of unrelated threads (politics, keylogger= ,
> mac os, compiler support, etc.). How that help to find a "New
> maintainer"?

There's nothing you can do against that.



--089e0149c57e4ba10b0521868256--