Re: More metaproblem

[Stephen Leake]

Stefan Monnier <address@hidden> writes:

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

Good point.

> So, I think we should say that we always have 2 branches:
> - master, for the bleeding edge.
> - stable, for bug fixes.

+1

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

We could try to leave trunk open, but put in a commit preprocessor that
looks for "fixes bug [0-9]+". It could then either refuse the commit, or
issue a stern warning.

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

I'll take a stab at writing that. 

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

I'll refer to admin/notes/* for "more advanced developers".

-- 
-- Stephe