[Scons-dev] Working branches

[Gary Oberbrunner]

On Mon, Oct 7, 2013 at 7:47 AM, Russel Winder <russel at winder.org.uk> wrote:


> On Fri, 2013-10-04 at 14:19 -0400, Gary Oberbrunner wrote:

> […]

> > What I've been thinking is this:

> >  * for now, we continue working on the python3-port branch until it

> works.

> >  * until python3-port works, regular changes go on default as usual.

> >  * merge from default into python3-port as needed, to keep it current.

> >  * as soon as it's working (which means on both python2 and python3 all

> > tests pass, and a few people say it works in their environments), we

> merge

> > it to default and close that branch.

> >  * From then on, all new changes go on default, and must support our list

> > of supported pythons (2.7.2 or greater, and 3.3 or greater, right?)

>

> From a quick look, the python3 branch looks like Python3 only code, it

> needs bringing back to be Python 2 compliant as well as Python 3

> compliant.



Yes, that's correct (though much of the 2to3 stuff ought to be _basically_
python2 compliant with some massaging).



> Step 1 is to put:

>

>         from __future__ import absolute_import, division, print_function,

> unicode_literals

>

> as the first statement in every code file and see what happens.

>


Perhaps that's step 2 :-); I've already started on some print changes to
handle unicode/string variation, per my last email.

As for absolute_import, I'm not sure that's needed; isn't it better to use
relative imports?  I think Neal's changes already move in that direction.
As for unicode_literals, I believe (?) that as of python3.3, u'xxx' works
again, so that shouldn't matter. Let me know if not.
As for division, I guess we need to do that, but there's some work there to
ensure we use // wherever we mean divide-and-floor (which is most of the
time, in this type of code I think).



> […]

> > Feature branches seem to be the worst part of hg IMHO.  Dirk, your

> workflow

> > seems OK, although a bit indirect; you could run into problems once your

> > changes are accepted, pulling back in. Russel, would Dirk's setup work

> for

> > you?  Alternatively if we used a separate repo for python3 work would

> that

> > be better? (Seems weird to me, even though it seems to be common practice

> > in mercurial).

>

> Apparently bookmarks are to Mercurial what feature branches are to Git.



I was going to object that bookmarks don't get pushed, but apparently now
they can be: http://mercurial.selenic.com/wiki/Bookmarks/ says push -B
<bookmark> pushes that bookmark and its changesets.

Since most pull requests come from the default branch, bookmarks are a good
idea for naming what otherwise come in as nameless heads.  In the python3
case, though, would using a bookmarked head be significantly different
workflow-wise (e.g. in how you maintain the D tool)?

-- 
Gary
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://two.pairlist.net/pipermail/scons-dev/attachments/20131007/ab803b94/attachment-0001.htm>