Hi all, Pardon my ignorance and, I presume my raging naïveté 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 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ław 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 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 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 features > > 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. > > >