[python-committers] [PSF-Members] Code Simplicity » Open Source Community, Simplified

Fri Feb 4 14:30:58 CET 2011

None I can show just now :(. I do remember discussion about some patches
not being backported because people were trying to speed up py3k.

>> If we up-port, no patch is forgotten. The rule should be: "patches in
>> n+1 are a SUPERSET of patches in n". With this rule, mercurial takes
>> care of everything (a patch in n+1 can 'undo' a patch up-ported from n,
>> if needed, keeping the rule).
> 
> That's a theoretical and IMO naïve point of view. In practice, there are
> many changesets that will not "up-port" cleanly and will need manual
> work. The work will not be much less than with down-porting.

I don't understand how "backporting" is easy, and "upporting" is
difficult. You have to potentially manually tweak in both cases.

Let's see.

We have these branches:

1. Old releases, still supported (security, critical fixes). These
releases are mostly static. Any patch there would "naturally" need to be
applied too in more modern branches. That is, "up porting".

2. Released and supported releases: These are bug fix only branches.
Traffic should be low. Since only fixes go in, every changeset should be
applied too to more modern branches. That is, "up porting".

3. Not yet, but about to be released branch. Currently this "freezes"
the trunk, or patches are very restricted. For instance, "no new
features". This status can be pretty lenghtly now, months. I suggest to
"clone" the trunk here. This will be the beta/rc/final/maintenance
clone. Trunk remains fully open. This clone has a restricting patch
policy (no new features in the beginning, fixes only later). Any patch
here, bug fix, documentation clean up, etc. should be "up ported" too to
trunk. Trunk is open all the time.

Some fellows said that this would disincentivate contributions to the
beta branch. In fact, coders would love to see their fixes/code/whatever
they do being released in the next python version, three months for now,
instead in the n+1 version, two years away. So I guess people would rush
to commit to the beta clone (just like now!). But coders with long term
plans can keep working in the trunk, freely. For instance, new stdlib
modules.

The only issue in this plan would be trunk evolving so fast that
up-porting changesets from the beta to trunk (merging) would be non
automatic. The beta being a few months long would help. Anyway, we could
have a social rule to "avoid" doing heavy incompatible work for a while,
until the release. Anyway, we already have the issue now, because if
trunk is wildy diverging, we already have issues when backporting from
trunk to the maintenance branches. In fact this situation disincentivate
"back porting", since it would be costly. If you "up port", you can't
left behind any patch.

My guess is that most coders would concentrate in the beta clone,
because they want their work released as fast as possible, and people
working in trunk would be guys adding new functionality. I bet that
overlapping changes would be pretty rare, during the beta/rc time.

Something to note is that mercurial merge is pretty clever, and can
follow things like file renaming/moving, line number offset, etc. It is
a "three way merge", far more powerful that simply trying to apply a
patch to a file. Mercurial do a history evaluation and know how to
modify your changeset to be applied cleanly, most of the time. For
instance, if the file was modified in trunk to add a 2000 line patch,
mercurial knows how to "offset" your changeset before trying to
automatically apply.

PS: When a branch moves to a *temporal* restricted commit state, a new
clone should be created, for people to keep working in the new minor
release. That is, we are now in 3.2.0 release candidate. Patching is
very restricted. If we had a 3.2.0 release candidate clone, MUST SHIP
changes would be in the 3.2.0rc repository, but patches planned for
3.2.1 would be being already being committed the clone. When 3.2.0 is
released and the branch is marked as "maintenance", the 3.2.1 clone
would merge into the 3.2 maintenance and destroyed.

The point is... to never temporally freeze any repository.

The only frozen repositories would be dead ones.

- -- 
Jesus Cea Avion                         _/_/      _/_/_/        _/_/_/
jcea at jcea.es - http://www.jcea.es/     _/_/    _/_/  _/_/    _/_/  _/_/
jabber / xmpp:jcea at jabber.org         _/_/    _/_/          _/_/_/_/_/
.                              _/_/  _/_/    _/_/          _/_/  _/_/
"Things are not so easy"      _/_/  _/_/    _/_/  _/_/    _/_/  _/_/
"My name is Dump, Core Dump"   _/_/_/        _/_/_/      _/_/  _/_/
"El amor es poner tu felicidad en la felicidad de otro" - Leibniz
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQCVAwUBTUv/kplgi5GaxT1NAQLWHQQAhOlRmla8vfLFJekN7pa51rDex2aJ8a+X
XtUucgBrzHjxvjCdlmMFexPvY52tq2/re4UkSso79ANzdn6B7wvaVLW+HZvcIrhF
uWptP765gdgSIPb1bwuN8ToJDK77CjjXQvcO1gO50oTe6P+I6l703kwHWMC499al
NA1x17si8xk=
=4qaS
-----END PGP SIGNATURE-----