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

[Brett Cannon]

Just to help settle this, I will write something and work with the
appropriate people to get something worked out. I will most likely
branch the devguide with an hg_transition branch and work in there so
people can still publicly participate but not have it affect the
published site.

On Sat, Feb 5, 2011 at 10:08, R. David Murray <rdmurray at bitdance.com> wrote:
> On Sat, 05 Feb 2011 02:07:52 +0100, <martin at v.loewis.de> wrote:
>> > Indeed. Mainline is the only branch where we *know* most patches need
>> > to be applied. It also means that people can contribute while
>> > maintaining only a single checkout, rather than necessarily needing
>> > all active versions.
>>
>> Notice that you'll automatically will have all active versions
>> available, if PEP 385 is implemented. A single clone will have all
>> maintenance branches as named branches inside, so integrating
>> a bug fix should be a sequence like
>>
>> hg update release32-maint
>> patch
>> hg commit
>> hg update default
>> hg merge release32-maint
>> hg commit -m merged
>> hg push
>>
>> Sprinkle test runs into this to your taste.
>
> What about compiles?  And perhaps even make distclean/configure?  With our
> current workflow I have separate checkouts for 2.7, 3.1, and 3.2, and
> run make when I see a c file go by after an svn up (and make distclean if
> I see an update to a .in file, though I know that isn't always necessary).
>
> Is there a way to translate that bit of the workflow to hg, or do I need
> to run make after each update, and make distclean if things fail to work
> as expected?  Will running make after an update always do the right thing
> (ignoring those issues for which make distclean is currently needed)?
>
> We really really really need some to document the expected best practices.
> Even if there isn't agreement among the hg veterans yet, someone should
> document *something* that we can iterate on to reach a preliminary
> consensus so us newbies have something to work from when the switchover
> is made.
>
> I'm with Nick here; I don't have a project that uses hg, and until I do
> no amount of reading about it is going to do any good.  And even after
> I'm going to need help...I tried using bzr for email6 and I *still*
> don't understand how to use it properly.  Of course, nobody had written
> a best practices guide for me for my project, which is why I'm joining
> the chorus asking for one for Python :)
>
> --
> R. David Murray                                      www.bitdance.com
> _______________________________________________
> python-committers mailing list
> python-committers at python.org
> http://mail.python.org/mailman/listinfo/python-committers
>