Re: More metaproblem

[Stefan Monnier]

>>> 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