From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: =?UTF-8?Q?Przemys=c5=82aw_Wojnowski?= Newsgroups: gmane.emacs.devel Subject: Re: New maintainer Date: Wed, 7 Oct 2015 20:49:39 +0200 Message-ID: <56156943.3080207@cumego.com> 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: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Trace: ger.gmane.org 1444243814 4792 80.91.229.3 (7 Oct 2015 18:50:14 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 7 Oct 2015 18:50:14 +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 20:50:00 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 1Zjtmp-0002T6-Hj for ged-emacs-devel@m.gmane.org; Wed, 07 Oct 2015 20:49:59 +0200 Original-Received: from localhost ([::1]:59043 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zjtmo-0000MY-QU for ged-emacs-devel@m.gmane.org; Wed, 07 Oct 2015 14:49:58 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:58741) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zjtmb-0000MK-Hm for emacs-devel@gnu.org; Wed, 07 Oct 2015 14:49:46 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZjtmY-0000aU-A8 for emacs-devel@gnu.org; Wed, 07 Oct 2015 14:49:45 -0400 Original-Received: from smtp10.iq.pl ([86.111.242.219]:58361) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZjtmX-0000ZC-Vs for emacs-devel@gnu.org; Wed, 07 Oct 2015 14:49:42 -0400 Original-Received: (qmail 9969 invoked from network); 7 Oct 2015 18:49:40 -0000 Original-Received: from unknown (HELO [192.168.1.102]) (esperanto@cumego.com@[159.205.196.239]) (envelope-sender ) by smtp22.iq.pl with AES128-SHA encrypted SMTP for ; 7 Oct 2015 18:49:40 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 In-Reply-To: <83k2qyem18.fsf@gnu.org> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 86.111.242.219 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:191058 Archived-At: W dniu 07.10.2015 o 17:27, Eli Zaretskii pisze: > 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. Didn't know that such file exist. Thanks! It definitely should have more exposure, especially "Simple tasks" section. How about mentioning it in etc/CONTRIBUTE?. What I found strange is that the following file has different content: http://www.gnu.org/software/emacs/CONTRIBUTE >> 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. Yes. Keep in mind that nothing is welded and can change for various reason, the roadmap too. But at least it's a plan (starting point). >> [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. Maybe it's a good approach. >> 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. Well, IMHO some goals could be defined, for example "Provide IDE features for language X (maybe unified) to make a programmer productive". To achieve that some smaller goals would need to be achieved, for example: - provide project support (notion of project, maybe unified project API for different languages, debugger, etc.) - provide refactoring tools for language(s) X (Y/Z) - etc. It could be divided into yet smaller goals until they finish in "Simple tasks" section . ;-) >> [...] strong tests >> 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. :-) It was not a joke. Writing tests is a very good way to learn how things work. > Besides, "more tests" is hardly a development direction, it's a means > to an end. I've written "strong tests", which is not the same. But to be clear, the goal is to have enough test to change Emacs safely, without a fear of introducing new bugs (of course that will always happen, but with "strong tests" they are very limited). Such tests allow to build deployment pipeline and be able to release Emacs on every commit that pass the pipeline. IMHO this can be a goal. > >> 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. Yes. The point here is constant improvement. Being open on new things , trying them and adapting what works. It doesn't have to be constrained only to the Agile teams. >>> 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. Maybe you're right. It was just an idea. >> 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. Maybe. It was just an idea how not to loose valuable people. Maybe someone else will have a better one. >> 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. Sorry. Seems that there's a misunderstanding. I don't want to "shut up" anyone, but just ask for moving "off-topics" to new threads - "Please discuss X in a separate thread." >> Unrelated messages make it very hard to follow the main thread. >> 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. Well, I can ask to discuss other topics in a new threads. Being polite doesn't hurt. Cheers, Przemysław