From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: More metaproblem Date: Thu, 04 Dec 2014 10:35:24 -0500 Message-ID: References: <20141203142859.24393.98673@vcs.savannah.gnu.org> <20141203192721.GE12748@thyrsus.com> <547F6774.50700@cs.ucla.edu> <838uio5vjw.fsf@gnu.org> <20141203211447.GB15111@thyrsus.com> <871toge5zw.fsf@floss.red-bean.com> <83388v6hsq.fsf@gnu.org> <85zjb3q06b.fsf@stephe-leake.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1417707358 4876 80.91.229.3 (4 Dec 2014 15:35:58 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 4 Dec 2014 15:35:58 +0000 (UTC) Cc: emacs-devel@gnu.org To: Stephen Leake Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Dec 04 16:35:51 2014 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 1XwYRY-000241-SX for ged-emacs-devel@m.gmane.org; Thu, 04 Dec 2014 16:35:49 +0100 Original-Received: from localhost ([::1]:46379 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XwYRY-0000RN-EX for ged-emacs-devel@m.gmane.org; Thu, 04 Dec 2014 10:35:48 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:50100) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XwYRO-0000RD-D7 for emacs-devel@gnu.org; Thu, 04 Dec 2014 10:35:45 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XwYRG-0001nq-Sa for emacs-devel@gnu.org; Thu, 04 Dec 2014 10:35:38 -0500 Original-Received: from ironport2-out.teksavvy.com ([206.248.154.181]:37312) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XwYRG-0001nb-NI for emacs-devel@gnu.org; Thu, 04 Dec 2014 10:35:30 -0500 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjsPAOwQflRMCqTq/2dsb2JhbABbgweDYIVaxR0EAgKBJBcBAQEBAQF8hAMBAQMBViMFCws0EhQYDSSISgnWWQEBAQEGAQEBAR6QbweESAWLAYNhiCqYI4F4hBkhgncBAQE X-IPAS-Result: AjsPAOwQflRMCqTq/2dsb2JhbABbgweDYIVaxR0EAgKBJBcBAQEBAQF8hAMBAQMBViMFCws0EhQYDSSISgnWWQEBAQEGAQEBAR6QbweESAWLAYNhiCqYI4F4hBkhgncBAQE X-IronPort-AV: E=Sophos;i="5.07,502,1413259200"; d="scan'208";a="99550523" Original-Received: from 76-10-164-234.dsl.teksavvy.com (HELO pastel.home) ([76.10.164.234]) by ironport2-out.teksavvy.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 04 Dec 2014 10:35:29 -0500 Original-Received: by pastel.home (Postfix, from userid 20848) id 683D5996B; Thu, 4 Dec 2014 10:35:24 -0500 (EST) In-Reply-To: <85zjb3q06b.fsf@stephe-leake.org> (Stephen Leake's message of "Thu, 04 Dec 2014 02:38:52 -0600") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (gnu/linux) X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 206.248.154.181 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:178826 Archived-At: >>> For example, as far as I can see -- and I've looked, though maybe in the >>> wrong places -- there's never been a permanent sign anywhere, like on a >>> web page, telling developers when they should commit to release branches >>> versus when they should commit to master (trunk). I'd be happy to put such info somewhere, but I'm not sure where that should go. I see two problems to solve: - Make sure people don't commit to the wrong branch. - Help people find out where to commit. The two are closely related, yet different: many contributors end up contributing to the wrong branch because they don't even know that there's a decision to make about which branch to use. Since most pople aren't going to check a docfile or webpage every time they commit, just on the off-chance that the rules have changed, it's important for these rules to be permanent, if we want them to work well. So, I think we should say that we always have 2 branches: - master, for the bleeding edge. - stable, for bug fixes. And to avoid errors, "master" should never be frozen (so far, this has not been the case, although I have tried to shorten the freeze time over the years). > That's not what admin/notes/repo says: > > Sometime before the release of a new major version of Emacs > a "feature freeze" is imposed on the trunk. No new features may be > added after this point. This is usually some months before the release. > > "some months" is not "short". (see below for suggested patch) For the last few releases, the process has been: - when we're ready to start the release: freeze the trunk. - a month or so later: cut a release branch from the trunk, re-open the trunk to changes. - keep on fixing bugs on the release branch, updating the doc, then make pretest releases, and finally after several more months: make a release. The purpose of the "freeze the trunk" is to try and get people to focus on fixing bugs for a while. I'm not sure it's very effective, tho. > (there is also the issue that "trunk" is now spelled "master") Indeed. > > >> Maybe we should simply move all that into etc/CONTRIBUTE, and leave in > > >> admin/notes only stuff that is minor/obscure etc. [...] > We can have a section there labeled "if you have write access to the > repository". I see nothing wrong with that, and no need to have yet > another file with possibly contradictory instructions. I don't have a strong opinion on any of this, but if we want this info to be effective, we should make it as visible as possible, i.e. not in admin/notes (which no newcomer would think of consulting) but in ./CONTRIBUTE (that's right: not in `etc' either but at the toplevel). And it should be kept as short as possible (e.g. things like formatting of references to particular revisions is the kind of nitpicking we don't need in there). Stefan