From eliben at gmail.com  Sat May  4 05:59:37 2013
From: eliben at gmail.com (Eli Bendersky)
Date: Fri, 3 May 2013 20:59:37 -0700
Subject: [python-committers] Commit rights to Ethan Furman
Message-ID: <CAF-Rda-FUVQke0_yVSS2vXybzuLHG_t3cB774cyzfguGCJw3Og@mail.gmail.com>

Hello,

I'd like to propose to grant Ethan Furman commit rights. He's authored PEP
309, has been very helpful in the Enum saga (and is the de-facto author of
the current reference implementation), and has also been active on the
tracker for a couple of years (username stoneleaf). I think he has already
signed the contributor agreement, and explicitly expressed interest to
contribute directly to PEP 435.

Any objections?

Eli
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-committers/attachments/20130503/321a2362/attachment.html>

From eliben at gmail.com  Sat May  4 06:02:38 2013
From: eliben at gmail.com (Eli Bendersky)
Date: Fri, 3 May 2013 21:02:38 -0700
Subject: [python-committers] Commit rights to Ethan Furman
In-Reply-To: <CAF-Rda-FUVQke0_yVSS2vXybzuLHG_t3cB774cyzfguGCJw3Og@mail.gmail.com>
References: <CAF-Rda-FUVQke0_yVSS2vXybzuLHG_t3cB774cyzfguGCJw3Og@mail.gmail.com>
Message-ID: <CAF-Rda8-SvZ+t2qqcsYsvERnR3PydxQkLSoAA_nObzv+Fs547Q@mail.gmail.com>

On Fri, May 3, 2013 at 8:59 PM, Eli Bendersky <eliben at gmail.com> wrote:

> Hello,
>
> I'd like to propose to grant Ethan Furman commit rights. He's authored PEP
> 309,
>

s/309/409/ - sorry for the typo
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-committers/attachments/20130503/723597c5/attachment.html>

From guido at python.org  Sat May  4 06:35:15 2013
From: guido at python.org (Guido van Rossum)
Date: Fri, 3 May 2013 21:35:15 -0700
Subject: [python-committers] Commit rights to Ethan Furman
In-Reply-To: <CAF-Rda8-SvZ+t2qqcsYsvERnR3PydxQkLSoAA_nObzv+Fs547Q@mail.gmail.com>
References: <CAF-Rda-FUVQke0_yVSS2vXybzuLHG_t3cB774cyzfguGCJw3Og@mail.gmail.com>
	<CAF-Rda8-SvZ+t2qqcsYsvERnR3PydxQkLSoAA_nObzv+Fs547Q@mail.gmail.com>
Message-ID: <CAP7+vJ+NmPSN2nCnBxgJFmj1a1fndAPEritOdnn-d-ZDWqfPkg@mail.gmail.com>

+1 on Ethan.

On Friday, May 3, 2013, Eli Bendersky wrote:

>
>
>
> On Fri, May 3, 2013 at 8:59 PM, Eli Bendersky <eliben at gmail.com<javascript:_e({}, 'cvml', 'eliben at gmail.com');>
> > wrote:
>
>> Hello,
>>
>> I'd like to propose to grant Ethan Furman commit rights. He's authored
>> PEP 309,
>>
>
> s/309/409/ - sorry for the typo
>
>
>
>

-- 
--Guido van Rossum (python.org/~guido)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-committers/attachments/20130503/7f61f516/attachment.html>

From barry at python.org  Mon May  6 16:46:45 2013
From: barry at python.org (Barry Warsaw)
Date: Mon, 6 May 2013 10:46:45 -0400
Subject: [python-committers] Commit rights to Ethan Furman
In-Reply-To: <CAF-Rda-FUVQke0_yVSS2vXybzuLHG_t3cB774cyzfguGCJw3Og@mail.gmail.com>
References: <CAF-Rda-FUVQke0_yVSS2vXybzuLHG_t3cB774cyzfguGCJw3Og@mail.gmail.com>
Message-ID: <20130506104645.1517aa32@anarchist>

On May 03, 2013, at 08:59 PM, Eli Bendersky wrote:

>I'd like to propose to grant Ethan Furman commit rights. He's authored PEP
>309, has been very helpful in the Enum saga (and is the de-facto author of
>the current reference implementation), and has also been active on the
>tracker for a couple of years (username stoneleaf). I think he has already
>signed the contributor agreement, and explicitly expressed interest to
>contribute directly to PEP 435.
>
>Any objections?

+1 for Ethan.

-Barry

From eliben at gmail.com  Wed May  8 22:44:27 2013
From: eliben at gmail.com (Eli Bendersky)
Date: Wed, 8 May 2013 13:44:27 -0700
Subject: [python-committers] Commit rights to Ethan Furman
In-Reply-To: <20130506104645.1517aa32@anarchist>
References: <CAF-Rda-FUVQke0_yVSS2vXybzuLHG_t3cB774cyzfguGCJw3Og@mail.gmail.com>
	<20130506104645.1517aa32@anarchist>
Message-ID: <CAF-Rda9aN5vwx6P-ZiSKU2_QSzr_Ce55J6AcOD8EnYpg5HZM_A@mail.gmail.com>

So I guess I can move forward with this unless there are objections in the
next day or two,

[What should I do in addition to directing him to
http://docs.python.org/devguide/coredev.html ?]

Eli



On Mon, May 6, 2013 at 7:46 AM, Barry Warsaw <barry at python.org> wrote:

> On May 03, 2013, at 08:59 PM, Eli Bendersky wrote:
>
> >I'd like to propose to grant Ethan Furman commit rights. He's authored PEP
> >309, has been very helpful in the Enum saga (and is the de-facto author of
> >the current reference implementation), and has also been active on the
> >tracker for a couple of years (username stoneleaf). I think he has already
> >signed the contributor agreement, and explicitly expressed interest to
> >contribute directly to PEP 435.
> >
> >Any objections?
>
> +1 for Ethan.
>
> -Barry
> _______________________________________________
> python-committers mailing list
> python-committers at python.org
> http://mail.python.org/mailman/listinfo/python-committers
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-committers/attachments/20130508/2f1d7479/attachment.html>

From tjreedy at udel.edu  Thu May  9 01:07:25 2013
From: tjreedy at udel.edu (Terry Reedy)
Date: Wed, 08 May 2013 19:07:25 -0400
Subject: [python-committers] Commit rights to Ethan Furman
In-Reply-To: <CAF-Rda9aN5vwx6P-ZiSKU2_QSzr_Ce55J6AcOD8EnYpg5HZM_A@mail.gmail.com>
References: <CAF-Rda-FUVQke0_yVSS2vXybzuLHG_t3cB774cyzfguGCJw3Og@mail.gmail.com>
	<20130506104645.1517aa32@anarchist>
	<CAF-Rda9aN5vwx6P-ZiSKU2_QSzr_Ce55J6AcOD8EnYpg5HZM_A@mail.gmail.com>
Message-ID: <518ADAAD.1080304@udel.edu>

On 5/8/2013 4:44 PM, Eli Bendersky wrote:
> So I guess I can move forward with this unless there are objections in 
> the next day or two,

I have not responded before since Guido's approval seems sufficient ;-).
The main concrete step is that one of the repository supervisors add 
his  access key.

> On Mon, May 6, 2013 at 7:46 AM, Barry Warsaw <barry at python.org 
> <mailto:barry at python.org>> wrote:
>
>     On May 03, 2013, at 08:59 PM, Eli Bendersky wrote:
>
>     >I'd like to propose to grant Ethan Furman commit rights. He's
>     authored PEP
>     >309,
>

409, not 309: http://www.python.org/dev/peps/pep-0409/

>     has been very helpful in the Enum saga (and is the de-facto author of
>     >the current reference implementation),
>

You, Barry, and Guido, who have also worked on enum, know him best and 
are the principle supporters of this proposal. I gather that you all 
agree that he has shown the 'cooperativeness' necessary to a collective 
project.

>     and has also been active on the tracker for a couple of years
>     (username stoneleaf).
>

As 'stoneleaf', he has been active on 12  issues since June 2010 (nosy 
on 2 more). One patch is open and 5 have been applied (3 by Nick, 1 each 
by Antoine and R. David),  I would say that the enum code, which appears 
to be on the way to acceptance,  is equivalent to a few more typical 
issue patches.

FWIW, This is enough for a +1 from me.

>     I think he has already
>     >signed the contributor agreement, and explicitly expressed
>     interest to
>     >contribute directly to PEP 435.
>

That is the enum PEP.  http://www.python.org/dev/peps/pep-0435/
I consider a (nontrivial) reference implementation to be a direct 
contribution even if he has not yet been pushing text changes.

>     >Any objections?
>
>     +1 for Ethan.
>

--
Terry Jan Reedy

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-committers/attachments/20130508/6f9ac03d/attachment.html>

From barry at python.org  Thu May  9 04:50:21 2013
From: barry at python.org (Barry Warsaw)
Date: Wed, 8 May 2013 22:50:21 -0400
Subject: [python-committers] Commit rights to Ethan Furman
In-Reply-To: <518ADAAD.1080304@udel.edu>
References: <CAF-Rda-FUVQke0_yVSS2vXybzuLHG_t3cB774cyzfguGCJw3Og@mail.gmail.com>
	<20130506104645.1517aa32@anarchist>
	<CAF-Rda9aN5vwx6P-ZiSKU2_QSzr_Ce55J6AcOD8EnYpg5HZM_A@mail.gmail.com>
	<518ADAAD.1080304@udel.edu>
Message-ID: <20130508225021.76782906@limelight.wooz.org>

On May 08, 2013, at 07:07 PM, Terry Reedy wrote:

>You, Barry, and Guido, who have also worked on enum, know him best and are
>the principle supporters of this proposal. I gather that you all agree that
>he has shown the 'cooperativeness' necessary to a collective project.

Yes, definitely.

-Barry

From eliben at gmail.com  Fri May 10 15:08:51 2013
From: eliben at gmail.com (Eli Bendersky)
Date: Fri, 10 May 2013 06:08:51 -0700
Subject: [python-committers] Commit rights to Ethan Furman
In-Reply-To: <518ADAAD.1080304@udel.edu>
References: <CAF-Rda-FUVQke0_yVSS2vXybzuLHG_t3cB774cyzfguGCJw3Og@mail.gmail.com>
	<20130506104645.1517aa32@anarchist>
	<CAF-Rda9aN5vwx6P-ZiSKU2_QSzr_Ce55J6AcOD8EnYpg5HZM_A@mail.gmail.com>
	<518ADAAD.1080304@udel.edu>
Message-ID: <CAF-Rda-zRvB5P-35ShW3M-xdeSdz62YrSca44X6qP+a8OY7D=g@mail.gmail.com>

Thanks!

I'll go ahead and point Ethan to the dev guide, so he'll send his SSH keys
to the appropriate place. Naturally I'm volunteering to mentor him in the
initial work he'll be doing as a Python core developer. We'll start with
getting an enum implementation committed (issue 17947). Since the
implementation will almost certainly be based in large parts on Ethan's
ref435 code, I think it's fair to let him commit that once it goes through
a review.

P.S. code review of on issue 17947 will be very much appreciated!

Eli



On Wed, May 8, 2013 at 4:07 PM, Terry Reedy <tjreedy at udel.edu> wrote:

>  On 5/8/2013 4:44 PM, Eli Bendersky wrote:
>
>  So I guess I can move forward with this unless there are objections in
> the next day or two,
>
>
> I have not responded before since Guido's approval seems sufficient ;-).
> The main concrete step is that one of the repository supervisors add his
> access key.
>
>    On Mon, May 6, 2013 at 7:46 AM, Barry Warsaw <barry at python.org> wrote:
>
>>  On May 03, 2013, at 08:59 PM, Eli Bendersky wrote:
>>
>> >I'd like to propose to grant Ethan Furman commit rights. He's authored
>> PEP
>> >309,
>>
>
> 409, not 309: http://www.python.org/dev/peps/pep-0409/
>
>
>      has been very helpful in the Enum saga (and is the de-facto author of
>> >the current reference implementation),
>>
>
> You, Barry, and Guido, who have also worked on enum, know him best and are
> the principle supporters of this proposal. I gather that you all agree that
> he has shown the 'cooperativeness' necessary to a collective project.
>
>
>      and has also been active on the tracker for a couple of years
>> (username stoneleaf).
>>
>
> As 'stoneleaf', he has been active on 12  issues since June 2010 (nosy on
> 2 more). One patch is open and 5 have been applied (3 by Nick, 1 each by
> Antoine and R. David),  I would say that the enum code, which appears to be
> on the way to acceptance,  is equivalent to a few more typical issue
> patches.
>
> FWIW, This is enough for a +1 from me.
>
>
>      I think he has already
>> >signed the contributor agreement, and explicitly expressed interest to
>> >contribute directly to PEP 435.
>>
>
> That is the enum PEP.  http://www.python.org/dev/peps/pep-0435/
> I consider a (nontrivial) reference implementation to be a direct
> contribution even if he has not yet been pushing text changes.
>
>
>      >Any objections?
>>
>>  +1 for Ethan.
>>
>
> --
> Terry Jan Reedy
>
>
> _______________________________________________
> python-committers mailing list
> python-committers at python.org
> http://mail.python.org/mailman/listinfo/python-committers
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-committers/attachments/20130510/92aa8a0d/attachment.html>

From brett at python.org  Sat May 11 16:54:13 2013
From: brett at python.org (Brett Cannon)
Date: Sat, 11 May 2013 10:54:13 -0400
Subject: [python-committers] Commit rights to Ethan Furman
In-Reply-To: <CAF-Rda-zRvB5P-35ShW3M-xdeSdz62YrSca44X6qP+a8OY7D=g@mail.gmail.com>
References: <CAF-Rda-FUVQke0_yVSS2vXybzuLHG_t3cB774cyzfguGCJw3Og@mail.gmail.com>
	<20130506104645.1517aa32@anarchist>
	<CAF-Rda9aN5vwx6P-ZiSKU2_QSzr_Ce55J6AcOD8EnYpg5HZM_A@mail.gmail.com>
	<518ADAAD.1080304@udel.edu>
	<CAF-Rda-zRvB5P-35ShW3M-xdeSdz62YrSca44X6qP+a8OY7D=g@mail.gmail.com>
Message-ID: <CAP1=2W46CdLwK=Tox9GP+dJL6WHhp+x_udz5D-+hGVpVekY9hw@mail.gmail.com>

Ethan should now have commit rights and be subscribed to this list.

On Fri, May 10, 2013 at 9:08 AM, Eli Bendersky <eliben at gmail.com> wrote:
> Thanks!
>
> I'll go ahead and point Ethan to the dev guide, so he'll send his SSH keys
> to the appropriate place. Naturally I'm volunteering to mentor him in the
> initial work he'll be doing as a Python core developer. We'll start with
> getting an enum implementation committed (issue 17947). Since the
> implementation will almost certainly be based in large parts on Ethan's
> ref435 code, I think it's fair to let him commit that once it goes through a
> review.
>
> P.S. code review of on issue 17947 will be very much appreciated!
>
> Eli
>
>
>
> On Wed, May 8, 2013 at 4:07 PM, Terry Reedy <tjreedy at udel.edu> wrote:
>>
>> On 5/8/2013 4:44 PM, Eli Bendersky wrote:
>>
>> So I guess I can move forward with this unless there are objections in the
>> next day or two,
>>
>>
>> I have not responded before since Guido's approval seems sufficient ;-).
>> The main concrete step is that one of the repository supervisors add his
>> access key.
>>
>> On Mon, May 6, 2013 at 7:46 AM, Barry Warsaw <barry at python.org> wrote:
>>>
>>> On May 03, 2013, at 08:59 PM, Eli Bendersky wrote:
>>>
>>> >I'd like to propose to grant Ethan Furman commit rights. He's authored
>>> > PEP
>>> >309,
>>
>>
>> 409, not 309: http://www.python.org/dev/peps/pep-0409/
>>
>>
>>> has been very helpful in the Enum saga (and is the de-facto author of
>>> >the current reference implementation),
>>
>>
>> You, Barry, and Guido, who have also worked on enum, know him best and are
>> the principle supporters of this proposal. I gather that you all agree that
>> he has shown the 'cooperativeness' necessary to a collective project.
>>
>>
>>> and has also been active on the tracker for a couple of years (username
>>> stoneleaf).
>>
>>
>> As 'stoneleaf', he has been active on 12  issues since June 2010 (nosy on
>> 2 more). One patch is open and 5 have been applied (3 by Nick, 1 each by
>> Antoine and R. David),  I would say that the enum code, which appears to be
>> on the way to acceptance,  is equivalent to a few more typical issue
>> patches.
>>
>> FWIW, This is enough for a +1 from me.
>>
>>
>>> I think he has already
>>> >signed the contributor agreement, and explicitly expressed interest to
>>> >contribute directly to PEP 435.
>>
>>
>> That is the enum PEP.  http://www.python.org/dev/peps/pep-0435/
>> I consider a (nontrivial) reference implementation to be a direct
>> contribution even if he has not yet been pushing text changes.
>>
>>
>>> >Any objections?
>>>
>>> +1 for Ethan.
>>
>>
>> --
>> Terry Jan Reedy
>>
>>
>> _______________________________________________
>> python-committers mailing list
>> python-committers at python.org
>> http://mail.python.org/mailman/listinfo/python-committers
>>
>
>
> _______________________________________________
> python-committers mailing list
> python-committers at python.org
> http://mail.python.org/mailman/listinfo/python-committers
>

From eliben at gmail.com  Sat May 11 17:24:13 2013
From: eliben at gmail.com (Eli Bendersky)
Date: Sat, 11 May 2013 08:24:13 -0700
Subject: [python-committers] Commit rights to Ethan Furman
In-Reply-To: <CAP1=2W46CdLwK=Tox9GP+dJL6WHhp+x_udz5D-+hGVpVekY9hw@mail.gmail.com>
References: <CAF-Rda-FUVQke0_yVSS2vXybzuLHG_t3cB774cyzfguGCJw3Og@mail.gmail.com>
	<20130506104645.1517aa32@anarchist>
	<CAF-Rda9aN5vwx6P-ZiSKU2_QSzr_Ce55J6AcOD8EnYpg5HZM_A@mail.gmail.com>
	<518ADAAD.1080304@udel.edu>
	<CAF-Rda-zRvB5P-35ShW3M-xdeSdz62YrSca44X6qP+a8OY7D=g@mail.gmail.com>
	<CAP1=2W46CdLwK=Tox9GP+dJL6WHhp+x_udz5D-+hGVpVekY9hw@mail.gmail.com>
Message-ID: <CAF-Rda90xbJatRPKTqNRQrJrGtupgLH338FyXcre6O-9idE6UQ@mail.gmail.com>

Thanks, Brett!


On Sat, May 11, 2013 at 7:54 AM, Brett Cannon <brett at python.org> wrote:

> Ethan should now have commit rights and be subscribed to this list.
>
> On Fri, May 10, 2013 at 9:08 AM, Eli Bendersky <eliben at gmail.com> wrote:
> > Thanks!
> >
> > I'll go ahead and point Ethan to the dev guide, so he'll send his SSH
> keys
> > to the appropriate place. Naturally I'm volunteering to mentor him in the
> > initial work he'll be doing as a Python core developer. We'll start with
> > getting an enum implementation committed (issue 17947). Since the
> > implementation will almost certainly be based in large parts on Ethan's
> > ref435 code, I think it's fair to let him commit that once it goes
> through a
> > review.
> >
> > P.S. code review of on issue 17947 will be very much appreciated!
> >
> > Eli
> >
> >
> >
> > On Wed, May 8, 2013 at 4:07 PM, Terry Reedy <tjreedy at udel.edu> wrote:
> >>
> >> On 5/8/2013 4:44 PM, Eli Bendersky wrote:
> >>
> >> So I guess I can move forward with this unless there are objections in
> the
> >> next day or two,
> >>
> >>
> >> I have not responded before since Guido's approval seems sufficient ;-).
> >> The main concrete step is that one of the repository supervisors add his
> >> access key.
> >>
> >> On Mon, May 6, 2013 at 7:46 AM, Barry Warsaw <barry at python.org> wrote:
> >>>
> >>> On May 03, 2013, at 08:59 PM, Eli Bendersky wrote:
> >>>
> >>> >I'd like to propose to grant Ethan Furman commit rights. He's authored
> >>> > PEP
> >>> >309,
> >>
> >>
> >> 409, not 309: http://www.python.org/dev/peps/pep-0409/
> >>
> >>
> >>> has been very helpful in the Enum saga (and is the de-facto author of
> >>> >the current reference implementation),
> >>
> >>
> >> You, Barry, and Guido, who have also worked on enum, know him best and
> are
> >> the principle supporters of this proposal. I gather that you all agree
> that
> >> he has shown the 'cooperativeness' necessary to a collective project.
> >>
> >>
> >>> and has also been active on the tracker for a couple of years (username
> >>> stoneleaf).
> >>
> >>
> >> As 'stoneleaf', he has been active on 12  issues since June 2010 (nosy
> on
> >> 2 more). One patch is open and 5 have been applied (3 by Nick, 1 each by
> >> Antoine and R. David),  I would say that the enum code, which appears
> to be
> >> on the way to acceptance,  is equivalent to a few more typical issue
> >> patches.
> >>
> >> FWIW, This is enough for a +1 from me.
> >>
> >>
> >>> I think he has already
> >>> >signed the contributor agreement, and explicitly expressed interest to
> >>> >contribute directly to PEP 435.
> >>
> >>
> >> That is the enum PEP.  http://www.python.org/dev/peps/pep-0435/
> >> I consider a (nontrivial) reference implementation to be a direct
> >> contribution even if he has not yet been pushing text changes.
> >>
> >>
> >>> >Any objections?
> >>>
> >>> +1 for Ethan.
> >>
> >>
> >> --
> >> Terry Jan Reedy
> >>
> >>
> >> _______________________________________________
> >> python-committers mailing list
> >> python-committers at python.org
> >> http://mail.python.org/mailman/listinfo/python-committers
> >>
> >
> >
> > _______________________________________________
> > python-committers mailing list
> > python-committers at python.org
> > http://mail.python.org/mailman/listinfo/python-committers
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-committers/attachments/20130511/c3b53005/attachment.html>

From ethan at stoneleaf.us  Sun May 12 07:10:32 2013
From: ethan at stoneleaf.us (Ethan Furman)
Date: Sat, 11 May 2013 22:10:32 -0700
Subject: [python-committers] Introduction
Message-ID: <518F2448.4080909@stoneleaf.us>

Greetings!

I was recently added as a core-dev (yes, saying it still makes me smile ;).

Python is an awesome language and I am happy to be a part of it.

Minor history:  I authored PEP 409 (raise ... from None), and authored most of the reference implementation for Enums 
(PEP 435).  I've been programming for a couple decades in languages ranging from x86 assembly to AS/400 CL (yeah, not 
really a language :( ) to Visual Foxpro, and I'm acquanted with several others.  Once I started using Python, however, 
my desire to spend any valuable free programming time on other languages just died.  Although I still need to get better 
at C (for Python!).

This is the first time I've really had the chance to work with a team, and I'm happy to say it has been productive, 
educational, and enlightening.

--
~Ethan~

From solipsis at pitrou.net  Sun May 12 13:18:16 2013
From: solipsis at pitrou.net (Antoine Pitrou)
Date: Sun, 12 May 2013 13:18:16 +0200
Subject: [python-committers] Introduction
In-Reply-To: <518F2448.4080909@stoneleaf.us>
References: <518F2448.4080909@stoneleaf.us>
Message-ID: <1368357496.2535.7.camel@fsol>

Le samedi 11 mai 2013 ? 22:10 -0700, Ethan Furman a ?crit :
> Greetings!
> 
> I was recently added as a core-dev (yes, saying it still makes me
> smile ;).
> 
> Python is an awesome language and I am happy to be a part of it.

Welcome to you! Congratulations for your new duty :-)

> Once I started using Python, however, 
> my desire to spend any valuable free programming time on other
> languages just died.

This sounds strangely familiar to me.

Regards

Antoine.



From eliben at gmail.com  Sun May 12 14:57:08 2013
From: eliben at gmail.com (Eli Bendersky)
Date: Sun, 12 May 2013 05:57:08 -0700
Subject: [python-committers] Introduction
In-Reply-To: <518F2448.4080909@stoneleaf.us>
References: <518F2448.4080909@stoneleaf.us>
Message-ID: <CAF-Rda9DMchjkmFGat4=+cNXaiGFcRdY398vQ3Kwt+s_+hLyzA@mail.gmail.com>

On Sat, May 11, 2013 at 10:10 PM, Ethan Furman <ethan at stoneleaf.us> wrote:

> Greetings!
>
> I was recently added as a core-dev (yes, saying it still makes me smile ;).
>
> Python is an awesome language and I am happy to be a part of it.
>
> Minor history:  I authored PEP 409 (raise ... from None), and authored
> most of the reference implementation for Enums (PEP 435).  I've been
> programming for a couple decades in languages ranging from x86 assembly to
> AS/400 CL (yeah, not really a language :( ) to Visual Foxpro, and I'm
> acquanted with several others.  Once I started using Python, however, my
> desire to spend any valuable free programming time on other languages just
> died.  Although I still need to get better at C (for Python!).
>
> This is the first time I've really had the chance to work with a team, and
> I'm happy to say it has been productive, educational, and enlightening.
>

Welcome, Ethan!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-committers/attachments/20130512/e53e555f/attachment.html>

From jackdied at gmail.com  Sun May 12 21:44:54 2013
From: jackdied at gmail.com (Jack Diederich)
Date: Sun, 12 May 2013 15:44:54 -0400
Subject: [python-committers] Introduction
In-Reply-To: <518F2448.4080909@stoneleaf.us>
References: <518F2448.4080909@stoneleaf.us>
Message-ID: <CACLn2+1SSUxEz5vmbd_UxWZKE8sp8kcf0Bqet_fkEG997SkUtw@mail.gmail.com>

Welcome!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-committers/attachments/20130512/b2f8620c/attachment.html>

From senthil at uthcode.com  Tue May 14 04:50:01 2013
From: senthil at uthcode.com (Senthil Kumaran)
Date: Mon, 13 May 2013 19:50:01 -0700
Subject: [python-committers] Introduction
In-Reply-To: <518F2448.4080909@stoneleaf.us>
References: <518F2448.4080909@stoneleaf.us>
Message-ID: <CAPOVWOT_zmbeprskiNC83Q3UbotevrPcW-L8jpHRLp1uN5U5qg@mail.gmail.com>

On Sat, May 11, 2013 at 10:10 PM, Ethan Furman <ethan at stoneleaf.us> wrote:

> Minor history:  I authored PEP 409 (raise ... from None), and authored
> most of the reference implementation for Enums (PEP 435).  I've been
> programming for a couple decades in languages ranging from x86 assembly to
> AS/400 CL (yeah, not really a language :( ) to Visual Foxpro, and I'm
> acquanted with several others.  Once I started using Python, however, my
> desire to spend any valuable free programming time on other languages just
> died.  Although I still need to get better at C (for Python!).
>

Congratulations and welcome, Ethan.

-- 
Senthil
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-committers/attachments/20130513/d1fce1ea/attachment.html>

From georg at python.org  Thu May 16 07:20:30 2013
From: georg at python.org (Georg Brandl)
Date: Thu, 16 May 2013 07:20:30 +0200
Subject: [python-committers] [RELEASED] Python 3.2.5 and Python 3.3.2
Message-ID: <51946C9E.10607@python.org>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On behalf of the Python development team, I am pleased to announce the
releases of Python 3.2.5 and 3.3.2.

The releases fix a few regressions in 3.2.4 and 3.3.1 in the zipfile, gzip
and xml.sax modules.  Details can be found in the changelogs:

    http://hg.python.org/cpython/file/v3.2.5/Misc/NEWS  and
    http://hg.python.org/cpython/file/v3.3.2/Misc/NEWS

To download Python 3.2.5 or Python 3.3.2, visit:

    http://www.python.org/download/releases/3.2.5/  or
    http://www.python.org/download/releases/3.3.2/

respectively.  As always, please report bugs to

    http://bugs.python.org/

(Thank you to those who reported these regressions.)

Enjoy!

- -- 
Georg Brandl, Release Manager
georg at python.org
(on behalf of the entire python-dev team and all contributors)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)

iEYEARECAAYFAlGUbJ4ACgkQN9GcIYhpnLDH8ACdEM4k7bobLJsFmCb49zuwQR3W
EjgAoIWAOFNhJNdTAWEGSWqFWUP20wrb
=YnPr
-----END PGP SIGNATURE-----

From brett at python.org  Fri May 24 14:24:25 2013
From: brett at python.org (Brett Cannon)
Date: Fri, 24 May 2013 08:24:25 -0400
Subject: [python-committers] what's going on with Misc/NEWS?
Message-ID: <CAP1=2W55By0cjq2J0cxcMuQKoCQLc+ty0PKtY6Ud0h6UpMsAeQ@mail.gmail.com>

I was trying to do a simple merge of a doc change between 3.3 and
default and the usual Misc/NEWS conflict came up. But when I looked at
the diff it was massive! Turns out that Misc/NEWS in default goes from
3.3.1rc1 to 3.4.0a1
(http://hg.python.org/cpython/file/24ffb0148729/Misc/NEWS) while
Misc/NEWS in 3.3 goes properly through all versions between 3.3.1rc1
to 3.3.3rc1 (http://hg.python.org/cpython/file/3c4a5dc29417/Misc/NEWS).

I have to get to work so I don't have time to fix this, but if someone
does have the time to unwind this mix-up that has accumulated that
would be great. And maybe it's finally time to bite the bullet and
come up with some way to automatically generate Misc/NEWS from commit
messages.

From ncoghlan at gmail.com  Fri May 24 15:00:37 2013
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Fri, 24 May 2013 23:00:37 +1000
Subject: [python-committers] what's going on with Misc/NEWS?
In-Reply-To: <CAP1=2W55By0cjq2J0cxcMuQKoCQLc+ty0PKtY6Ud0h6UpMsAeQ@mail.gmail.com>
References: <CAP1=2W55By0cjq2J0cxcMuQKoCQLc+ty0PKtY6Ud0h6UpMsAeQ@mail.gmail.com>
Message-ID: <CADiSq7dezvi=ATp1mAS6h36A7f0FbpQb39k9ZvjinY4zVLSt5A@mail.gmail.com>

On Fri, May 24, 2013 at 10:24 PM, Brett Cannon <brett at python.org> wrote:
> I was trying to do a simple merge of a doc change between 3.3 and
> default and the usual Misc/NEWS conflict came up. But when I looked at
> the diff it was massive! Turns out that Misc/NEWS in default goes from
> 3.3.1rc1 to 3.4.0a1
> (http://hg.python.org/cpython/file/24ffb0148729/Misc/NEWS) while
> Misc/NEWS in 3.3 goes properly through all versions between 3.3.1rc1
> to 3.3.3rc1 (http://hg.python.org/cpython/file/3c4a5dc29417/Misc/NEWS).
>
> I have to get to work so I don't have time to fix this, but if someone
> does have the time to unwind this mix-up that has accumulated that
> would be great. And maybe it's finally time to bite the bullet and
> come up with some way to automatically generate Misc/NEWS from commit
> messages.

No, commit messages do not a NEWS file make. The audiences are
different (current and future developers vs interested end users), so
it doesn't make sense to try to use the same content. Using commit
messages also makes it annoyingly difficult to edit erroneous entries,
as well as needing to come up with conventions to indicate commits
which *shouldn't* get a log entry.

What *does* make sense is to use a directory structure (which version
control systems handle nicely) rather than a single file (which is
prone to spurious context based conflicts). Twisted has their notion
of "topfiles (see
https://twistedmatrix.com/trac/wiki/ReviewProcess#Newsfiles) and for
Beaker we adopted the model of simply dumping draft release note
snippets into a "whatsnew/next" subdirectory and using a Sphinx
wildcard to display them in the draft docs (we edit them into
something more coherent as part of the release process, since they're
our equivalent of What's New rather than NEWS).

For Python, it would make sense to me if we took the existing
subcategories in NEWS and turned them into a NEWS.in directory tree:

    NEWS.in/
        legacy.txt # The NEWS contents from past releases
        3.4.0a1/
            core/
                misc.txt  # Any changes with no tracker entry
                issue12345.txt  # Single bullet point
                issue54321.txt  # Single bullet point
                ...
            library/
                ...
            tests/
                ...
            docs/
                ...
            c-api/
                ...
            idle/
                ...
            build/
                ...

The trunk NEWS.in would then end up with full notes for all branches
that have been merged forward. The NEWS file generation for each
version would be designed to take care of matching up the
corresponding maintenance releases when deciding which entries to
include.

Of course, we've talked about doing something like this before, it's
just never irritated anyone enough for them to sit down and *write*
the associated NEWS file generator, or the code to split the existing
NEWS file for the active branches :)

Cheers,
Nick.

--
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia

From storchaka at gmail.com  Fri May 24 15:12:03 2013
From: storchaka at gmail.com (Serhiy Storchaka)
Date: Fri, 24 May 2013 16:12:03 +0300
Subject: [python-committers] what's going on with Misc/NEWS?
In-Reply-To: <CAP1=2W55By0cjq2J0cxcMuQKoCQLc+ty0PKtY6Ud0h6UpMsAeQ@mail.gmail.com>
References: <CAP1=2W55By0cjq2J0cxcMuQKoCQLc+ty0PKtY6Ud0h6UpMsAeQ@mail.gmail.com>
Message-ID: <knnouu$74u$1@ger.gmane.org>

24.05.13 15:24, Brett Cannon ???????(??):
> I was trying to do a simple merge of a doc change between 3.3 and
> default and the usual Misc/NEWS conflict came up. But when I looked at
> the diff it was massive! Turns out that Misc/NEWS in default goes from
> 3.3.1rc1 to 3.4.0a1
> (http://hg.python.org/cpython/file/24ffb0148729/Misc/NEWS) while
> Misc/NEWS in 3.3 goes properly through all versions between 3.3.1rc1
> to 3.3.3rc1 (http://hg.python.org/cpython/file/3c4a5dc29417/Misc/NEWS).
>
> I have to get to work so I don't have time to fix this, but if someone
> does have the time to unwind this mix-up that has accumulated that
> would be great. And maybe it's finally time to bite the bullet and
> come up with some way to automatically generate Misc/NEWS from commit
> messages.

I had untangled some Misc/NEWS defects in issue17221 [1] but the work is 
not finished yet.

[1] http://bugs.python.org/issue17221


From brett at python.org  Fri May 24 16:09:21 2013
From: brett at python.org (Brett Cannon)
Date: Fri, 24 May 2013 10:09:21 -0400
Subject: [python-committers] what's going on with Misc/NEWS?
In-Reply-To: <CADiSq7dezvi=ATp1mAS6h36A7f0FbpQb39k9ZvjinY4zVLSt5A@mail.gmail.com>
References: <CAP1=2W55By0cjq2J0cxcMuQKoCQLc+ty0PKtY6Ud0h6UpMsAeQ@mail.gmail.com>
	<CADiSq7dezvi=ATp1mAS6h36A7f0FbpQb39k9ZvjinY4zVLSt5A@mail.gmail.com>
Message-ID: <CAP1=2W5UpoZLugDRxAS1ZyzxvSiK4LQUq_EL2ktHAm6xoWhXrQ@mail.gmail.com>

On Fri, May 24, 2013 at 9:00 AM, Nick Coghlan <ncoghlan at gmail.com> wrote:
> On Fri, May 24, 2013 at 10:24 PM, Brett Cannon <brett at python.org> wrote:
>> I was trying to do a simple merge of a doc change between 3.3 and
>> default and the usual Misc/NEWS conflict came up. But when I looked at
>> the diff it was massive! Turns out that Misc/NEWS in default goes from
>> 3.3.1rc1 to 3.4.0a1
>> (http://hg.python.org/cpython/file/24ffb0148729/Misc/NEWS) while
>> Misc/NEWS in 3.3 goes properly through all versions between 3.3.1rc1
>> to 3.3.3rc1 (http://hg.python.org/cpython/file/3c4a5dc29417/Misc/NEWS).
>>
>> I have to get to work so I don't have time to fix this, but if someone
>> does have the time to unwind this mix-up that has accumulated that
>> would be great. And maybe it's finally time to bite the bullet and
>> come up with some way to automatically generate Misc/NEWS from commit
>> messages.
>
> No, commit messages do not a NEWS file make. The audiences are
> different (current and future developers vs interested end users), so
> it doesn't make sense to try to use the same content. Using commit
> messages also makes it annoyingly difficult to edit erroneous entries,
> as well as needing to come up with conventions to indicate commits
> which *shouldn't* get a log entry.

I don't know about you, but my first sentence (i.e. up to \n\n) is
essentially what I put into NEWS anyway so making it work so that
developer details go after that is not really an issue. Yes, coming up
with a way to flag commits as not NEWS-worthy would be needed, but I
don't think that would be difficult.

>
> What *does* make sense is to use a directory structure (which version
> control systems handle nicely) rather than a single file (which is
> prone to spurious context based conflicts).

I sent a followup email to myself but unfortunately Gmail sent it from
another address so it got rejected.

> Twisted has their notion
> of "topfiles (see
> https://twistedmatrix.com/trac/wiki/ReviewProcess#Newsfiles) and for
> Beaker we adopted the model of simply dumping draft release note
> snippets into a "whatsnew/next" subdirectory and using a Sphinx
> wildcard to display them in the draft docs (we edit them into
> something more coherent as part of the release process, since they're
> our equivalent of What's New rather than NEWS).
>
> For Python, it would make sense to me if we took the existing
> subcategories in NEWS and turned them into a NEWS.in directory tree:
>
>     NEWS.in/
>         legacy.txt # The NEWS contents from past releases
>         3.4.0a1/
>             core/
>                 misc.txt  # Any changes with no tracker entry
>                 issue12345.txt  # Single bullet point
>                 issue54321.txt  # Single bullet point
>                 ...
>             library/
>                 ...
>             tests/
>                 ...
>             docs/
>                 ...
>             c-api/
>                 ...
>             idle/
>                 ...
>             build/
>                 ...
>
> The trunk NEWS.in would then end up with full notes for all branches
> that have been merged forward. The NEWS file generation for each
> version would be designed to take care of matching up the
> corresponding maintenance releases when deciding which entries to
> include.
>
> Of course, we've talked about doing something like this before, it's
> just never irritated anyone enough for them to sit down and *write*
> the associated NEWS file generator, or the code to split the existing
> NEWS file for the active branches :)

I think that's overly complicated. I don't see why we need anything
more than simply NEWS/3.4, NEWS/3.3, etc. and just split the files per
feature release since that's the interest (and merge) boundary. And do
we really need a merged NEWS file at that granularity?

From solipsis at pitrou.net  Fri May 24 18:39:16 2013
From: solipsis at pitrou.net (Antoine Pitrou)
Date: Fri, 24 May 2013 18:39:16 +0200 (CEST)
Subject: [python-committers] what's going on with Misc/NEWS?
In-Reply-To: <CAP1=2W5UpoZLugDRxAS1ZyzxvSiK4LQUq_EL2ktHAm6xoWhXrQ@mail.gmail.com>
References: <CAP1=2W55By0cjq2J0cxcMuQKoCQLc+ty0PKtY6Ud0h6UpMsAeQ@mail.gmail.com>
	<CADiSq7dezvi=ATp1mAS6h36A7f0FbpQb39k9ZvjinY4zVLSt5A@mail.gmail.com>
	<CAP1=2W5UpoZLugDRxAS1ZyzxvSiK4LQUq_EL2ktHAm6xoWhXrQ@mail.gmail.com>
Message-ID: <63724bbaea84f6591bb36288355cd96f.squirrel@webmail.nerim.net>


Brett wrote:
>> Of course, we've talked about doing something like this before, it's
>> just never irritated anyone enough for them to sit down and *write*
>> the associated NEWS file generator, or the code to split the existing
>> NEWS file for the active branches :)
>
> I think that's overly complicated.

Agreed. I'm not surprised Twisted uses something like that :-), but we
don't need
that level of complexity.

> I don't see why we need anything
> more than simply NEWS/3.4, NEWS/3.3, etc. and just split the files per
> feature release since that's the interest (and merge) boundary.

You'll have to copy stuff by hand, though, if you don't want to rely on the
merge machinery. So we have two possible file layouts:

* (current) a single Misc/NEWS is merged from branch to branch. Pro: hg merge
copies the text for you. Con: hg merge sometimes screws up and you have to
clean up a large conflict.

* a dedicated Misc/NEWS-x.y per major version. Pro: no merge conflicts ever.
Con: you have to copy the message by hand when merging a bug fix to the upper
branch. Con: it's easy to forget to copy the message (hg won't yell if you
don't
do it), so people *will* forget (and it's annoying grunt work for those who
notice it).

The major con with the current scheme *might* be solved by a dedicated hg
extension, but someone needs to have enough free time and passion to try and
write it :-)

> And do
> we really need a merged NEWS file at that granularity?

Not really, IMO.

Regards

Antoine.



From rdmurray at bitdance.com  Fri May 24 19:33:17 2013
From: rdmurray at bitdance.com (R. David Murray)
Date: Fri, 24 May 2013 13:33:17 -0400
Subject: [python-committers] what's going on with Misc/NEWS?
In-Reply-To: <63724bbaea84f6591bb36288355cd96f.squirrel@webmail.nerim.net>
References: <CAP1=2W55By0cjq2J0cxcMuQKoCQLc+ty0PKtY6Ud0h6UpMsAeQ@mail.gmail.com>
	<CADiSq7dezvi=ATp1mAS6h36A7f0FbpQb39k9ZvjinY4zVLSt5A@mail.gmail.com>
	<CAP1=2W5UpoZLugDRxAS1ZyzxvSiK4LQUq_EL2ktHAm6xoWhXrQ@mail.gmail.com>
	<63724bbaea84f6591bb36288355cd96f.squirrel@webmail.nerim.net>
Message-ID: <20130524173317.61C47250BE2@webabinitio.net>

On Fri, 24 May 2013 18:39:16 +0200, "Antoine Pitrou" <solipsis at pitrou.net> wrote:
> Brett wrote:
> >> Of course, we've talked about doing something like this before, it's
> >> just never irritated anyone enough for them to sit down and *write*
> >> the associated NEWS file generator, or the code to split the existing
> >> NEWS file for the active branches :)
> >
> > I think that's overly complicated.
> 
> Agreed. I'm not surprised Twisted uses something like that :-), but we
> don't need
> that level of complexity.
> 
> > I don't see why we need anything
> > more than simply NEWS/3.4, NEWS/3.3, etc. and just split the files per
> > feature release since that's the interest (and merge) boundary.
> 
> You'll have to copy stuff by hand, though, if you don't want to rely on the
> merge machinery. So we have two possible file layouts:
> 
> * (current) a single Misc/NEWS is merged from branch to branch. Pro: hg merge
> copies the text for you. Con: hg merge sometimes screws up and you have to
> clean up a large conflict.
> 
> * a dedicated Misc/NEWS-x.y per major version. Pro: no merge conflicts ever.
> Con: you have to copy the message by hand when merging a bug fix to the upper
> branch. Con: it's easy to forget to copy the message (hg won't yell if you
> don't
> do it), so people *will* forget (and it's annoying grunt work for those who
> notice it).
> 
> The major con with the current scheme *might* be solved by a dedicated hg
> extension, but someone needs to have enough free time and passion to try and
> write it :-)

I agree with Antoine here.  I'd rather deal with the occasional conflicts
(which goes: revert Misc/NEWS change, copy news entry) and get automatic
merge some of the time, rather than have to *always* remember to copy
the news entry, with no warning if I forget.  The current way either
the merge works[*], or you get an error reminding you you have to do the
revert/copy dance.

--David

[*] So far I haven't had a case of what sometimes happened in svn,
where the merge would appear to work but would be in the wrong
section. I think this is because we moved stuff to HISTORY, or it
may be that hg merge is just smarter than svn merge.

From tjreedy at udel.edu  Fri May 24 20:03:42 2013
From: tjreedy at udel.edu (Terry Reedy)
Date: Fri, 24 May 2013 14:03:42 -0400
Subject: [python-committers] what's going on with Misc/NEWS?
In-Reply-To: <CAP1=2W55By0cjq2J0cxcMuQKoCQLc+ty0PKtY6Ud0h6UpMsAeQ@mail.gmail.com>
References: <CAP1=2W55By0cjq2J0cxcMuQKoCQLc+ty0PKtY6Ud0h6UpMsAeQ@mail.gmail.com>
Message-ID: <519FAB7E.1010605@udel.edu>

On 5/24/2013 8:24 AM, Brett Cannon wrote:
> I was trying to do a simple merge of a doc change between 3.3 and
> default and the usual Misc/NEWS conflict came up.
I have had things like this happen and after pain iwth kdiff3 just 
edited the default version
>   But when I looked at
> the diff it was massive! Turns out that Misc/NEWS in default goes from
> 3.3.1rc1 to 3.4.0a1
> (http://hg.python.org/cpython/file/24ffb0148729/Misc/NEWS) while
> Misc/NEWS in 3.3 goes properly through all versions between 3.3.1rc1
> to 3.3.3rc1 (http://hg.python.org/cpython/file/3c4a5dc29417/Misc/NEWS).
I do not know if I had the same cause. Never looked that far.
> I have to get to work so I don't have time to fix this, but if someone
> does have the time to unwind this mix-up that has accumulated that
> would be great. And maybe it's finally time to bite the bullet and
> come up with some way to automatically generate Misc/NEWS from commit
> messages.

+100 on ending or ameliorating NEWS conflict hell. I do fewer commits 
because of it.

Proposal: If the commit message has a line like
***Library
then everything *above that line is put into NEWS. This makes automatic 
generation optional and optionally allows additional non-NEWS extras.

The immediate problem is conflict with the lower context, the three 
lines below
Library
---------
<blank>

which is often different between 3.3 and 3.4 and possibly changed anyway 
since the patch
was made. Can hg be told to ignore the lower context and just match the 
3 upper context lines for this file?

The larger problem is that our workplace design subverts the premise of 
non-checkout repositories, that people usually work on different areas 
of files, making conflicts rare. Our current design makes conflict normal.

--
Terry Jan Reedy


From brett at python.org  Fri May 24 20:23:21 2013
From: brett at python.org (Brett Cannon)
Date: Fri, 24 May 2013 14:23:21 -0400
Subject: [python-committers] what's going on with Misc/NEWS?
In-Reply-To: <63724bbaea84f6591bb36288355cd96f.squirrel@webmail.nerim.net>
References: <CAP1=2W55By0cjq2J0cxcMuQKoCQLc+ty0PKtY6Ud0h6UpMsAeQ@mail.gmail.com>
	<CADiSq7dezvi=ATp1mAS6h36A7f0FbpQb39k9ZvjinY4zVLSt5A@mail.gmail.com>
	<CAP1=2W5UpoZLugDRxAS1ZyzxvSiK4LQUq_EL2ktHAm6xoWhXrQ@mail.gmail.com>
	<63724bbaea84f6591bb36288355cd96f.squirrel@webmail.nerim.net>
Message-ID: <CAP1=2W4rTF9+SZqotwprNug3=shWsB0iEEbqxNa3f5uVPxjNnA@mail.gmail.com>

On Fri, May 24, 2013 at 12:39 PM, Antoine Pitrou <solipsis at pitrou.net> wrote:
>
> Brett wrote:
>>> Of course, we've talked about doing something like this before, it's
>>> just never irritated anyone enough for them to sit down and *write*
>>> the associated NEWS file generator, or the code to split the existing
>>> NEWS file for the active branches :)
>>
>> I think that's overly complicated.
>
> Agreed. I'm not surprised Twisted uses something like that :-), but we
> don't need
> that level of complexity.
>
>> I don't see why we need anything
>> more than simply NEWS/3.4, NEWS/3.3, etc. and just split the files per
>> feature release since that's the interest (and merge) boundary.
>
> You'll have to copy stuff by hand, though, if you don't want to rely on the
> merge machinery. So we have two possible file layouts:
>
> * (current) a single Misc/NEWS is merged from branch to branch. Pro: hg merge
> copies the text for you. Con: hg merge sometimes screws up and you have to
> clean up a large conflict.

But hg won't let you simply revert; at least today it said I had to
either resolve the conflict or do an update -C which tosses the whole
change which is just annoying.

>
> * a dedicated Misc/NEWS-x.y per major version. Pro: no merge conflicts ever.
> Con: you have to copy the message by hand when merging a bug fix to the upper
> branch. Con: it's easy to forget to copy the message (hg won't yell if you
> don't
> do it), so people *will* forget (and it's annoying grunt work for those who
> notice it).

So the question becomes do we really need to copy every entry? Beyond
simply being redundant, it's annoying when doing merges because of the
constant conflicts. I would argue that in bugfix releases we could say
in the issue whether it stops there or propagates into the next
feature release (e.g. [regression] or [bugfix]). Then it becomes habit
to always specify that (and maybe even have a Mercurial extension that
detects when neither is specified and throws a fit).

Either way the status quo makes me not want to fix small doc typos
like a missing parenthesis since this is enough of a hassle to not
make it worth it.

>
> The major con with the current scheme *might* be solved by a dedicated hg
> extension, but someone needs to have enough free time and passion to try and
> write it :-)

Wouldn't an extension that does the copying be easier than resolving
the conflict?

-Brett

>
>> And do
>> we really need a merged NEWS file at that granularity?
>
> Not really, IMO.
>
> Regards
>
> Antoine.
>
>
> _______________________________________________
> python-committers mailing list
> python-committers at python.org
> http://mail.python.org/mailman/listinfo/python-committers

From solipsis at pitrou.net  Fri May 24 20:27:51 2013
From: solipsis at pitrou.net (Antoine Pitrou)
Date: Fri, 24 May 2013 20:27:51 +0200
Subject: [python-committers] what's going on with Misc/NEWS?
In-Reply-To: <CAP1=2W4rTF9+SZqotwprNug3=shWsB0iEEbqxNa3f5uVPxjNnA@mail.gmail.com>
References: <CAP1=2W55By0cjq2J0cxcMuQKoCQLc+ty0PKtY6Ud0h6UpMsAeQ@mail.gmail.com>
	<CADiSq7dezvi=ATp1mAS6h36A7f0FbpQb39k9ZvjinY4zVLSt5A@mail.gmail.com>
	<CAP1=2W5UpoZLugDRxAS1ZyzxvSiK4LQUq_EL2ktHAm6xoWhXrQ@mail.gmail.com>
	<63724bbaea84f6591bb36288355cd96f.squirrel@webmail.nerim.net>
	<CAP1=2W4rTF9+SZqotwprNug3=shWsB0iEEbqxNa3f5uVPxjNnA@mail.gmail.com>
Message-ID: <1369420071.2559.3.camel@fsol>

Le vendredi 24 mai 2013 ? 14:23 -0400, Brett Cannon a ?crit :
> > You'll have to copy stuff by hand, though, if you don't want to rely on the
> > merge machinery. So we have two possible file layouts:
> >
> > * (current) a single Misc/NEWS is merged from branch to branch. Pro: hg merge
> > copies the text for you. Con: hg merge sometimes screws up and you have to
> > clean up a large conflict.
> 
> But hg won't let you simply revert;

hg rev -r <branch name> Misc/NEWS

> > * a dedicated Misc/NEWS-x.y per major version. Pro: no merge conflicts ever.
> > Con: you have to copy the message by hand when merging a bug fix to the upper
> > branch. Con: it's easy to forget to copy the message (hg won't yell if you
> > don't
> > do it), so people *will* forget (and it's annoying grunt work for those who
> > notice it).
> 
> So the question becomes do we really need to copy every entry? Beyond
> simply being redundant, it's annoying when doing merges because of the
> constant conflicts. I would argue that in bugfix releases we could say
> in the issue whether it stops there or propagates into the next
> feature release (e.g. [regression] or [bugfix]). Then it becomes habit
> to always specify that (and maybe even have a Mercurial extension that
> detects when neither is specified and throws a fit).

Then Misc/NEWS* become harder to read for third parties, since reading
Misc/NEWS-3.4 won't tell you everything that happened in 3.4.

> Either way the status quo makes me not want to fix small doc typos
> like a missing parenthesis since this is enough of a hassle to not
> make it worth it.

Do you mean Mics/NEWS doc typos?

> > The major con with the current scheme *might* be solved by a dedicated hg
> > extension, but someone needs to have enough free time and passion to try and
> > write it :-)
> 
> Wouldn't an extension that does the copying be easier than resolving
> the conflict?

Sure, it would be. Like Nick said: if you are motivated enough to write
the extension... :-)

Regards

Antoine.



From brett at python.org  Fri May 24 21:26:29 2013
From: brett at python.org (Brett Cannon)
Date: Fri, 24 May 2013 15:26:29 -0400
Subject: [python-committers] what's going on with Misc/NEWS?
In-Reply-To: <1369420071.2559.3.camel@fsol>
References: <CAP1=2W55By0cjq2J0cxcMuQKoCQLc+ty0PKtY6Ud0h6UpMsAeQ@mail.gmail.com>
	<CADiSq7dezvi=ATp1mAS6h36A7f0FbpQb39k9ZvjinY4zVLSt5A@mail.gmail.com>
	<CAP1=2W5UpoZLugDRxAS1ZyzxvSiK4LQUq_EL2ktHAm6xoWhXrQ@mail.gmail.com>
	<63724bbaea84f6591bb36288355cd96f.squirrel@webmail.nerim.net>
	<CAP1=2W4rTF9+SZqotwprNug3=shWsB0iEEbqxNa3f5uVPxjNnA@mail.gmail.com>
	<1369420071.2559.3.camel@fsol>
Message-ID: <CAP1=2W5nAjHZNYnXk=Y+68fg1Zz=cbDY_dFnv9NZvh-YPzStwQ@mail.gmail.com>

On Fri, May 24, 2013 at 2:27 PM, Antoine Pitrou <solipsis at pitrou.net> wrote:
> Le vendredi 24 mai 2013 ? 14:23 -0400, Brett Cannon a ?crit :
>> > You'll have to copy stuff by hand, though, if you don't want to rely on the
>> > merge machinery. So we have two possible file layouts:
>> >
>> > * (current) a single Misc/NEWS is merged from branch to branch. Pro: hg merge
>> > copies the text for you. Con: hg merge sometimes screws up and you have to
>> > clean up a large conflict.
>>
>> But hg won't let you simply revert;
>
> hg rev -r <branch name> Misc/NEWS

I'll add that to the devguide if it works for me next time.

>
>> > * a dedicated Misc/NEWS-x.y per major version. Pro: no merge conflicts ever.
>> > Con: you have to copy the message by hand when merging a bug fix to the upper
>> > branch. Con: it's easy to forget to copy the message (hg won't yell if you
>> > don't
>> > do it), so people *will* forget (and it's annoying grunt work for those who
>> > notice it).
>>
>> So the question becomes do we really need to copy every entry? Beyond
>> simply being redundant, it's annoying when doing merges because of the
>> constant conflicts. I would argue that in bugfix releases we could say
>> in the issue whether it stops there or propagates into the next
>> feature release (e.g. [regression] or [bugfix]). Then it becomes habit
>> to always specify that (and maybe even have a Mercurial extension that
>> detects when neither is specified and throws a fit).
>
> Then Misc/NEWS* become harder to read for third parties, since reading
> Misc/NEWS-3.4 won't tell you everything that happened in 3.4.

This is when we could have a script that just pulled from both 3.3 and
3.4 NEWS files and makes a single one.

>
>> Either way the status quo makes me not want to fix small doc typos
>> like a missing parenthesis since this is enough of a hassle to not
>> make it worth it.
>
> Do you mean Mics/NEWS doc typos?

No I mean typos in the docs. For instance, I found a missing
parenthesis in the docs for some module, but backporting it is enough
of a pain that I don't want to bother. The only reason I did this one
for sys is because it clarified semantics.

>
>> > The major con with the current scheme *might* be solved by a dedicated hg
>> > extension, but someone needs to have enough free time and passion to try and
>> > write it :-)
>>
>> Wouldn't an extension that does the copying be easier than resolving
>> the conflict?
>
> Sure, it would be. Like Nick said: if you are motivated enough to write
> the extension... :-)

We'll see.

From solipsis at pitrou.net  Fri May 24 21:54:02 2013
From: solipsis at pitrou.net (Antoine Pitrou)
Date: Fri, 24 May 2013 21:54:02 +0200
Subject: [python-committers] what's going on with Misc/NEWS?
In-Reply-To: <CAP1=2W5nAjHZNYnXk=Y+68fg1Zz=cbDY_dFnv9NZvh-YPzStwQ@mail.gmail.com>
References: <CAP1=2W55By0cjq2J0cxcMuQKoCQLc+ty0PKtY6Ud0h6UpMsAeQ@mail.gmail.com>
	<CADiSq7dezvi=ATp1mAS6h36A7f0FbpQb39k9ZvjinY4zVLSt5A@mail.gmail.com>
	<CAP1=2W5UpoZLugDRxAS1ZyzxvSiK4LQUq_EL2ktHAm6xoWhXrQ@mail.gmail.com>
	<63724bbaea84f6591bb36288355cd96f.squirrel@webmail.nerim.net>
	<CAP1=2W4rTF9+SZqotwprNug3=shWsB0iEEbqxNa3f5uVPxjNnA@mail.gmail.com>
	<1369420071.2559.3.camel@fsol>
	<CAP1=2W5nAjHZNYnXk=Y+68fg1Zz=cbDY_dFnv9NZvh-YPzStwQ@mail.gmail.com>
Message-ID: <1369425242.2559.4.camel@fsol>

Le vendredi 24 mai 2013 ? 15:26 -0400, Brett Cannon a ?crit :
> >> Either way the status quo makes me not want to fix small doc typos
> >> like a missing parenthesis since this is enough of a hassle to not
> >> make it worth it.
> >
> > Do you mean Mics/NEWS doc typos?
> 
> No I mean typos in the docs. For instance, I found a missing
> parenthesis in the docs for some module, but backporting it is enough
> of a pain that I don't want to bother.

I don't understand why it's painful to backport. Can you explain?



From tjreedy at udel.edu  Fri May 24 21:08:01 2013
From: tjreedy at udel.edu (Terry Reedy)
Date: Fri, 24 May 2013 15:08:01 -0400
Subject: [python-committers] what's going on with Misc/NEWS?
In-Reply-To: <CADiSq7dezvi=ATp1mAS6h36A7f0FbpQb39k9ZvjinY4zVLSt5A@mail.gmail.com>
References: <CAP1=2W55By0cjq2J0cxcMuQKoCQLc+ty0PKtY6Ud0h6UpMsAeQ@mail.gmail.com>
	<CADiSq7dezvi=ATp1mAS6h36A7f0FbpQb39k9ZvjinY4zVLSt5A@mail.gmail.com>
Message-ID: <519FBA91.6030303@udel.edu>

On 5/24/2013 9:00 AM, Nick Coghlan wrote:
> On Fri, May 24, 2013 at 10:24 PM, Brett Cannon <brett at python.org> wrote:
>> would be great. And maybe it's finally time to bite the bullet and
>> come up with some way to automatically generate Misc/NEWS from commit
>> messages.
> No, commit messages do not a NEWS file make.

They often do. Nearly all of my NEWS messages are copy and paste from 
the commit message. This is often true of other people's commits. 
Anyway, my  proposal, in response to Brett, is to make autocommit 
optional and possible partial bu only autocommitting the part of a 
commit message above a flag line like ***Library that identifies where 
to put the autocommit. This proposal does not conflict with separating 
the files.


>   The audiences are
> different (current and future developers vs interested end users), so
> it doesn't make sense to try to use the same content. Using commit
> messages also makes it annoyingly difficult to edit erroneous entries,
It is impossible to correct commit messages now. Any error not noticed 
before copy and paste already gets put in NEWS. Errors in NEWS could 
still be corrected. Auto copy and paste does not change anything except 
the hell of lower context conflict.

> as well as needing to come up with conventions to indicate commits
> which *shouldn't* get a log entry.
My proposed default is no autocommit. If you do not want it for your 
commits, continue as present.

> What *does* make sense is to use a directory structure (which version
Since the conflict problem is entirely within the sections that would be 
put into separate files, I do not see how that affects the conflict 
problem at all. This seems to me like an orthogonal proposal.

Here is an alternate proposal. Each branch has a NewsLog file. Each 
entry consists of
---
TAG
Entry



---
TAG is CORE, LIB, IDLE, TEST, or DOC. The three blank lines are part of 
the patch. Entries are put at the bottom of the file, so that the patch 
context is (should be) 3 blank lines above and <bottom of file> below. 
No conflict possible (unless differs subvert this by thinking the old 
blank lines are new and the new blank lines are old - maybe a commit 
hook could check and correct this).

When releases are tagged, NewsLog is emptied, the entries are sorted by 
tag and formatted
  ('- ' and '  ' prepended), subsection headers are added, and a 
corresponding section is added to NEWS.

> Of course, we've talked about doing something like this before, it's
> just never irritated anyone enough for them to sit down and *write*
> the associated NEWS file generator, or the code to split the existing
> NEWS file for the active branches :)
The problem irritated enough other people that the devguide contains the 
suggestion to insert news items into a random place in the current list. 
This only works when the section contains at least a few entries.

Having missed previous discussions, my impression has been that old 
timers are so used to the current mess and experienced dealing with it 
that it was useless for me to even say anything.  So if I do not care 
enough about an issue to suffer the commit pain, I leave it alone. 
Thanks Brett of saying something. However, I can only suggest as I have 
no idea how to implement a commit hook that would look at commit lines 
for a flag line to auto cut and commit. I do not even know if that is 
possible with hg.

---
Terry Jan Reedy


From rdmurray at bitdance.com  Fri May 24 22:18:41 2013
From: rdmurray at bitdance.com (R. David Murray)
Date: Fri, 24 May 2013 16:18:41 -0400
Subject: [python-committers] what's going on with Misc/NEWS?
In-Reply-To: <CAP1=2W5nAjHZNYnXk=Y+68fg1Zz=cbDY_dFnv9NZvh-YPzStwQ@mail.gmail.com>
References: <CAP1=2W55By0cjq2J0cxcMuQKoCQLc+ty0PKtY6Ud0h6UpMsAeQ@mail.gmail.com>
	<CADiSq7dezvi=ATp1mAS6h36A7f0FbpQb39k9ZvjinY4zVLSt5A@mail.gmail.com>
	<CAP1=2W5UpoZLugDRxAS1ZyzxvSiK4LQUq_EL2ktHAm6xoWhXrQ@mail.gmail.com>
	<63724bbaea84f6591bb36288355cd96f.squirrel@webmail.nerim.net>
	<CAP1=2W4rTF9+SZqotwprNug3=shWsB0iEEbqxNa3f5uVPxjNnA@mail.gmail.com>
	<1369420071.2559.3.camel@fsol>
	<CAP1=2W5nAjHZNYnXk=Y+68fg1Zz=cbDY_dFnv9NZvh-YPzStwQ@mail.gmail.com>
Message-ID: <20130524201841.BBC7D250BDB@webabinitio.net>

On Fri, 24 May 2013 15:26:29 -0400, Brett Cannon <brett at python.org> wrote:
> On Fri, May 24, 2013 at 2:27 PM, Antoine Pitrou <solipsis at pitrou.net> wrote:
> > Le vendredi 24 mai 2013 ?? 14:23 -0400, Brett Cannon a ??crit :
> >> > You'll have to copy stuff by hand, though, if you don't want to rely on the
> >> > merge machinery. So we have two possible file layouts:
> >> >
> >> > * (current) a single Misc/NEWS is merged from branch to branch. Pro: hg merge
> >> > copies the text for you. Con: hg merge sometimes screws up and you have to
> >> > clean up a large conflict.
> >>
> >> But hg won't let you simply revert;
> >
> > hg rev -r <branch name> Misc/NEWS
> 
> I'll add that to the devguide if it works for me next time.
 
I find that I also have to do:

    hg resolve -m Misc/NEWS

which I find to be a really obnoxious mis-feature of hg.

> > Do you mean Mics/NEWS doc typos?
> 
> No I mean typos in the docs. For instance, I found a missing
> parenthesis in the docs for some module, but backporting it is enough
> of a pain that I don't want to bother. The only reason I did this one
> for sys is because it clarified semantics.

You're adding a NEWS entry for a single character doc typo?  No wonder
you don't like making doc fixes :)

I only make news entries for doc changes when they are major or are
changes to the doc *system*.

--David

From brett at python.org  Fri May 24 22:22:09 2013
From: brett at python.org (Brett Cannon)
Date: Fri, 24 May 2013 16:22:09 -0400
Subject: [python-committers] what's going on with Misc/NEWS?
In-Reply-To: <1369425242.2559.4.camel@fsol>
References: <CAP1=2W55By0cjq2J0cxcMuQKoCQLc+ty0PKtY6Ud0h6UpMsAeQ@mail.gmail.com>
	<CADiSq7dezvi=ATp1mAS6h36A7f0FbpQb39k9ZvjinY4zVLSt5A@mail.gmail.com>
	<CAP1=2W5UpoZLugDRxAS1ZyzxvSiK4LQUq_EL2ktHAm6xoWhXrQ@mail.gmail.com>
	<63724bbaea84f6591bb36288355cd96f.squirrel@webmail.nerim.net>
	<CAP1=2W4rTF9+SZqotwprNug3=shWsB0iEEbqxNa3f5uVPxjNnA@mail.gmail.com>
	<1369420071.2559.3.camel@fsol>
	<CAP1=2W5nAjHZNYnXk=Y+68fg1Zz=cbDY_dFnv9NZvh-YPzStwQ@mail.gmail.com>
	<1369425242.2559.4.camel@fsol>
Message-ID: <CAP1=2W7xuv3hGxupG=sn-77MF3uCMpv=SkBaNjN2kOYEzz7pYA@mail.gmail.com>

On Fri, May 24, 2013 at 3:54 PM, Antoine Pitrou <solipsis at pitrou.net> wrote:
> Le vendredi 24 mai 2013 ? 15:26 -0400, Brett Cannon a ?crit :
>> >> Either way the status quo makes me not want to fix small doc typos
>> >> like a missing parenthesis since this is enough of a hassle to not
>> >> make it worth it.
>> >
>> > Do you mean Mics/NEWS doc typos?
>>
>> No I mean typos in the docs. For instance, I found a missing
>> parenthesis in the docs for some module, but backporting it is enough
>> of a pain that I don't want to bother.
>
> I don't understand why it's painful to backport. Can you explain?

If I make a very minor fix to the docs I have to:

# In a 3.3 checkout
Fix docs
Compile docs
Add Misc/NEWS entry
hg ci -m "repeat what I just said in Misc/NEWS"
hg push
cd ../default
hg merge 3.3
Fix/revert Misc/NEWS (at least)
Compile docs (if fix is needed)
hg ci
hg push

If you look at that process, it's a lot of VCS stuff to keep history,
which I understand. But there are at least two steps that directly
involve Misc/NEWS which could be automated/skipped if we used the
commit message somehow. And the fixing of Misc/NEWS I irrationally
hate since it happens every single time and could go away somehow if
we chose to make it go away even if people continue to hate on commit
messages as a solution.

From brett at python.org  Fri May 24 22:23:31 2013
From: brett at python.org (Brett Cannon)
Date: Fri, 24 May 2013 16:23:31 -0400
Subject: [python-committers] what's going on with Misc/NEWS?
In-Reply-To: <20130524201841.BBC7D250BDB@webabinitio.net>
References: <CAP1=2W55By0cjq2J0cxcMuQKoCQLc+ty0PKtY6Ud0h6UpMsAeQ@mail.gmail.com>
	<CADiSq7dezvi=ATp1mAS6h36A7f0FbpQb39k9ZvjinY4zVLSt5A@mail.gmail.com>
	<CAP1=2W5UpoZLugDRxAS1ZyzxvSiK4LQUq_EL2ktHAm6xoWhXrQ@mail.gmail.com>
	<63724bbaea84f6591bb36288355cd96f.squirrel@webmail.nerim.net>
	<CAP1=2W4rTF9+SZqotwprNug3=shWsB0iEEbqxNa3f5uVPxjNnA@mail.gmail.com>
	<1369420071.2559.3.camel@fsol>
	<CAP1=2W5nAjHZNYnXk=Y+68fg1Zz=cbDY_dFnv9NZvh-YPzStwQ@mail.gmail.com>
	<20130524201841.BBC7D250BDB@webabinitio.net>
Message-ID: <CAP1=2W5ShR5nNyhWC0Kt9Kaf0Q5Fw8=dYqGbmSHz_zMwNC2siQ@mail.gmail.com>

On Fri, May 24, 2013 at 4:18 PM, R. David Murray <rdmurray at bitdance.com> wrote:
> On Fri, 24 May 2013 15:26:29 -0400, Brett Cannon <brett at python.org> wrote:
>> On Fri, May 24, 2013 at 2:27 PM, Antoine Pitrou <solipsis at pitrou.net> wrote:
>> > Le vendredi 24 mai 2013 ? 14:23 -0400, Brett Cannon a ?crit :
>> >> > You'll have to copy stuff by hand, though, if you don't want to rely on the
>> >> > merge machinery. So we have two possible file layouts:
>> >> >
>> >> > * (current) a single Misc/NEWS is merged from branch to branch. Pro: hg merge
>> >> > copies the text for you. Con: hg merge sometimes screws up and you have to
>> >> > clean up a large conflict.
>> >>
>> >> But hg won't let you simply revert;
>> >
>> > hg rev -r <branch name> Misc/NEWS
>>
>> I'll add that to the devguide if it works for me next time.
>
> I find that I also have to do:
>
>     hg resolve -m Misc/NEWS
>
> which I find to be a really obnoxious mis-feature of hg.
>
>> > Do you mean Mics/NEWS doc typos?
>>
>> No I mean typos in the docs. For instance, I found a missing
>> parenthesis in the docs for some module, but backporting it is enough
>> of a pain that I don't want to bother. The only reason I did this one
>> for sys is because it clarified semantics.
>
> You're adding a NEWS entry for a single character doc typo?  No wonder
> you don't like making doc fixes :)
>
> I only make news entries for doc changes when they are major or are
> changes to the doc *system*.

It's an extreme example, but for instance I added an entry for this
sys.modules change where I just added a clarifying sentence. Probably
not needed but wanted to make sure that people got the message they
shouldn't replace sys.modules.

From tjreedy at udel.edu  Fri May 24 22:25:33 2013
From: tjreedy at udel.edu (Terry Reedy)
Date: Fri, 24 May 2013 16:25:33 -0400
Subject: [python-committers] what's going on with Misc/NEWS?
In-Reply-To: <CAP1=2W55By0cjq2J0cxcMuQKoCQLc+ty0PKtY6Ud0h6UpMsAeQ@mail.gmail.com>
References: <CAP1=2W55By0cjq2J0cxcMuQKoCQLc+ty0PKtY6Ud0h6UpMsAeQ@mail.gmail.com>
Message-ID: <519FCCBD.2070501@udel.edu>

Trying again, as my response 2 hours ago never showed up
On 5/24/2013 8:24 AM, Brett Cannon wrote:

> I was trying to do a simple merge of a doc change between 3.3 and
> default and the usual Misc/NEWS conflict came up.
I have had things like this happen and after pain iwth kdiff3 just 
edited the default version
>   But when I looked at
> the diff it was massive! Turns out that Misc/NEWS in default goes from
> 3.3.1rc1 to 3.4.0a1
> (http://hg.python.org/cpython/file/24ffb0148729/Misc/NEWS) while
> Misc/NEWS in 3.3 goes properly through all versions between 3.3.1rc1
> to 3.3.3rc1 (http://hg.python.org/cpython/file/3c4a5dc29417/Misc/NEWS).
I do not know if I had the same cause. Never looked that far.
> I have to get to work so I don't have time to fix this, but if someone
> does have the time to unwind this mix-up that has accumulated that
> would be great. And maybe it's finally time to bite the bullet and
> come up with some way to automatically generate Misc/NEWS from commit
> messages.

+100 on ending or ameliorating NEWS conflict hell. I do fewer commits 
because of it.

Proposal: If the commit message has a line like
***Library
then everything *above that line is put into NEWS. This makes automatic 
generation optional and optionally allows additional non-NEWS extras.

The immediate problem is conflict with the lower context, the three 
lines below
Library
---------
<blank>

which is often different between 3.3 and 3.4 and possibly changed anyway 
since the patch
was made. Can hg be told to ignore the lower context and just match the 
3 upper context lines for this file?

The larger problem is that our workplace design subverts the premise of 
non-checkout repositories, that people usually work on different areas 
of files, making conflicts rare. Our current design makes conflict normal.

-- 
Terry Jan Reedy

From benjamin at python.org  Fri May 24 22:26:18 2013
From: benjamin at python.org (Benjamin Peterson)
Date: Fri, 24 May 2013 13:26:18 -0700
Subject: [python-committers] what's going on with Misc/NEWS?
In-Reply-To: <CAP1=2W5ShR5nNyhWC0Kt9Kaf0Q5Fw8=dYqGbmSHz_zMwNC2siQ@mail.gmail.com>
References: <CAP1=2W55By0cjq2J0cxcMuQKoCQLc+ty0PKtY6Ud0h6UpMsAeQ@mail.gmail.com>
	<CADiSq7dezvi=ATp1mAS6h36A7f0FbpQb39k9ZvjinY4zVLSt5A@mail.gmail.com>
	<CAP1=2W5UpoZLugDRxAS1ZyzxvSiK4LQUq_EL2ktHAm6xoWhXrQ@mail.gmail.com>
	<63724bbaea84f6591bb36288355cd96f.squirrel@webmail.nerim.net>
	<CAP1=2W4rTF9+SZqotwprNug3=shWsB0iEEbqxNa3f5uVPxjNnA@mail.gmail.com>
	<1369420071.2559.3.camel@fsol>
	<CAP1=2W5nAjHZNYnXk=Y+68fg1Zz=cbDY_dFnv9NZvh-YPzStwQ@mail.gmail.com>
	<20130524201841.BBC7D250BDB@webabinitio.net>
	<CAP1=2W5ShR5nNyhWC0Kt9Kaf0Q5Fw8=dYqGbmSHz_zMwNC2siQ@mail.gmail.com>
Message-ID: <CAPZV6o92xfsiH_VG3iVFhFXaDp4jrYQMRpJii+Z83r0yFKU3sQ@mail.gmail.com>

2013/5/24 Brett Cannon <brett at python.org>:
> It's an extreme example, but for instance I added an entry for this
> sys.modules change where I just added a clarifying sentence. Probably
> not needed but wanted to make sure that people got the message they
> shouldn't replace sys.modules.

Does anybody actually ready Misc/NEWS?


--
Regards,
Benjamin

From tjreedy at udel.edu  Fri May 24 22:29:04 2013
From: tjreedy at udel.edu (Terry Reedy)
Date: Fri, 24 May 2013 16:29:04 -0400
Subject: [python-committers] what's going on with Misc/NEWS?
In-Reply-To: <CADiSq7dezvi=ATp1mAS6h36A7f0FbpQb39k9ZvjinY4zVLSt5A@mail.gmail.com>
References: <CAP1=2W55By0cjq2J0cxcMuQKoCQLc+ty0PKtY6Ud0h6UpMsAeQ@mail.gmail.com>
	<CADiSq7dezvi=ATp1mAS6h36A7f0FbpQb39k9ZvjinY4zVLSt5A@mail.gmail.com>
Message-ID: <519FCD90.9050302@udel.edu>

Another replay that did not show up on list.

On 5/24/2013 9:00 AM, Nick Coghlan wrote:
> On Fri, May 24, 2013 at 10:24 PM, Brett Cannon <brett at python.org> wrote:
>> would be great. And maybe it's finally time to bite the bullet and
>> come up with some way to automatically generate Misc/NEWS from commit
>> messages.
> No, commit messages do not a NEWS file make.

They often do. Nearly all of my NEWS messages are copy and paste from 
the commit message. This is often true of other people's commits. 
Anyway, my  proposal, in response to Brett, is to make autocommit 
optional and possible partial bu only autocommitting the part of a 
commit message above a flag line like ***Library that identifies where 
to put the autocommit. This proposal does not conflict with separating 
the files.


>   The audiences are
> different (current and future developers vs interested end users), so
> it doesn't make sense to try to use the same content. Using commit
> messages also makes it annoyingly difficult to edit erroneous entries,
It is impossible to correct commit messages now. Any error not noticed 
before copy and paste already gets put in NEWS. Errors in NEWS could 
still be corrected. Auto copy and paste does not change anything except 
the hell of lower context conflict.

> as well as needing to come up with conventions to indicate commits
> which *shouldn't* get a log entry.
My proposed default is no autocommit. If you do not want it for your 
commits, continue as present.

> What *does* make sense is to use a directory structure (which version
Since the conflict problem is entirely within the sections that would be 
put into separate files, I do not see how that affects the conflict 
problem at all. This seems to me like an orthogonal proposal.

Here is an alternate proposal. Each branch has a NewsLog file. Each 
entry consists of
---
TAG
Entry



---
TAG is CORE, LIB, IDLE, TEST, or DOC. The three blank lines are part of 
the patch. Entries are put at the bottom of the file, so that the patch 
context is (should be) 3 blank lines above and <bottom of file> below. 
No conflict possible (unless differs subvert this by thinking the old 
blank lines are new and the new blank lines are old - maybe a commit 
hook could check and correct this).

When releases are tagged, NewsLog is emptied, the entries are sorted by 
tag and formatted
  ('- ' and '  ' prepended), subsection headers are added, and a 
corresponding section is added to NEWS.

> Of course, we've talked about doing something like this before, it's
> just never irritated anyone enough for them to sit down and *write*
> the associated NEWS file generator, or the code to split the existing
> NEWS file for the active branches
The problem irritated enough other people that the devguide contains the 
suggestion to insert news items into a random place in the current list. 
This only works when the section contains at least a few entries.

Having missed previous discussions, my impression has been that old 
timers are so used to the current mess and experienced dealing with it 
that it was useless for me to even say anything.  So if I do not care 
enough about an issue to suffer the commit pain, I leave it alone. 
Thanks Brett of saying something. However, I can only suggest as I have 
no idea how to implement a commit hook that would look at commit lines 
for a flag line to auto cut and commit. I do not even know if that is 
possible with hg.

---
Terry Jan Reedy
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-committers/attachments/20130524/85ff1993/attachment.html>

From solipsis at pitrou.net  Fri May 24 22:54:24 2013
From: solipsis at pitrou.net (Antoine Pitrou)
Date: Fri, 24 May 2013 22:54:24 +0200
Subject: [python-committers] what's going on with Misc/NEWS?
In-Reply-To: <CAP1=2W7xuv3hGxupG=sn-77MF3uCMpv=SkBaNjN2kOYEzz7pYA@mail.gmail.com>
References: <CAP1=2W55By0cjq2J0cxcMuQKoCQLc+ty0PKtY6Ud0h6UpMsAeQ@mail.gmail.com>
	<CADiSq7dezvi=ATp1mAS6h36A7f0FbpQb39k9ZvjinY4zVLSt5A@mail.gmail.com>
	<CAP1=2W5UpoZLugDRxAS1ZyzxvSiK4LQUq_EL2ktHAm6xoWhXrQ@mail.gmail.com>
	<63724bbaea84f6591bb36288355cd96f.squirrel@webmail.nerim.net>
	<CAP1=2W4rTF9+SZqotwprNug3=shWsB0iEEbqxNa3f5uVPxjNnA@mail.gmail.com>
	<1369420071.2559.3.camel@fsol>
	<CAP1=2W5nAjHZNYnXk=Y+68fg1Zz=cbDY_dFnv9NZvh-YPzStwQ@mail.gmail.com>
	<1369425242.2559.4.camel@fsol>
	<CAP1=2W7xuv3hGxupG=sn-77MF3uCMpv=SkBaNjN2kOYEzz7pYA@mail.gmail.com>
Message-ID: <1369428864.2559.6.camel@fsol>

Le vendredi 24 mai 2013 ? 16:22 -0400, Brett Cannon a ?crit :
> >
> > I don't understand why it's painful to backport. Can you explain?
> 
> If I make a very minor fix to the docs I have to:
> 
> # In a 3.3 checkout
> Fix docs
> Compile docs
> Add Misc/NEWS entry
> hg ci -m "repeat what I just said in Misc/NEWS"
> hg push
> cd ../default
> hg merge 3.3
> Fix/revert Misc/NEWS (at least)
> Compile docs (if fix is needed)
> hg ci
> hg push

I honestly don't understand why you would mention doc fixes (even major
ones) in Misc/NEWS. It's not a useful piece of information to have
there. People want to know about bug fixes because they are affected by
bugs, but doc fixes??

Regards

Antoine.



From greg at krypto.org  Fri May 24 23:11:31 2013
From: greg at krypto.org (Gregory P. Smith)
Date: Fri, 24 May 2013 15:11:31 -0600
Subject: [python-committers] what's going on with Misc/NEWS?
In-Reply-To: <CAPZV6o92xfsiH_VG3iVFhFXaDp4jrYQMRpJii+Z83r0yFKU3sQ@mail.gmail.com>
References: <CAP1=2W55By0cjq2J0cxcMuQKoCQLc+ty0PKtY6Ud0h6UpMsAeQ@mail.gmail.com>
	<CADiSq7dezvi=ATp1mAS6h36A7f0FbpQb39k9ZvjinY4zVLSt5A@mail.gmail.com>
	<CAP1=2W5UpoZLugDRxAS1ZyzxvSiK4LQUq_EL2ktHAm6xoWhXrQ@mail.gmail.com>
	<63724bbaea84f6591bb36288355cd96f.squirrel@webmail.nerim.net>
	<CAP1=2W4rTF9+SZqotwprNug3=shWsB0iEEbqxNa3f5uVPxjNnA@mail.gmail.com>
	<1369420071.2559.3.camel@fsol>
	<CAP1=2W5nAjHZNYnXk=Y+68fg1Zz=cbDY_dFnv9NZvh-YPzStwQ@mail.gmail.com>
	<20130524201841.BBC7D250BDB@webabinitio.net>
	<CAP1=2W5ShR5nNyhWC0Kt9Kaf0Q5Fw8=dYqGbmSHz_zMwNC2siQ@mail.gmail.com>
	<CAPZV6o92xfsiH_VG3iVFhFXaDp4jrYQMRpJii+Z83r0yFKU3sQ@mail.gmail.com>
Message-ID: <CAGE7PN+=TYeof3nuFhuGOw_gg4eBgeZ9ADt5aXCE1XGSrh9uAQ@mail.gmail.com>

On May 24, 2013 2:26 PM, "Benjamin Peterson" <benjamin at python.org> wrote:
>
> 2013/5/24 Brett Cannon <brett at python.org>:
> > It's an extreme example, but for instance I added an entry for this
> > sys.modules change where I just added a clarifying sentence. Probably
> > not needed but wanted to make sure that people got the message they
> > shouldn't replace sys.modules.
>
> Does anybody actually read Misc/NEWS?
>

Yes. It's the best way to get a summary of what changed in a release with
more little details than any higher level what's new docs and without
looking at diffs.

>
> --
> Regards,
> Benjamin
> _______________________________________________
> python-committers mailing list
> python-committers at python.org
> http://mail.python.org/mailman/listinfo/python-committers
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-committers/attachments/20130524/c3d152f9/attachment.html>

From greg at krypto.org  Fri May 24 23:16:24 2013
From: greg at krypto.org (Gregory P. Smith)
Date: Fri, 24 May 2013 15:16:24 -0600
Subject: [python-committers] what's going on with Misc/NEWS?
In-Reply-To: <1369428864.2559.6.camel@fsol>
References: <CAP1=2W55By0cjq2J0cxcMuQKoCQLc+ty0PKtY6Ud0h6UpMsAeQ@mail.gmail.com>
	<CADiSq7dezvi=ATp1mAS6h36A7f0FbpQb39k9ZvjinY4zVLSt5A@mail.gmail.com>
	<CAP1=2W5UpoZLugDRxAS1ZyzxvSiK4LQUq_EL2ktHAm6xoWhXrQ@mail.gmail.com>
	<63724bbaea84f6591bb36288355cd96f.squirrel@webmail.nerim.net>
	<CAP1=2W4rTF9+SZqotwprNug3=shWsB0iEEbqxNa3f5uVPxjNnA@mail.gmail.com>
	<1369420071.2559.3.camel@fsol>
	<CAP1=2W5nAjHZNYnXk=Y+68fg1Zz=cbDY_dFnv9NZvh-YPzStwQ@mail.gmail.com>
	<1369425242.2559.4.camel@fsol>
	<CAP1=2W7xuv3hGxupG=sn-77MF3uCMpv=SkBaNjN2kOYEzz7pYA@mail.gmail.com>
	<1369428864.2559.6.camel@fsol>
Message-ID: <CAGE7PNKZD=a2sLYa0RweRk7-t9k=3T21zk4fkihHD9xX05N75w@mail.gmail.com>

On May 24, 2013 2:55 PM, "Antoine Pitrou" <solipsis at pitrou.net> wrote:
>
> Le vendredi 24 mai 2013 ? 16:22 -0400, Brett Cannon a ?crit :
> > >
> > > I don't understand why it's painful to backport. Can you explain?
> >
> > If I make a very minor fix to the docs I have to:
> >
> > # In a 3.3 checkout
> > Fix docs
> > Compile docs
> > Add Misc/NEWS entry
> > hg ci -m "repeat what I just said in Misc/NEWS"
> > hg push
> > cd ../default
> > hg merge 3.3
> > Fix/revert Misc/NEWS (at least)
> > Compile docs (if fix is needed)
> > hg ci
> > hg push
>
> I honestly don't understand why you would mention doc fixes (even major
> ones) in Misc/NEWS. It's not a useful piece of information to have
> there. People want to know about bug fixes because they are affected by
> bugs, but doc fixes??

I think you misunderstood what he meant. Misc/NEWS is documentation. I
believe he meant he won't fix typos in NEWS due to the make pain involved.

I'm the same way. I want nothing to do with news when making my changes
because it ALWAYS gets in the way for any change not being done on
head/default/tip only. If anything I prefer to leave news entries out of
the commit they are related to to avoid news merges going wrong from
messing up the real change. Hopefully I remember to write a news entry for
it after the fact.

>
> Regards
>
> Antoine.
>
>
> _______________________________________________
> python-committers mailing list
> python-committers at python.org
> http://mail.python.org/mailman/listinfo/python-committers
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-committers/attachments/20130524/2be2450d/attachment-0001.html>

From rdmurray at bitdance.com  Sat May 25 05:00:00 2013
From: rdmurray at bitdance.com (R. David Murray)
Date: Fri, 24 May 2013 23:00:00 -0400
Subject: [python-committers] what's going on with Misc/NEWS?
In-Reply-To: <CAGE7PNKZD=a2sLYa0RweRk7-t9k=3T21zk4fkihHD9xX05N75w@mail.gmail.com>
References: <CAP1=2W55By0cjq2J0cxcMuQKoCQLc+ty0PKtY6Ud0h6UpMsAeQ@mail.gmail.com>
	<CADiSq7dezvi=ATp1mAS6h36A7f0FbpQb39k9ZvjinY4zVLSt5A@mail.gmail.com>
	<CAP1=2W5UpoZLugDRxAS1ZyzxvSiK4LQUq_EL2ktHAm6xoWhXrQ@mail.gmail.com>
	<63724bbaea84f6591bb36288355cd96f.squirrel@webmail.nerim.net>
	<CAP1=2W4rTF9+SZqotwprNug3=shWsB0iEEbqxNa3f5uVPxjNnA@mail.gmail.com>
	<1369420071.2559.3.camel@fsol>
	<CAP1=2W5nAjHZNYnXk=Y+68fg1Zz=cbDY_dFnv9NZvh-YPzStwQ@mail.gmail.com>
	<1369425242.2559.4.camel@fsol>
	<CAP1=2W7xuv3hGxupG=sn-77MF3uCMpv=SkBaNjN2kOYEzz7pYA@mail.gmail.com>
	<1369428864.2559.6.camel@fsol>
	<CAGE7PNKZD=a2sLYa0RweRk7-t9k=3T21zk4fkihHD9xX05N75w@mail.gmail.com>
Message-ID: <20130525030001.9D691250BC4@webabinitio.net>

On Fri, 24 May 2013 15:16:24 -0600, "Gregory P. Smith" <greg at krypto.org> wrote:
> On May 24, 2013 2:55 PM, "Antoine Pitrou" <solipsis at pitrou.net> wrote:
> >
> > Le vendredi 24 mai 2013 ?? 16:22 -0400, Brett Cannon a ??crit :
> > > >
> > > > I don't understand why it's painful to backport. Can you explain?
> > >
> > > If I make a very minor fix to the docs I have to:
> > >
> > > # In a 3.3 checkout
> > > Fix docs
> > > Compile docs
> > > Add Misc/NEWS entry
> > > hg ci -m "repeat what I just said in Misc/NEWS"
> > > hg push
> > > cd ../default
> > > hg merge 3.3
> > > Fix/revert Misc/NEWS (at least)
> > > Compile docs (if fix is needed)
> > > hg ci
> > > hg push
> >
> > I honestly don't understand why you would mention doc fixes (even major
> > ones) in Misc/NEWS. It's not a useful piece of information to have
> > there. People want to know about bug fixes because they are affected by
> > bugs, but doc fixes??
> 
> I think you misunderstood what he meant. Misc/NEWS is documentation. I
> believe he meant he won't fix typos in NEWS due to the make pain involved.

No, he really meant he created a news entry for a doc change.  For a
reasonable reason, in the example he gave :)

But you certainly don't need a news entry for typos, or most other
doc changes, IMO.

> I'm the same way. I want nothing to do with news when making my changes
> because it ALWAYS gets in the way for any change not being done on
> head/default/tip only. If anything I prefer to leave news entries out of
> the commit they are related to to avoid news merges going wrong from
> messing up the real change. Hopefully I remember to write a news entry for
> it after the fact.

In the subversion days almost every merge I did had a NEWS conflict.
With hg, I only get a merge conflict if the most recent change to NEWS
is a 3.3-only entry.  So, maybe half the time.  (I suppose if people
are really sticking entries in randomly I might start seeing more
conflicts...)

I have no objection to the process being improved if someone is willing
to do the scripting to improve it.  I personally would prefer not to
simply have the files have different names, meaning I'd have to copy the
news entry all the time instead of half the time.  But my objection is
only about -0.25, so if more people prefer making the file names different
in the absence of a better scripted solution, I'll live with it :)
I just hope we don't start losing NEWS entries as as result.

Oh, and my news entries are almost never the same as my commit one-lines,
partly because I keep the commit line to *one* line, whereas the NEWS
entry is typically two to three.  Keeping the first commit line to one
line makes reading the log easier, IMO; but I suppose since not everybody
does that it's really just a quirk :)

But even without that the messages would different.  As someone else
mentioned, I feel that the audiences are different...and in the commit
message I assume that you are seeing the list of changed files as well,
to give you context for the commit message that isn't present in the
NEWS entry.

--David

From ncoghlan at gmail.com  Sat May 25 05:07:49 2013
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Sat, 25 May 2013 13:07:49 +1000
Subject: [python-committers] what's going on with Misc/NEWS?
In-Reply-To: <20130525030001.9D691250BC4@webabinitio.net>
References: <CAP1=2W55By0cjq2J0cxcMuQKoCQLc+ty0PKtY6Ud0h6UpMsAeQ@mail.gmail.com>
	<CADiSq7dezvi=ATp1mAS6h36A7f0FbpQb39k9ZvjinY4zVLSt5A@mail.gmail.com>
	<CAP1=2W5UpoZLugDRxAS1ZyzxvSiK4LQUq_EL2ktHAm6xoWhXrQ@mail.gmail.com>
	<63724bbaea84f6591bb36288355cd96f.squirrel@webmail.nerim.net>
	<CAP1=2W4rTF9+SZqotwprNug3=shWsB0iEEbqxNa3f5uVPxjNnA@mail.gmail.com>
	<1369420071.2559.3.camel@fsol>
	<CAP1=2W5nAjHZNYnXk=Y+68fg1Zz=cbDY_dFnv9NZvh-YPzStwQ@mail.gmail.com>
	<1369425242.2559.4.camel@fsol>
	<CAP1=2W7xuv3hGxupG=sn-77MF3uCMpv=SkBaNjN2kOYEzz7pYA@mail.gmail.com>
	<1369428864.2559.6.camel@fsol>
	<CAGE7PNKZD=a2sLYa0RweRk7-t9k=3T21zk4fkihHD9xX05N75w@mail.gmail.com>
	<20130525030001.9D691250BC4@webabinitio.net>
Message-ID: <CADiSq7cOLJEaLOKLNzEKwMMVhSBBj6B4Qfx9CErUP8K29mtgsg@mail.gmail.com>

On 25 May 2013 13:05, "R. David Murray" <rdmurray at bitdance.com> wrote:
>
> On Fri, 24 May 2013 15:16:24 -0600, "Gregory P. Smith" <greg at krypto.org>
wrote:
> > On May 24, 2013 2:55 PM, "Antoine Pitrou" <solipsis at pitrou.net> wrote:
> > >
> > > Le vendredi 24 mai 2013 ? 16:22 -0400, Brett Cannon a ?crit :
> > > > >
> > > > > I don't understand why it's painful to backport. Can you explain?
> > > >
> > > > If I make a very minor fix to the docs I have to:
> > > >
> > > > # In a 3.3 checkout
> > > > Fix docs
> > > > Compile docs
> > > > Add Misc/NEWS entry
> > > > hg ci -m "repeat what I just said in Misc/NEWS"
> > > > hg push
> > > > cd ../default
> > > > hg merge 3.3
> > > > Fix/revert Misc/NEWS (at least)
> > > > Compile docs (if fix is needed)
> > > > hg ci
> > > > hg push
> > >
> > > I honestly don't understand why you would mention doc fixes (even
major
> > > ones) in Misc/NEWS. It's not a useful piece of information to have
> > > there. People want to know about bug fixes because they are affected
by
> > > bugs, but doc fixes??
> >
> > I think you misunderstood what he meant. Misc/NEWS is documentation. I
> > believe he meant he won't fix typos in NEWS due to the make pain
involved.
>
> No, he really meant he created a news entry for a doc change.  For a
> reasonable reason, in the example he gave :)
>
> But you certainly don't need a news entry for typos, or most other
> doc changes, IMO.
>
> > I'm the same way. I want nothing to do with news when making my changes
> > because it ALWAYS gets in the way for any change not being done on
> > head/default/tip only. If anything I prefer to leave news entries out of
> > the commit they are related to to avoid news merges going wrong from
> > messing up the real change. Hopefully I remember to write a news entry
for
> > it after the fact.
>
> In the subversion days almost every merge I did had a NEWS conflict.
> With hg, I only get a merge conflict if the most recent change to NEWS
> is a 3.3-only entry.  So, maybe half the time.  (I suppose if people
> are really sticking entries in randomly I might start seeing more
> conflicts...)
>
> I have no objection to the process being improved if someone is willing
> to do the scripting to improve it.  I personally would prefer not to
> simply have the files have different names, meaning I'd have to copy the
> news entry all the time instead of half the time.  But my objection is
> only about -0.25, so if more people prefer making the file names different
> in the absence of a better scripted solution, I'll live with it :)
> I just hope we don't start losing NEWS entries as as result.
>
> Oh, and my news entries are almost never the same as my commit one-lines,
> partly because I keep the commit line to *one* line, whereas the NEWS
> entry is typically two to three.  Keeping the first commit line to one
> line makes reading the log easier, IMO; but I suppose since not everybody
> does that it's really just a quirk :)
>
> But even without that the messages would different.  As someone else
> mentioned, I feel that the audiences are different...and in the commit
> message I assume that you are seeing the list of changed files as well,
> to give you context for the commit message that isn't present in the
> NEWS entry.

Yep, that's my view of commit vs NEWS as well.

Cheers,
Nick.

>
> --David
>
> _______________________________________________
> python-committers mailing list
> python-committers at python.org
> http://mail.python.org/mailman/listinfo/python-committers
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-committers/attachments/20130525/9e98395a/attachment.html>

From raymond.hettinger at gmail.com  Sat May 25 05:46:55 2013
From: raymond.hettinger at gmail.com (Raymond Hettinger)
Date: Fri, 24 May 2013 20:46:55 -0700
Subject: [python-committers] what's going on with Misc/NEWS?
In-Reply-To: <CAP1=2W5UpoZLugDRxAS1ZyzxvSiK4LQUq_EL2ktHAm6xoWhXrQ@mail.gmail.com>
References: <CAP1=2W55By0cjq2J0cxcMuQKoCQLc+ty0PKtY6Ud0h6UpMsAeQ@mail.gmail.com>
	<CADiSq7dezvi=ATp1mAS6h36A7f0FbpQb39k9ZvjinY4zVLSt5A@mail.gmail.com>
	<CAP1=2W5UpoZLugDRxAS1ZyzxvSiK4LQUq_EL2ktHAm6xoWhXrQ@mail.gmail.com>
Message-ID: <51CA58D1-1B7C-4397-967F-B4C87330D638@gmail.com>


On May 24, 2013, at 7:09 AM, Brett Cannon <brett at python.org> wrote:

> I think that's overly complicated. I don't see why we need anything
> more than simply NEWS/3.4, NEWS/3.3, etc. and just split the files per
> feature release since that's the interest (and merge) boundary.

+1 from me.  This is a straight-forward solution to the merge problem
and it recognizes that users don't really need to look across merge
boundaries.


Raymond
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-committers/attachments/20130524/807ae727/attachment.html>

From ericsnowcurrently at gmail.com  Sat May 25 06:01:16 2013
From: ericsnowcurrently at gmail.com (Eric Snow)
Date: Fri, 24 May 2013 22:01:16 -0600
Subject: [python-committers] what's going on with Misc/NEWS?
In-Reply-To: <51CA58D1-1B7C-4397-967F-B4C87330D638@gmail.com>
References: <CAP1=2W55By0cjq2J0cxcMuQKoCQLc+ty0PKtY6Ud0h6UpMsAeQ@mail.gmail.com>
	<CADiSq7dezvi=ATp1mAS6h36A7f0FbpQb39k9ZvjinY4zVLSt5A@mail.gmail.com>
	<CAP1=2W5UpoZLugDRxAS1ZyzxvSiK4LQUq_EL2ktHAm6xoWhXrQ@mail.gmail.com>
	<51CA58D1-1B7C-4397-967F-B4C87330D638@gmail.com>
Message-ID: <CALFfu7Dk9i9AXqMj8eXYPCcyOPaZtzJcddbrNqbRvjj3xPeF2w@mail.gmail.com>

On Fri, May 24, 2013 at 9:46 PM, Raymond Hettinger
<raymond.hettinger at gmail.com> wrote:
> and it recognizes that users don't really need to look across merge
> boundaries.

This is tricky though for any patch that is forward-ported to a
release branch (a la 3.2->3.3).  How can you tell from MISC/News in
which release (e.g. 3.3.0 or 3.3.1) of that branch the bug was fixed?
The entry would only show up in MISC/News for the previous release
(e.g. 3.2.3).

Granted, this would impact much fewer patches than our current pain point does.

-eric

From ncoghlan at gmail.com  Sat May 25 10:40:03 2013
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Sat, 25 May 2013 18:40:03 +1000
Subject: [python-committers] what's going on with Misc/NEWS?
In-Reply-To: <CALFfu7Dk9i9AXqMj8eXYPCcyOPaZtzJcddbrNqbRvjj3xPeF2w@mail.gmail.com>
References: <CAP1=2W55By0cjq2J0cxcMuQKoCQLc+ty0PKtY6Ud0h6UpMsAeQ@mail.gmail.com>
	<CADiSq7dezvi=ATp1mAS6h36A7f0FbpQb39k9ZvjinY4zVLSt5A@mail.gmail.com>
	<CAP1=2W5UpoZLugDRxAS1ZyzxvSiK4LQUq_EL2ktHAm6xoWhXrQ@mail.gmail.com>
	<51CA58D1-1B7C-4397-967F-B4C87330D638@gmail.com>
	<CALFfu7Dk9i9AXqMj8eXYPCcyOPaZtzJcddbrNqbRvjj3xPeF2w@mail.gmail.com>
Message-ID: <CADiSq7dzBtiu_foR2+oFeBZrVwCgNtu6VrZQ_nkYb11b+NFkyg@mail.gmail.com>

On Sat, May 25, 2013 at 2:01 PM, Eric Snow <ericsnowcurrently at gmail.com> wrote:
> On Fri, May 24, 2013 at 9:46 PM, Raymond Hettinger
> <raymond.hettinger at gmail.com> wrote:
>> and it recognizes that users don't really need to look across merge
>> boundaries.
>
> This is tricky though for any patch that is forward-ported to a
> release branch (a la 3.2->3.3).  How can you tell from MISC/News in
> which release (e.g. 3.3.0 or 3.3.1) of that branch the bug was fixed?
> The entry would only show up in MISC/News for the previous release
> (e.g. 3.2.3).
>
> Granted, this would impact much fewer patches than our current pain point does.

Let's take a step back for a moment and define the workflows we want to handle.

1. Feature development

- simplest case
- just edit Misc/NEWS on default

2. Normal 3.x only bug fix

- second simplest case
- exit Misc/NEWS on 3.3
- merge to default
- frequently conflict (due to entries for new features and different
release headers)
....

OK, I'm going to stop enumerating the cases there, because it already
suggests to me that splitting the *whole* NEWS file entirely by
version is the wrong thing to do. Instead, we really only need to
split the handling for NEWS items that haven't been released yet.

To avoid needing to copy info from other branches between files when
doing a merge, we could instead set up the following:

1. Add a new directory called NEWS.next
2. New NEWS entries go in version specific files in that directory
3. When a new release is made, ALL entries in NEWS.next are added to
the top of the main NEWS file for the relevant (a script to help with
the merging would be a good idea) and the contents of NEWS.next are
cleared.

So, suppose we're about to release 3.4.0a1. In the meantime, we have
accumulated bug fixes for 3.3 and new features and bug fixes that
couldn't be backported for 3.4. (The scheme could be extended to
security branches too, but I'm assuming for the moment those will be
handled via selective backporting rather than the normal forward
porting path)

The 3.3 branch layout would look like this:

    NEWS.next/
        3.3.txt  # Categorised changes
    NEWS  # Existing partial entry for 3.3.x

The default branch layout would look like this:

    NEWS.next/
        3.3.txt  # Forward ported categorised changes
        3.4.txt  # Categorised changes
   NEWS  # Existing partial entry for 3.4.0a1

Any changes that were specific to 3.3 would be listed in
NEWS.next/3.3.txt on that branch, but not on the default branch (since
the associated null-merge would have skipped adding them)

Now, we go to create 3.4.0a1. This will involve transferring *all* the
NEWS.next entries on default into the main NEWS file and clearing the
files in NEWS.next.

    NEWS.next/
        3.3.txt  # Empty file
        3.4.txt  # Empty file
   NEWS  # Complete entry for 3.4.0

The part I'm not clear on is whether we'd then start getting conflicts
when forwarding merging changes to NEWS.next/3.3.txt from the 3.3
branch, or if Mercurial would be smart enough to cope with the
deletion for the file contents and not try to add them back in. If it
can't cope, then it would be possible to do the following on 3.3 when
creating the initial 3.4.0a1 release:

    NEWS.next/
        3.3.txt  # Empty file
   NEWS  # Longer partial entry for 3.3.x

We then continuing accumulating NEWS.next entries in parallel during
the 3.4 alpha and beta cycle, moving the entries into the appropriate
NEWS files as releases are made.

The other advantage of this is that it's an approach we can adopt
*today*, so long as we acknowledge we'll need the tooling to merge the
NEWS entries and clear NEWS.next before we can next do a release for
3.3 and 3.4, and Georg and Larry are happy with that notion.

Cheers,
Nick.

--
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia

From brett at python.org  Sat May 25 17:10:16 2013
From: brett at python.org (Brett Cannon)
Date: Sat, 25 May 2013 11:10:16 -0400
Subject: [python-committers] what's going on with Misc/NEWS?
In-Reply-To: <CADiSq7dzBtiu_foR2+oFeBZrVwCgNtu6VrZQ_nkYb11b+NFkyg@mail.gmail.com>
References: <CAP1=2W55By0cjq2J0cxcMuQKoCQLc+ty0PKtY6Ud0h6UpMsAeQ@mail.gmail.com>
	<CADiSq7dezvi=ATp1mAS6h36A7f0FbpQb39k9ZvjinY4zVLSt5A@mail.gmail.com>
	<CAP1=2W5UpoZLugDRxAS1ZyzxvSiK4LQUq_EL2ktHAm6xoWhXrQ@mail.gmail.com>
	<51CA58D1-1B7C-4397-967F-B4C87330D638@gmail.com>
	<CALFfu7Dk9i9AXqMj8eXYPCcyOPaZtzJcddbrNqbRvjj3xPeF2w@mail.gmail.com>
	<CADiSq7dzBtiu_foR2+oFeBZrVwCgNtu6VrZQ_nkYb11b+NFkyg@mail.gmail.com>
Message-ID: <CAP1=2W5EVz6=VLz5t1OCZj6zbPf6=VSmFnPQAp-aaV-tyY+0sQ@mail.gmail.com>

On Sat, May 25, 2013 at 4:40 AM, Nick Coghlan <ncoghlan at gmail.com> wrote:
> On Sat, May 25, 2013 at 2:01 PM, Eric Snow <ericsnowcurrently at gmail.com> wrote:
>> On Fri, May 24, 2013 at 9:46 PM, Raymond Hettinger
>> <raymond.hettinger at gmail.com> wrote:
>>> and it recognizes that users don't really need to look across merge
>>> boundaries.
>>
>> This is tricky though for any patch that is forward-ported to a
>> release branch (a la 3.2->3.3).  How can you tell from MISC/News in
>> which release (e.g. 3.3.0 or 3.3.1) of that branch the bug was fixed?
>> The entry would only show up in MISC/News for the previous release
>> (e.g. 3.2.3).
>>
>> Granted, this would impact much fewer patches than our current pain point does.
>
> Let's take a step back for a moment and define the workflows we want to handle.
>
> 1. Feature development
>
> - simplest case
> - just edit Misc/NEWS on default
>
> 2. Normal 3.x only bug fix
>
> - second simplest case
> - exit Misc/NEWS on 3.3
> - merge to default
> - frequently conflict (due to entries for new features and different
> release headers)
> ....
>
> OK, I'm going to stop enumerating the cases there, because it already
> suggests to me that splitting the *whole* NEWS file entirely by
> version is the wrong thing to do. Instead, we really only need to
> split the handling for NEWS items that haven't been released yet.

Yes, that's a very good point.

>
> To avoid needing to copy info from other branches between files when
> doing a merge, we could instead set up the following:
>
> 1. Add a new directory called NEWS.next
> 2. New NEWS entries go in version specific files in that directory
> 3. When a new release is made, ALL entries in NEWS.next are added to
> the top of the main NEWS file for the relevant (a script to help with
> the merging would be a good idea) and the contents of NEWS.next are
> cleared.

Still with you.

>
> So, suppose we're about to release 3.4.0a1. In the meantime, we have
> accumulated bug fixes for 3.3 and new features and bug fixes that
> couldn't be backported for 3.4. (The scheme could be extended to
> security branches too, but I'm assuming for the moment those will be
> handled via selective backporting rather than the normal forward
> porting path)
>
> The 3.3 branch layout would look like this:
>
>     NEWS.next/
>         3.3.txt  # Categorised changes

Categorized how? E.g. Core,Lib,Docs, etc.? Or "3.3 only", "3.3 and 3.4"?

>     NEWS  # Existing partial entry for 3.3.x

And the accumulated history of all previous versions.

>
> The default branch layout would look like this:
>
>     NEWS.next/
>         3.3.txt  # Forward ported categorised changes
>         3.4.txt  # Categorised changes
>    NEWS  # Existing partial entry for 3.4.0a1
>
> Any changes that were specific to 3.3 would be listed in
> NEWS.next/3.3.txt on that branch, but not on the default branch (since
> the associated null-merge would have skipped adding them)
>
> Now, we go to create 3.4.0a1. This will involve transferring *all* the
> NEWS.next entries on default into the main NEWS file and clearing the
> files in NEWS.next.
>
>     NEWS.next/
>         3.3.txt  # Empty file
>         3.4.txt  # Empty file
>    NEWS  # Complete entry for 3.4.0
>
> The part I'm not clear on is whether we'd then start getting conflicts
> when forwarding merging changes to NEWS.next/3.3.txt from the 3.3
> branch, or if Mercurial would be smart enough to cope with the
> deletion for the file contents and not try to add them back in. If it
> can't cope, then it would be possible to do the following on 3.3 when
> creating the initial 3.4.0a1 release:
>
>     NEWS.next/
>         3.3.txt  # Empty file
>    NEWS  # Longer partial entry for 3.3.x

Right, and that's the tricky bit. You can have a 3.3 file which is
stuff that is not forward-ported (and thus just delete the file in
default and won't hg just ignore the diff for that file?) and you can
have a 3.4 file that only exists in default so you don't have to worry
about any merge issues.

But it's the 3.3+ changes that exist in both versions. That's the
sticking point and where we always have merge problems. We might want
to classify commits as 3.3 only, 3.3+3.4, or 3.4 only and have
separate files for each case.

Since these files are for staging NEWS entries essentially and are not
meant to be seen by the general public, we can be a little messy here.
So why don't we simply use markers in a 3.3+3.4 file that gets merged
across 3.3 and default that represents "from this line down,
everything has been merged into the main NEWS file under 3.4" and then
some other line that represents "from this line down everything has
been merged into the main NEWS file for 3.3". Then above those lines
we just start a new set of sections we continue to populate every time
there is some merger in some version for NEWS. A script can easily
figure out that some region is new to 3.4 or 3.3 based on reasonable
markers and just searching far enough back in the file to the last
merge for a specific feature release. And who cares if we have a
bazillion Library sections as long as the Library section at the top
is where we always put new entries that go into 3.3 and 3.4? Then
there is no merge conflict, no repeating ourselves and it's still easy
to add NEWS entries.

>
> We then continuing accumulating NEWS.next entries in parallel during
> the 3.4 alpha and beta cycle, moving the entries into the appropriate
> NEWS files as releases are made.
>
> The other advantage of this is that it's an approach we can adopt
> *today*, so long as we acknowledge we'll need the tooling to merge the
> NEWS entries and clear NEWS.next before we can next do a release for
> 3.3 and 3.4, and Georg and Larry are happy with that notion.

Yes, it's yet another step for release managers, but if we tool it
right and add it to release.py the burden should be low to
non-existent (biggest issue would be resolving the potential merge
conflict from 3.3 to default after a release when the main NEWS file
is updated).

From ncoghlan at gmail.com  Sat May 25 17:29:12 2013
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Sun, 26 May 2013 01:29:12 +1000
Subject: [python-committers] what's going on with Misc/NEWS?
In-Reply-To: <CAP1=2W5EVz6=VLz5t1OCZj6zbPf6=VSmFnPQAp-aaV-tyY+0sQ@mail.gmail.com>
References: <CAP1=2W55By0cjq2J0cxcMuQKoCQLc+ty0PKtY6Ud0h6UpMsAeQ@mail.gmail.com>
	<CADiSq7dezvi=ATp1mAS6h36A7f0FbpQb39k9ZvjinY4zVLSt5A@mail.gmail.com>
	<CAP1=2W5UpoZLugDRxAS1ZyzxvSiK4LQUq_EL2ktHAm6xoWhXrQ@mail.gmail.com>
	<51CA58D1-1B7C-4397-967F-B4C87330D638@gmail.com>
	<CALFfu7Dk9i9AXqMj8eXYPCcyOPaZtzJcddbrNqbRvjj3xPeF2w@mail.gmail.com>
	<CADiSq7dzBtiu_foR2+oFeBZrVwCgNtu6VrZQ_nkYb11b+NFkyg@mail.gmail.com>
	<CAP1=2W5EVz6=VLz5t1OCZj6zbPf6=VSmFnPQAp-aaV-tyY+0sQ@mail.gmail.com>
Message-ID: <CADiSq7cka=swW+kxoe=yebU0JuaC7iyZe1c4iPcDHAx=7Z-unQ@mail.gmail.com>

On Sun, May 26, 2013 at 1:10 AM, Brett Cannon <brett at python.org> wrote:
> On Sat, May 25, 2013 at 4:40 AM, Nick Coghlan <ncoghlan at gmail.com> wrote:
>> The 3.3 branch layout would look like this:
>>
>>     NEWS.next/
>>         3.3.txt  # Categorised changes
>
> Categorized how? E.g. Core,Lib,Docs, etc.? Or "3.3 only", "3.3 and 3.4"?

Just the existing categories. So Core, Library, etc

>>     NEWS  # Existing partial entry for 3.3.x
>
> And the accumulated history of all previous versions.

Indeed.

> But it's the 3.3+ changes that exist in both versions. That's the
> sticking point and where we always have merge problems. We might want
> to classify commits as 3.3 only, 3.3+3.4, or 3.4 only and have
> separate files for each case.

Yeah, I think that makes sense - we're going to know which we have
before we create the news entry, so how about if the layout looked
like this:

3.3 branch layout:

    NEWS.next/
        3.3.txt  # Forward ported
        3.3-only.txt # Not forward ported
    NEWS  # Existing partial entry for 3.3.x

The default branch layout would look like this:

    NEWS.next/
        3.3.txt  # Forward ported changes
        3.4.txt  # All 3.4 changes
   NEWS  # Existing partial entry for 3.4.0a1

Any changes that were specific to 3.3 would be listed in
NEWS.next/3.3-only.txt on that branch, but not on the default branch (since
the associated null-merge would always skip adding that file)

Now, we go to create 3.4.0a1 with this layout. This will involve
transferring *all* the
NEWS.next entries on default into the main NEWS file and clearing the
files in NEWS.next.

    NEWS.next/
        3.3.txt  # Empty file
        3.4.txt  # Empty file
   NEWS  # Complete entry for 3.4.0

We then go back to the 3.3 branch, and move all of the
NEWS.next/3.3.txt entries into NEWS.next/3.3-only.txt and do a null
merge.

    NEWS.next/
        3.3.txt  # Empty file
        3.3-only.txt # Not forward ported or already released for 3.4
    NEWS  # Existing partial entry for 3.3.x

When it comes time to create the next 3.3 release, the contents of
both NEWS.next/3.3.txt and NEWS.next/3.3-only.txt would be merged into
the main 3.3 NEWS file.

Does that seem workable?

Cheers,
Nick.

--
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia

From greg at krypto.org  Sat May 25 17:29:49 2013
From: greg at krypto.org (Gregory P. Smith)
Date: Sat, 25 May 2013 09:29:49 -0600
Subject: [python-committers] what's going on with Misc/NEWS?
In-Reply-To: <CADiSq7dzBtiu_foR2+oFeBZrVwCgNtu6VrZQ_nkYb11b+NFkyg@mail.gmail.com>
References: <CAP1=2W55By0cjq2J0cxcMuQKoCQLc+ty0PKtY6Ud0h6UpMsAeQ@mail.gmail.com>
	<CADiSq7dezvi=ATp1mAS6h36A7f0FbpQb39k9ZvjinY4zVLSt5A@mail.gmail.com>
	<CAP1=2W5UpoZLugDRxAS1ZyzxvSiK4LQUq_EL2ktHAm6xoWhXrQ@mail.gmail.com>
	<51CA58D1-1B7C-4397-967F-B4C87330D638@gmail.com>
	<CALFfu7Dk9i9AXqMj8eXYPCcyOPaZtzJcddbrNqbRvjj3xPeF2w@mail.gmail.com>
	<CADiSq7dzBtiu_foR2+oFeBZrVwCgNtu6VrZQ_nkYb11b+NFkyg@mail.gmail.com>
Message-ID: <CAGE7PNJdZZVtyo=12fWv+Ero7BO+Ds3JWq0-VaV+zXv-HHcD6A@mail.gmail.com>

On May 25, 2013 1:40 AM, "Nick Coghlan" <ncoghlan at gmail.com> wrote:
>
> On Sat, May 25, 2013 at 2:01 PM, Eric Snow <ericsnowcurrently at gmail.com>
wrote:
> > On Fri, May 24, 2013 at 9:46 PM, Raymond Hettinger
> > <raymond.hettinger at gmail.com> wrote:
> >> and it recognizes that users don't really need to look across merge
> >> boundaries.
> >
> > This is tricky though for any patch that is forward-ported to a
> > release branch (a la 3.2->3.3).  How can you tell from MISC/News in
> > which release (e.g. 3.3.0 or 3.3.1) of that branch the bug was fixed?
> > The entry would only show up in MISC/News for the previous release
> > (e.g. 3.2.3).
> >
> > Granted, this would impact much fewer patches than our current pain
point does.
>
> Let's take a step back for a moment and define the workflows we want to
handle.
>
> 1. Feature development
>
> - simplest case
> - just edit Misc/NEWS on default
>
> 2. Normal 3.x only bug fix
>
> - second simplest case
> - exit Misc/NEWS on 3.3
> - merge to default
> - frequently conflict (due to entries for new features and different
> release headers)
> ....
>
> OK, I'm going to stop enumerating the cases there, because it already
> suggests to me that splitting the *whole* NEWS file entirely by
> version is the wrong thing to do. Instead, we really only need to
> split the handling for NEWS items that haven't been released yet.
>
> To avoid needing to copy info from other branches between files when
> doing a merge, we could instead set up the following:
>
> 1. Add a new directory called NEWS.next
> 2. New NEWS entries go in version specific files in that directory
> 3. When a new release is made, ALL entries in NEWS.next are added to
> the top of the main NEWS file for the relevant (a script to help with
> the merging would be a good idea) and the contents of NEWS.next are
> cleared.
>
> So, suppose we're about to release 3.4.0a1. In the meantime, we have
> accumulated bug fixes for 3.3 and new features and bug fixes that
> couldn't be backported for 3.4. (The scheme could be extended to
> security branches too, but I'm assuming for the moment those will be
> handled via selective backporting rather than the normal forward
> porting path)
>
> The 3.3 branch layout would look like this:
>
>     NEWS.next/
>         3.3.txt  # Categorised changes
>     NEWS  # Existing partial entry for 3.3.x
>
> The default branch layout would look like this:
>
>     NEWS.next/
>         3.3.txt  # Forward ported categorised changes
>         3.4.txt  # Categorised changes
>    NEWS  # Existing partial entry for 3.4.0a1
>
> Any changes that were specific to 3.3 would be listed in
> NEWS.next/3.3.txt on that branch, but not on the default branch (since
> the associated null-merge would have skipped adding them)
>
> Now, we go to create 3.4.0a1. This will involve transferring *all* the
> NEWS.next entries on default into the main NEWS file and clearing the
> files in NEWS.next.
>
>     NEWS.next/
>         3.3.txt  # Empty file
>         3.4.txt  # Empty file
>    NEWS  # Complete entry for 3.4.0
>
> The part I'm not clear on is whether we'd then start getting conflicts
> when forwarding merging changes to NEWS.next/3.3.txt from the 3.3
> branch, or if Mercurial would be smart enough to cope with the
> deletion for the file contents and not try to add them back in. If it
> can't cope, then it would be possible to do the following on 3.3 when
> creating the initial 3.4.0a1 release:
>
>     NEWS.next/
>         3.3.txt  # Empty file
>    NEWS  # Longer partial entry for 3.3.x
>
> We then continuing accumulating NEWS.next entries in parallel during
> the 3.4 alpha and beta cycle, moving the entries into the appropriate
> NEWS files as releases are made.
>
> The other advantage of this is that it's an approach we can adopt
> *today*, so long as we acknowledge we'll need the tooling to merge the
> NEWS entries and clear NEWS.next before we can next do a release for
> 3.3 and 3.4, and Georg and Larry are happy with that notion.
>

I like where you're heading with this but it still leaves merges during
Spruits and when a few people are working at once by putting stuff in a
single file.

Per news item / per issue files for each release that are riled up into the
actual news file by a release manager run script & commit at release time
make more sense.

> Cheers,
> Nick.
>
> --
> Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia
> _______________________________________________
> python-committers mailing list
> python-committers at python.org
> http://mail.python.org/mailman/listinfo/python-committers
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-committers/attachments/20130525/e72327f4/attachment-0001.html>

From greg at krypto.org  Sat May 25 17:31:22 2013
From: greg at krypto.org (Gregory P. Smith)
Date: Sat, 25 May 2013 09:31:22 -0600
Subject: [python-committers] what's going on with Misc/NEWS?
In-Reply-To: <CAGE7PNJdZZVtyo=12fWv+Ero7BO+Ds3JWq0-VaV+zXv-HHcD6A@mail.gmail.com>
References: <CAP1=2W55By0cjq2J0cxcMuQKoCQLc+ty0PKtY6Ud0h6UpMsAeQ@mail.gmail.com>
	<CADiSq7dezvi=ATp1mAS6h36A7f0FbpQb39k9ZvjinY4zVLSt5A@mail.gmail.com>
	<CAP1=2W5UpoZLugDRxAS1ZyzxvSiK4LQUq_EL2ktHAm6xoWhXrQ@mail.gmail.com>
	<51CA58D1-1B7C-4397-967F-B4C87330D638@gmail.com>
	<CALFfu7Dk9i9AXqMj8eXYPCcyOPaZtzJcddbrNqbRvjj3xPeF2w@mail.gmail.com>
	<CADiSq7dzBtiu_foR2+oFeBZrVwCgNtu6VrZQ_nkYb11b+NFkyg@mail.gmail.com>
	<CAGE7PNJdZZVtyo=12fWv+Ero7BO+Ds3JWq0-VaV+zXv-HHcD6A@mail.gmail.com>
Message-ID: <CAGE7PNLvBpSxawLa5cuztGNDrZJPpzspo3zTsMnmFmhJs3PHaw@mail.gmail.com>

On May 25, 2013 8:29 AM, "Gregory P. Smith" <greg at krypto.org> wrote:
>
>
> On May 25, 2013 1:40 AM, "Nick Coghlan" <ncoghlan at gmail.com> wrote:
> >
> > On Sat, May 25, 2013 at 2:01 PM, Eric Snow <ericsnowcurrently at gmail.com>
wrote:
> > > On Fri, May 24, 2013 at 9:46 PM, Raymond Hettinger
> > > <raymond.hettinger at gmail.com> wrote:
> > >> and it recognizes that users don't really need to look across merge
> > >> boundaries.
> > >
> > > This is tricky though for any patch that is forward-ported to a
> > > release branch (a la 3.2->3.3).  How can you tell from MISC/News in
> > > which release (e.g. 3.3.0 or 3.3.1) of that branch the bug was fixed?
> > > The entry would only show up in MISC/News for the previous release
> > > (e.g. 3.2.3).
> > >
> > > Granted, this would impact much fewer patches than our current pain
point does.
> >
> > Let's take a step back for a moment and define the workflows we want to
handle.
> >
> > 1. Feature development
> >
> > - simplest case
> > - just edit Misc/NEWS on default
> >
> > 2. Normal 3.x only bug fix
> >
> > - second simplest case
> > - exit Misc/NEWS on 3.3
> > - merge to default
> > - frequently conflict (due to entries for new features and different
> > release headers)
> > ....
> >
> > OK, I'm going to stop enumerating the cases there, because it already
> > suggests to me that splitting the *whole* NEWS file entirely by
> > version is the wrong thing to do. Instead, we really only need to
> > split the handling for NEWS items that haven't been released yet.
> >
> > To avoid needing to copy info from other branches between files when
> > doing a merge, we could instead set up the following:
> >
> > 1. Add a new directory called NEWS.next
> > 2. New NEWS entries go in version specific files in that directory
> > 3. When a new release is made, ALL entries in NEWS.next are added to
> > the top of the main NEWS file for the relevant (a script to help with
> > the merging would be a good idea) and the contents of NEWS.next are
> > cleared.
> >
> > So, suppose we're about to release 3.4.0a1. In the meantime, we have
> > accumulated bug fixes for 3.3 and new features and bug fixes that
> > couldn't be backported for 3.4. (The scheme could be extended to
> > security branches too, but I'm assuming for the moment those will be
> > handled via selective backporting rather than the normal forward
> > porting path)
> >
> > The 3.3 branch layout would look like this:
> >
> >     NEWS.next/
> >         3.3.txt  # Categorised changes
> >     NEWS  # Existing partial entry for 3.3.x
> >
> > The default branch layout would look like this:
> >
> >     NEWS.next/
> >         3.3.txt  # Forward ported categorised changes
> >         3.4.txt  # Categorised changes
> >    NEWS  # Existing partial entry for 3.4.0a1
> >
> > Any changes that were specific to 3.3 would be listed in
> > NEWS.next/3.3.txt on that branch, but not on the default branch (since
> > the associated null-merge would have skipped adding them)
> >
> > Now, we go to create 3.4.0a1. This will involve transferring *all* the
> > NEWS.next entries on default into the main NEWS file and clearing the
> > files in NEWS.next.
> >
> >     NEWS.next/
> >         3.3.txt  # Empty file
> >         3.4.txt  # Empty file
> >    NEWS  # Complete entry for 3.4.0
> >
> > The part I'm not clear on is whether we'd then start getting conflicts
> > when forwarding merging changes to NEWS.next/3.3.txt from the 3.3
> > branch, or if Mercurial would be smart enough to cope with the
> > deletion for the file contents and not try to add them back in. If it
> > can't cope, then it would be possible to do the following on 3.3 when
> > creating the initial 3.4.0a1 release:
> >
> >     NEWS.next/
> >         3.3.txt  # Empty file
> >    NEWS  # Longer partial entry for 3.3.x
> >
> > We then continuing accumulating NEWS.next entries in parallel during
> > the 3.4 alpha and beta cycle, moving the entries into the appropriate
> > NEWS files as releases are made.
> >
> > The other advantage of this is that it's an approach we can adopt
> > *today*, so long as we acknowledge we'll need the tooling to merge the
> > NEWS entries and clear NEWS.next before we can next do a release for
> > 3.3 and 3.4, and Georg and Larry are happy with that notion.
> >
>
> I like where you're heading with this but it still leaves merges during
Spruits and when a few people are working at once by putting stuff in a
single file.

sprints

>
> Per news item / per issue files for each release that are riled up into
the actual news file by a release manager run script & commit at release
time make more sense.
>
> > Cheers,
> > Nick.
> >
> > --
> > Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia
> > _______________________________________________
> > python-committers mailing list
> > python-committers at python.org
> > http://mail.python.org/mailman/listinfo/python-committers
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-committers/attachments/20130525/5fbd8cb8/attachment.html>

From ncoghlan at gmail.com  Sat May 25 18:05:54 2013
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Sun, 26 May 2013 02:05:54 +1000
Subject: [python-committers] what's going on with Misc/NEWS?
In-Reply-To: <CAGE7PNJdZZVtyo=12fWv+Ero7BO+Ds3JWq0-VaV+zXv-HHcD6A@mail.gmail.com>
References: <CAP1=2W55By0cjq2J0cxcMuQKoCQLc+ty0PKtY6Ud0h6UpMsAeQ@mail.gmail.com>
	<CADiSq7dezvi=ATp1mAS6h36A7f0FbpQb39k9ZvjinY4zVLSt5A@mail.gmail.com>
	<CAP1=2W5UpoZLugDRxAS1ZyzxvSiK4LQUq_EL2ktHAm6xoWhXrQ@mail.gmail.com>
	<51CA58D1-1B7C-4397-967F-B4C87330D638@gmail.com>
	<CALFfu7Dk9i9AXqMj8eXYPCcyOPaZtzJcddbrNqbRvjj3xPeF2w@mail.gmail.com>
	<CADiSq7dzBtiu_foR2+oFeBZrVwCgNtu6VrZQ_nkYb11b+NFkyg@mail.gmail.com>
	<CAGE7PNJdZZVtyo=12fWv+Ero7BO+Ds3JWq0-VaV+zXv-HHcD6A@mail.gmail.com>
Message-ID: <CADiSq7dhfxHCvBB7fgTRPmnTJjPKGkuWUypcwR7iqQx3RX0z=A@mail.gmail.com>

On Sun, May 26, 2013 at 1:29 AM, Gregory P. Smith <greg at krypto.org> wrote:
> I like where you're heading with this but it still leaves merges during
> Spruits and when a few people are working at once by putting stuff in a
> single file.
>
> Per news item / per issue files for each release that are riled up into the
> actual news file by a release manager run script & commit at release time
> make more sense.

That's heading back to where I started, when people dismissed the idea
as too complex. It's a pretty straightforward change to my previous
suggestion though. Instead of having these layouts:

    NEWS.next/
        3.3.txt
        3.3-only.txt

    NEWS.next/
        3.3.txt
        3.4.txt

You instead have layouts like:

    NEWS.next/
        3.3/
            core/
                issue123456.txt # Core change with issue number
                misc.txt # Core changes without issue numbers
            library/
                issue54321.txt # Library change with issue number
                misc.txt # Library changes without issue numbers
            ...
       3.3-only/
            ...

    NEWS.next/
        3.3/
            ...
        3.4/
            ...

Whether categorisation is done by file prefix or by directories
doesn't make much difference, although I have a slight preference for
separate folders since repeating prefixes feels like irrelevant noise.

The NEWS update script could even use the revision history to decide
which order to add entries to the bulleted list.

Cheers,
Nick.

--
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia

From brett at python.org  Sun May 26 01:41:12 2013
From: brett at python.org (Brett Cannon)
Date: Sat, 25 May 2013 19:41:12 -0400
Subject: [python-committers] what's going on with Misc/NEWS?
In-Reply-To: <CADiSq7dhfxHCvBB7fgTRPmnTJjPKGkuWUypcwR7iqQx3RX0z=A@mail.gmail.com>
References: <CAP1=2W55By0cjq2J0cxcMuQKoCQLc+ty0PKtY6Ud0h6UpMsAeQ@mail.gmail.com>
	<CADiSq7dezvi=ATp1mAS6h36A7f0FbpQb39k9ZvjinY4zVLSt5A@mail.gmail.com>
	<CAP1=2W5UpoZLugDRxAS1ZyzxvSiK4LQUq_EL2ktHAm6xoWhXrQ@mail.gmail.com>
	<51CA58D1-1B7C-4397-967F-B4C87330D638@gmail.com>
	<CALFfu7Dk9i9AXqMj8eXYPCcyOPaZtzJcddbrNqbRvjj3xPeF2w@mail.gmail.com>
	<CADiSq7dzBtiu_foR2+oFeBZrVwCgNtu6VrZQ_nkYb11b+NFkyg@mail.gmail.com>
	<CAGE7PNJdZZVtyo=12fWv+Ero7BO+Ds3JWq0-VaV+zXv-HHcD6A@mail.gmail.com>
	<CADiSq7dhfxHCvBB7fgTRPmnTJjPKGkuWUypcwR7iqQx3RX0z=A@mail.gmail.com>
Message-ID: <CAP1=2W66Tp5P-ExGZVzzBr3AhrHfKZ46Q2KmEmZtZpDh+YjCDA@mail.gmail.com>

On Sat, May 25, 2013 at 12:05 PM, Nick Coghlan <ncoghlan at gmail.com> wrote:
> On Sun, May 26, 2013 at 1:29 AM, Gregory P. Smith <greg at krypto.org> wrote:
>> I like where you're heading with this but it still leaves merges during
>> Spruits and when a few people are working at once by putting stuff in a
>> single file.

I don't know if sprints happen often enough to make them a big worry,
but it's true they are there.

>>
>> Per news item / per issue files for each release that are riled up into the
>> actual news file by a release manager run script & commit at release time
>> make more sense.
>
> That's heading back to where I started, when people dismissed the idea
> as too complex. It's a pretty straightforward change to my previous
> suggestion though. Instead of having these layouts:
>
>     NEWS.next/
>         3.3.txt
>         3.3-only.txt
>
>     NEWS.next/
>         3.3.txt
>         3.4.txt
>
> You instead have layouts like:
>
>     NEWS.next/
>         3.3/
>             core/
>                 issue123456.txt # Core change with issue number
>                 misc.txt # Core changes without issue numbers
>             library/
>                 issue54321.txt # Library change with issue number
>                 misc.txt # Library changes without issue numbers
>             ...
>        3.3-only/
>             ...
>
>     NEWS.next/
>         3.3/
>             ...
>         3.4/
>             ...
>
> Whether categorisation is done by file prefix or by directories
> doesn't make much difference, although I have a slight preference for
> separate folders since repeating prefixes feels like irrelevant noise.

Directory if this happens.

>
> The NEWS update script could even use the revision history to decide
> which order to add entries to the bulleted list.

I think the annoyance with this approach is you will have to remember
to add a file every time you do anything worthy of NEWS. Without
something like ``hg newsworthy`` to take an optional issue # and then
have you enter your NEWS entry and then use that to pre-populate the
commit message, people will forget. Now granted adding the commit
later is not a huge deal, but it is something that might happen if you
forget to ``hg st`` before committing.

And if you go that route you start to end up with something like a
marker to separate in the commit message what is meant for the commit
and what is meant for NEWS.

From ncoghlan at gmail.com  Sun May 26 03:18:43 2013
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Sun, 26 May 2013 11:18:43 +1000
Subject: [python-committers] what's going on with Misc/NEWS?
In-Reply-To: <CAP1=2W66Tp5P-ExGZVzzBr3AhrHfKZ46Q2KmEmZtZpDh+YjCDA@mail.gmail.com>
References: <CAP1=2W55By0cjq2J0cxcMuQKoCQLc+ty0PKtY6Ud0h6UpMsAeQ@mail.gmail.com>
	<CADiSq7dezvi=ATp1mAS6h36A7f0FbpQb39k9ZvjinY4zVLSt5A@mail.gmail.com>
	<CAP1=2W5UpoZLugDRxAS1ZyzxvSiK4LQUq_EL2ktHAm6xoWhXrQ@mail.gmail.com>
	<51CA58D1-1B7C-4397-967F-B4C87330D638@gmail.com>
	<CALFfu7Dk9i9AXqMj8eXYPCcyOPaZtzJcddbrNqbRvjj3xPeF2w@mail.gmail.com>
	<CADiSq7dzBtiu_foR2+oFeBZrVwCgNtu6VrZQ_nkYb11b+NFkyg@mail.gmail.com>
	<CAGE7PNJdZZVtyo=12fWv+Ero7BO+Ds3JWq0-VaV+zXv-HHcD6A@mail.gmail.com>
	<CADiSq7dhfxHCvBB7fgTRPmnTJjPKGkuWUypcwR7iqQx3RX0z=A@mail.gmail.com>
	<CAP1=2W66Tp5P-ExGZVzzBr3AhrHfKZ46Q2KmEmZtZpDh+YjCDA@mail.gmail.com>
Message-ID: <CADiSq7fj_52ShO6S0WBQzhr3agpbaAvFmX-J5N86pU=6RsSsdQ@mail.gmail.com>

On Sun, May 26, 2013 at 9:41 AM, Brett Cannon <brett at python.org> wrote:
>> The NEWS update script could even use the revision history to decide
>> which order to add entries to the bulleted list.
>
> I think the annoyance with this approach is you will have to remember
> to add a file every time you do anything worthy of NEWS. Without
> something like ``hg newsworthy`` to take an optional issue # and then
> have you enter your NEWS entry and then use that to pre-populate the
> commit message, people will forget. Now granted adding the commit
> later is not a huge deal, but it is something that might happen if you
> forget to ``hg st`` before committing.

How is that any different from the status quo with people forgetting
an entry in NEWS? Just the extra step of needing to "hg add" the news
entry?

Well, perhaps we can do this in two phases - resolve the persistent
problem of merge conflicts first, and then worry about the separate
push race problem later.

Cheers,
Nick.

--
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia

From brett at python.org  Sun May 26 22:15:31 2013
From: brett at python.org (Brett Cannon)
Date: Sun, 26 May 2013 16:15:31 -0400
Subject: [python-committers] what's going on with Misc/NEWS?
In-Reply-To: <CADiSq7fj_52ShO6S0WBQzhr3agpbaAvFmX-J5N86pU=6RsSsdQ@mail.gmail.com>
References: <CAP1=2W55By0cjq2J0cxcMuQKoCQLc+ty0PKtY6Ud0h6UpMsAeQ@mail.gmail.com>
	<CADiSq7dezvi=ATp1mAS6h36A7f0FbpQb39k9ZvjinY4zVLSt5A@mail.gmail.com>
	<CAP1=2W5UpoZLugDRxAS1ZyzxvSiK4LQUq_EL2ktHAm6xoWhXrQ@mail.gmail.com>
	<51CA58D1-1B7C-4397-967F-B4C87330D638@gmail.com>
	<CALFfu7Dk9i9AXqMj8eXYPCcyOPaZtzJcddbrNqbRvjj3xPeF2w@mail.gmail.com>
	<CADiSq7dzBtiu_foR2+oFeBZrVwCgNtu6VrZQ_nkYb11b+NFkyg@mail.gmail.com>
	<CAGE7PNJdZZVtyo=12fWv+Ero7BO+Ds3JWq0-VaV+zXv-HHcD6A@mail.gmail.com>
	<CADiSq7dhfxHCvBB7fgTRPmnTJjPKGkuWUypcwR7iqQx3RX0z=A@mail.gmail.com>
	<CAP1=2W66Tp5P-ExGZVzzBr3AhrHfKZ46Q2KmEmZtZpDh+YjCDA@mail.gmail.com>
	<CADiSq7fj_52ShO6S0WBQzhr3agpbaAvFmX-J5N86pU=6RsSsdQ@mail.gmail.com>
Message-ID: <CAP1=2W594FHhRtvp==Wc5cgBSkP4tB8cfkpQT22-k993VgtFZg@mail.gmail.com>

On May 25, 2013 9:18 PM, "Nick Coghlan" <ncoghlan at gmail.com> wrote:
>
> On Sun, May 26, 2013 at 9:41 AM, Brett Cannon <brett at python.org> wrote:
> >> The NEWS update script could even use the revision history to decide
> >> which order to add entries to the bulleted list.
> >
> > I think the annoyance with this approach is you will have to remember
> > to add a file every time you do anything worthy of NEWS. Without
> > something like ``hg newsworthy`` to take an optional issue # and then
> > have you enter your NEWS entry and then use that to pre-populate the
> > commit message, people will forget. Now granted adding the commit
> > later is not a huge deal, but it is something that might happen if you
> > forget to ``hg st`` before committing.
>
> How is that any different from the status quo with people forgetting
> an entry in NEWS? Just the extra step of needing to "hg add" the news
> entry?

I didn't think there was a forgetfulness issue. I'm just trying to lower
the overhead of doing a merge.

>
> Well, perhaps we can do this in two phases - resolve the persistent
> problem of merge conflicts first, and then worry about the separate
> push race problem later.

If we can ever agree on a solution. :)

-brett

>
> Cheers,
> Nick.
>
> --
> Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-committers/attachments/20130526/01bd7f8c/attachment.html>

From greg at krypto.org  Sun May 26 22:22:36 2013
From: greg at krypto.org (Gregory P. Smith)
Date: Sun, 26 May 2013 14:22:36 -0600
Subject: [python-committers] what's going on with Misc/NEWS?
In-Reply-To: <CAP1=2W594FHhRtvp==Wc5cgBSkP4tB8cfkpQT22-k993VgtFZg@mail.gmail.com>
References: <CAP1=2W55By0cjq2J0cxcMuQKoCQLc+ty0PKtY6Ud0h6UpMsAeQ@mail.gmail.com>
	<CADiSq7dezvi=ATp1mAS6h36A7f0FbpQb39k9ZvjinY4zVLSt5A@mail.gmail.com>
	<CAP1=2W5UpoZLugDRxAS1ZyzxvSiK4LQUq_EL2ktHAm6xoWhXrQ@mail.gmail.com>
	<51CA58D1-1B7C-4397-967F-B4C87330D638@gmail.com>
	<CALFfu7Dk9i9AXqMj8eXYPCcyOPaZtzJcddbrNqbRvjj3xPeF2w@mail.gmail.com>
	<CADiSq7dzBtiu_foR2+oFeBZrVwCgNtu6VrZQ_nkYb11b+NFkyg@mail.gmail.com>
	<CAGE7PNJdZZVtyo=12fWv+Ero7BO+Ds3JWq0-VaV+zXv-HHcD6A@mail.gmail.com>
	<CADiSq7dhfxHCvBB7fgTRPmnTJjPKGkuWUypcwR7iqQx3RX0z=A@mail.gmail.com>
	<CAP1=2W66Tp5P-ExGZVzzBr3AhrHfKZ46Q2KmEmZtZpDh+YjCDA@mail.gmail.com>
	<CADiSq7fj_52ShO6S0WBQzhr3agpbaAvFmX-J5N86pU=6RsSsdQ@mail.gmail.com>
	<CAP1=2W594FHhRtvp==Wc5cgBSkP4tB8cfkpQT22-k993VgtFZg@mail.gmail.com>
Message-ID: <CAGE7PNLx+0WXB77_ZnUB9JcN2c7m8R2n31rHibRjTE0MChjprA@mail.gmail.com>

On May 26, 2013 1:15 PM, "Brett Cannon" <brett at python.org> wrote:
>
>
> On May 25, 2013 9:18 PM, "Nick Coghlan" <ncoghlan at gmail.com> wrote:
> >
> > On Sun, May 26, 2013 at 9:41 AM, Brett Cannon <brett at python.org> wrote:
> > >> The NEWS update script could even use the revision history to decide
> > >> which order to add entries to the bulleted list.
> > >
> > > I think the annoyance with this approach is you will have to remember
> > > to add a file every time you do anything worthy of NEWS. Without
> > > something like ``hg newsworthy`` to take an optional issue # and then
> > > have you enter your NEWS entry and then use that to pre-populate the
> > > commit message, people will forget. Now granted adding the commit
> > > later is not a huge deal, but it is something that might happen if you
> > > forget to ``hg st`` before committing.
> >
> > How is that any different from the status quo with people forgetting
> > an entry in NEWS? Just the extra step of needing to "hg add" the news
> > entry?
>
> I didn't think there was a forgetfulness issue. I'm just trying to lower
the overhead of doing a merge.
>
> >
> > Well, perhaps we can do this in two phases - resolve the persistent
> > problem of merge conflicts first, and then worry about the separate
> > push race problem later.
>
> If we can ever agree on a solution. :)

If people are still allowed to edit Misc/NEWS manually while a tools and
alternatives are worked out that ultimately merge their entries into the
original file at release time I think no agreement is needed beyond from
the release managers who presumably get to ensure it all happens to
generate the single file at tag/branch time.

Try a few things out, see what sticks and vote on what the ultimate
solution for everyone should be at that point.

>
> -brett
>
> >
> > Cheers,
> > Nick.
> >
> > --
> > Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-committers/attachments/20130526/2de63685/attachment.html>

From ezio.melotti at gmail.com  Sun May 26 23:03:20 2013
From: ezio.melotti at gmail.com (Ezio Melotti)
Date: Mon, 27 May 2013 00:03:20 +0300
Subject: [python-committers] what's going on with Misc/NEWS?
In-Reply-To: <63724bbaea84f6591bb36288355cd96f.squirrel@webmail.nerim.net>
References: <CAP1=2W55By0cjq2J0cxcMuQKoCQLc+ty0PKtY6Ud0h6UpMsAeQ@mail.gmail.com>
	<CADiSq7dezvi=ATp1mAS6h36A7f0FbpQb39k9ZvjinY4zVLSt5A@mail.gmail.com>
	<CAP1=2W5UpoZLugDRxAS1ZyzxvSiK4LQUq_EL2ktHAm6xoWhXrQ@mail.gmail.com>
	<63724bbaea84f6591bb36288355cd96f.squirrel@webmail.nerim.net>
Message-ID: <CACBhJdFbsUZtVMB_t1oU5NxKZJivo7+w0KfyYQGEvML6RP=eXg@mail.gmail.com>

On Fri, May 24, 2013 at 7:39 PM, Antoine Pitrou <solipsis at pitrou.net> wrote:
>
> Brett wrote:
>>> Of course, we've talked about doing something like this before, it's
>>> just never irritated anyone enough for them to sit down and *write*
>>> the associated NEWS file generator, or the code to split the existing
>>> NEWS file for the active branches :)
>>
>> I think that's overly complicated.
>
> Agreed. I'm not surprised Twisted uses something like that :-), but we
> don't need
> that level of complexity.
>

Agreed.

For me, in the best case scenario hg takes care of the merge; in the
worst, kdiff3 pops up and I have to press CTRL and 3, 2, s, q (to
include the two conflicting news, save and quit respectively).
Solving the merge conflict is not something that really bothers me,
and even when hg merge screws up, doing a revert and copying the news
entry manually is not really cumbersome (and it doesn't happen really
often anyway).

I understand that some people don't use and/or they are not sure how
to use merge tools, but spending 10 minutes to install kdiff3 (or
similar tools) and learn how to use it is a good investment IMHO*.

>> I don't see why we need anything
>> more than simply NEWS/3.4, NEWS/3.3, etc. and just split the files per
>> feature release since that's the interest (and merge) boundary.
>
> You'll have to copy stuff by hand, though, if you don't want to rely on the
> merge machinery. So we have two possible file layouts:
>
> * (current) a single Misc/NEWS is merged from branch to branch. Pro: hg merge
> copies the text for you. Con: hg merge sometimes screws up and you have to
> clean up a large conflict.
>
> * a dedicated Misc/NEWS-x.y per major version. Pro: no merge conflicts ever.
> Con: you have to copy the message by hand when merging a bug fix to the upper
> branch. Con: it's easy to forget to copy the message (hg won't yell if you
> don't
> do it), so people *will* forget (and it's annoying grunt work for those who
> notice it).
>
> The major con with the current scheme *might* be solved by a dedicated hg
> extension, but someone needs to have enough free time and passion to try and
> write it :-)
>

This is somewhere on my TODO list but even though hacking on Mercurial
is a lot of fun, its priority is quite low since this "issue" doesn't
affect me.  I'm also not entirely sure what people want -- having
separate files for every major version and an extension that merges
the news entry in the right file should also be doable.

>> And do
>> we really need a merged NEWS file at that granularity?
>
> Not really, IMO.
>

I'm +0 on having a separate file for 3.3, 3.4, etc., as long as I
don't have to copy/paste the news entry in the right file every time.
Anything more than that is just going to cause more troubles.

Best Regards,
Ezio Melotti

As I side note, before committing I always do an "hg diff" to check
that everything is OK.  Misc/NEWS is usually the last file in the
diff, so I just copy the first sentence of the entry and use it in the
commit message.

* this is also valid with Mercurial in general, but there's no need I
tell you this ;)

From senthil at uthcode.com  Tue May 28 16:11:19 2013
From: senthil at uthcode.com (Senthil Kumaran)
Date: Tue, 28 May 2013 07:11:19 -0700
Subject: [python-committers] hg clone cpython newrepo aborts
Message-ID: <CAPOVWOSn+Vd73Fgr9h2r7vCGbpN2rvTTAQhBDgKLj-0sYC68OQ@mail.gmail.com>

While trying to clone a cpython repo to a new repo. I am getting this error.

getting Lib/idlelib/idle.bat
getting Lib/idlelib/idle.py
getting Lib/idlelib/idle.pyw
getting Lib/idlelib/idle_test/@README.txt
abort: data/Lib/idlelib/idle_test/@README.txt.i at 7573717b9e6f: no match
found!

Is something wrong with the repo?

I updated my clone today morning

[cpython]$ hg pull
running ssh hg at hg.python.org 'hg -R cpython serve --stdio'
pulling from ssh://hg at hg.python.org/cpython
searching for changes
no changes found

[cpython]$hg log
changeset:   83956:ad56dff3602f
tag:         tip
parent:      83954:96e543ba96a4
parent:      83955:b864f4056b78
user:        Serhiy Storchaka <storchaka at gmail.com>
date:        Tue May 28 16:27:08 2013 +0300
files:       Lib/test/test_io.py Misc/NEWS Modules/_io/bufferedio.c
description:
Issue #18025: Fixed a segfault in io.BufferedIOBase.readinto() when raw
stream's read() returns more bytes than requested.
...
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-committers/attachments/20130528/b5ca2d15/attachment.html>

From dirkjan at ochtman.nl  Tue May 28 16:19:14 2013
From: dirkjan at ochtman.nl (Dirkjan Ochtman)
Date: Tue, 28 May 2013 16:19:14 +0200
Subject: [python-committers] hg clone cpython newrepo aborts
In-Reply-To: <CAPOVWOSn+Vd73Fgr9h2r7vCGbpN2rvTTAQhBDgKLj-0sYC68OQ@mail.gmail.com>
References: <CAPOVWOSn+Vd73Fgr9h2r7vCGbpN2rvTTAQhBDgKLj-0sYC68OQ@mail.gmail.com>
Message-ID: <CAKmKYaAYu6vuKs+qn9n6UwvdnBv7uiDvQG72sRXvQrxwnK0SNQ@mail.gmail.com>

On Tue, May 28, 2013 at 4:11 PM, Senthil Kumaran <senthil at uthcode.com> wrote:
> While trying to clone a cpython repo to a new repo. I am getting this error.
>
> getting Lib/idlelib/idle.bat
> getting Lib/idlelib/idle.py
> getting Lib/idlelib/idle.pyw
> getting Lib/idlelib/idle_test/@README.txt
> abort: data/Lib/idlelib/idle_test/@README.txt.i at 7573717b9e6f: no match
> found!
>
> Is something wrong with the repo?

It's possible something broke with the @-filename. Have you tried hg verify yet?

Cheers,

Dirkjan

From senthil at uthcode.com  Tue May 28 16:25:04 2013
From: senthil at uthcode.com (Senthil Kumaran)
Date: Tue, 28 May 2013 07:25:04 -0700
Subject: [python-committers] hg clone cpython newrepo aborts
In-Reply-To: <CAKmKYaAYu6vuKs+qn9n6UwvdnBv7uiDvQG72sRXvQrxwnK0SNQ@mail.gmail.com>
References: <CAPOVWOSn+Vd73Fgr9h2r7vCGbpN2rvTTAQhBDgKLj-0sYC68OQ@mail.gmail.com>
	<CAKmKYaAYu6vuKs+qn9n6UwvdnBv7uiDvQG72sRXvQrxwnK0SNQ@mail.gmail.com>
Message-ID: <CAPOVWORUoa1ueGWEhSMsAsN4_GK9eWqR4+uHZGgWet8Yzm3DUw@mail.gmail.com>

On Tue, May 28, 2013 at 7:19 AM, Dirkjan Ochtman <dirkjan at ochtman.nl> wrote:

> On Tue, May 28, 2013 at 4:11 PM, Senthil Kumaran <senthil at uthcode.com>
> wrote:
> > While trying to clone a cpython repo to a new repo. I am getting this
> error.
> >
> > getting Lib/idlelib/idle.bat
> > getting Lib/idlelib/idle.py
> > getting Lib/idlelib/idle.pyw
> > getting Lib/idlelib/idle_test/@README.txt
> > abort: data/Lib/idlelib/idle_test/@README.txt.i at 7573717b9e6f: no match
> > found!
> >
> > Is something wrong with the repo?
>
> It's possible something broke with the @-filename. Have you tried hg
> verify yet?
>
>
$ hg verify
repository uses revlog format 1
checking changesets
checking manifests
crosschecking files in changesets and manifests
checking files
 data/Lib/idlelib/idle_test/@README.txt.i at 83941: missing revlog!
 83941: empty or missing Lib/idlelib/idle_test/@README.txt
 Lib/idlelib/idle_test/@README.txt at 83941: 7573717b9e6f in manifests not
found
warning: copy source of 'Modules/_threadmodule.c' not in parents of
60ad83716733
warning: copy source of 'Objects/bytesobject.c' not in parents of
64bb1d258322
warning: copy source of 'Objects/stringobject.c' not in parents of
357e268e7c5f
9872 files, 83957 changesets, 185453 total revisions
3 warnings encountered!
3 integrity errors encountered!
(first damaged changeset appears to be 83941)


// All these are from my local repo, which i keep updated. I am cloning
from hg.python.org to see if this problem persists.

Thanks,
Senthil
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-committers/attachments/20130528/2708109f/attachment.html>

From benjamin at python.org  Tue May 28 16:29:45 2013
From: benjamin at python.org (Benjamin Peterson)
Date: Tue, 28 May 2013 07:29:45 -0700
Subject: [python-committers] hg clone cpython newrepo aborts
In-Reply-To: <CAPOVWORUoa1ueGWEhSMsAsN4_GK9eWqR4+uHZGgWet8Yzm3DUw@mail.gmail.com>
References: <CAPOVWOSn+Vd73Fgr9h2r7vCGbpN2rvTTAQhBDgKLj-0sYC68OQ@mail.gmail.com>
	<CAKmKYaAYu6vuKs+qn9n6UwvdnBv7uiDvQG72sRXvQrxwnK0SNQ@mail.gmail.com>
	<CAPOVWORUoa1ueGWEhSMsAsN4_GK9eWqR4+uHZGgWet8Yzm3DUw@mail.gmail.com>
Message-ID: <CAPZV6o9iCBL9p8n86f1N_xYfoPPEyzVXh78gAKAaZ8uoQeSPDg@mail.gmail.com>

2013/5/28 Senthil Kumaran <senthil at uthcode.com>:
>
> On Tue, May 28, 2013 at 7:19 AM, Dirkjan Ochtman <dirkjan at ochtman.nl> wrote:
>>
>> On Tue, May 28, 2013 at 4:11 PM, Senthil Kumaran <senthil at uthcode.com>
>> wrote:
>> > While trying to clone a cpython repo to a new repo. I am getting this
>> > error.
>> >
>> > getting Lib/idlelib/idle.bat
>> > getting Lib/idlelib/idle.py
>> > getting Lib/idlelib/idle.pyw
>> > getting Lib/idlelib/idle_test/@README.txt
>> > abort: data/Lib/idlelib/idle_test/@README.txt.i at 7573717b9e6f: no match
>> > found!
>> >
>> > Is something wrong with the repo?
>>
>> It's possible something broke with the @-filename. Have you tried hg
>> verify yet?
>>
>
> $ hg verify
> repository uses revlog format 1
> checking changesets
> checking manifests
> crosschecking files in changesets and manifests
> checking files
>  data/Lib/idlelib/idle_test/@README.txt.i at 83941: missing revlog!
>  83941: empty or missing Lib/idlelib/idle_test/@README.txt
>  Lib/idlelib/idle_test/@README.txt at 83941: 7573717b9e6f in manifests not
> found
> warning: copy source of 'Modules/_threadmodule.c' not in parents of
> 60ad83716733
> warning: copy source of 'Objects/bytesobject.c' not in parents of
> 64bb1d258322
> warning: copy source of 'Objects/stringobject.c' not in parents of
> 357e268e7c5f
> 9872 files, 83957 changesets, 185453 total revisions
> 3 warnings encountered!
> 3 integrity errors encountered!
> (first damaged changeset appears to be 83941)
>
>
> // All these are from my local repo, which i keep updated. I am cloning from
> hg.python.org to see if this problem persists.

 I think you need to upgrade hg.

--
Regards,
Benjamin

From senthil at uthcode.com  Tue May 28 16:37:19 2013
From: senthil at uthcode.com (Senthil Kumaran)
Date: Tue, 28 May 2013 07:37:19 -0700
Subject: [python-committers] hg clone cpython newrepo aborts
In-Reply-To: <CAPOVWORUoa1ueGWEhSMsAsN4_GK9eWqR4+uHZGgWet8Yzm3DUw@mail.gmail.com>
References: <CAPOVWOSn+Vd73Fgr9h2r7vCGbpN2rvTTAQhBDgKLj-0sYC68OQ@mail.gmail.com>
	<CAKmKYaAYu6vuKs+qn9n6UwvdnBv7uiDvQG72sRXvQrxwnK0SNQ@mail.gmail.com>
	<CAPOVWORUoa1ueGWEhSMsAsN4_GK9eWqR4+uHZGgWet8Yzm3DUw@mail.gmail.com>
Message-ID: <CAPOVWOTbyC6KWXkN1RLwwDEONO8eTmoBL2Aik_GgcjdcgwX1wg@mail.gmail.com>

On Tue, May 28, 2013 at 7:25 AM, Senthil Kumaran <senthil at uthcode.com>wrote:

All these are from my local repo, which i keep updated. I am cloning from
> hg.python.org to see if this problem persists.
>
>
I tried re-cloning from hg.python.org and it works fine. So. it was my
local clone which was corrupted.  Ezio on IRC indicated that it could be
disk problem.
I shall use the new clone.  I had not seen this bad behavior earlier.

Thanks.
Senthil
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-committers/attachments/20130528/2c65b7c6/attachment.html>

From stefan at bytereef.org  Tue May 28 16:34:10 2013
From: stefan at bytereef.org (Stefan Krah)
Date: Tue, 28 May 2013 16:34:10 +0200
Subject: [python-committers] hg clone cpython newrepo aborts
In-Reply-To: <CAPOVWORUoa1ueGWEhSMsAsN4_GK9eWqR4+uHZGgWet8Yzm3DUw@mail.gmail.com>
References: <CAPOVWOSn+Vd73Fgr9h2r7vCGbpN2rvTTAQhBDgKLj-0sYC68OQ@mail.gmail.com>
	<CAKmKYaAYu6vuKs+qn9n6UwvdnBv7uiDvQG72sRXvQrxwnK0SNQ@mail.gmail.com>
	<CAPOVWORUoa1ueGWEhSMsAsN4_GK9eWqR4+uHZGgWet8Yzm3DUw@mail.gmail.com>
Message-ID: <20130528143410.GA20986@sleipnir.bytereef.org>

Senthil Kumaran <senthil at uthcode.com> wrote:
> warning: copy source of 'Modules/_threadmodule.c' not in parents of
> 60ad83716733
> warning: copy source of 'Objects/bytesobject.c' not in parents of 64bb1d258322
> warning: copy source of 'Objects/stringobject.c' not in parents of 357e268e7c5f
> 9872 files, 83957 changesets, 185453 total revisions
> 3 warnings encountered!

The warnings are known and apparently harmless:

http://mail.python.org/pipermail/python-dev/2012-August/121390.html



> ?83941: empty or missing Lib/idlelib/idle_test/@README.txt
> ?Lib/idlelib/idle_test/@README.txt at 83941: 7573717b9e6f in manifests not found
> 3 integrity errors encountered!
> (first damaged changeset appears to be 83941)

This is new though.



Stefan Krah




From solipsis at pitrou.net  Tue May 28 20:10:09 2013
From: solipsis at pitrou.net (Antoine Pitrou)
Date: Tue, 28 May 2013 20:10:09 +0200
Subject: [python-committers] hg clone cpython newrepo aborts
In-Reply-To: <CAPOVWOSn+Vd73Fgr9h2r7vCGbpN2rvTTAQhBDgKLj-0sYC68OQ@mail.gmail.com>
References: <CAPOVWOSn+Vd73Fgr9h2r7vCGbpN2rvTTAQhBDgKLj-0sYC68OQ@mail.gmail.com>
Message-ID: <1369764609.2566.0.camel@fsol>


Hello,

For the sake of safety, I ran "hg verify" on the master repo on
hg.python.org and it turned out fine:

$ hg verify
checking changesets
checking manifests
crosschecking files in changesets and manifests
checking files
9872 files, 83957 changesets, 185454 total revisions


Regards

Antoine.



Le mardi 28 mai 2013 ? 07:11 -0700, Senthil Kumaran a ?crit :
> While trying to clone a cpython repo to a new repo. I am getting this
> error.
> 
> 
> 
> getting Lib/idlelib/idle.bat
> getting Lib/idlelib/idle.py
> getting Lib/idlelib/idle.pyw
> getting Lib/idlelib/idle_test/@README.txt
> abort: data/Lib/idlelib/idle_test/@README.txt.i at 7573717b9e6f: no match
> found!
> 
> 
> Is something wrong with the repo?
> 
> 
> I updated my clone today morning
> 
> 
> [cpython]$ hg pull
> 
> running ssh hg at hg.python.org 'hg -R cpython serve --stdio'
> pulling from ssh://hg at hg.python.org/cpython
> searching for changes
> no changes found
> 
> 
> [cpython]$hg log
> changeset:   83956:ad56dff3602f
> tag:         tip
> parent:      83954:96e543ba96a4
> parent:      83955:b864f4056b78
> user:        Serhiy Storchaka <storchaka at gmail.com>
> date:        Tue May 28 16:27:08 2013 +0300
> files:       Lib/test/test_io.py Misc/NEWS Modules/_io/bufferedio.c
> description:
> Issue #18025: Fixed a segfault in io.BufferedIOBase.readinto() when
> raw
> stream's read() returns more bytes than requested.
> ...
> 
> 
> _______________________________________________
> python-committers mailing list
> python-committers at python.org
> http://mail.python.org/mailman/listinfo/python-committers



From tjreedy at udel.edu  Tue May 28 20:47:09 2013
From: tjreedy at udel.edu (Terry Reedy)
Date: Tue, 28 May 2013 14:47:09 -0400
Subject: [python-committers] hg clone cpython newrepo aborts
In-Reply-To: <CAKmKYaAYu6vuKs+qn9n6UwvdnBv7uiDvQG72sRXvQrxwnK0SNQ@mail.gmail.com>
References: <CAPOVWOSn+Vd73Fgr9h2r7vCGbpN2rvTTAQhBDgKLj-0sYC68OQ@mail.gmail.com>
	<CAKmKYaAYu6vuKs+qn9n6UwvdnBv7uiDvQG72sRXvQrxwnK0SNQ@mail.gmail.com>
Message-ID: <51A4FBAD.4030209@udel.edu>

On 5/28/2013 10:19 AM, Dirkjan Ochtman wrote:
> On Tue, May 28, 2013 at 4:11 PM, Senthil Kumaran <senthil at uthcode.com> wrote:
>> While trying to clone a cpython repo to a new repo. I am getting this error.
>>
>> getting Lib/idlelib/idle.bat
>> getting Lib/idlelib/idle.py
>> getting Lib/idlelib/idle.pyw
>> getting Lib/idlelib/idle_test/@README.txt
>> abort: data/Lib/idlelib/idle_test/@README.txt.i at 7573717b9e6f: no match
>> found!
>>
>> Is something wrong with the repo?
> It's possible something broke with the @-filename.
I am planning to change '@' to '_' anyway.



From ezio.melotti at gmail.com  Tue May 28 22:50:09 2013
From: ezio.melotti at gmail.com (Ezio Melotti)
Date: Tue, 28 May 2013 23:50:09 +0300
Subject: [python-committers] hg clone cpython newrepo aborts
In-Reply-To: <51A4FBAD.4030209@udel.edu>
References: <CAPOVWOSn+Vd73Fgr9h2r7vCGbpN2rvTTAQhBDgKLj-0sYC68OQ@mail.gmail.com>
	<CAKmKYaAYu6vuKs+qn9n6UwvdnBv7uiDvQG72sRXvQrxwnK0SNQ@mail.gmail.com>
	<51A4FBAD.4030209@udel.edu>
Message-ID: <CACBhJdGzb5VuCP=23k48BEjce=nOzxP0xCUZaDfK1+3q5eO==g@mail.gmail.com>

On Tue, May 28, 2013 at 9:47 PM, Terry Reedy <tjreedy at udel.edu> wrote:
> On 5/28/2013 10:19 AM, Dirkjan Ochtman wrote:
>>
>> It's possible something broke with the @-filename.
>
> I am planning to change '@' to '_' anyway.
>

What's wrong with just "README" or "README.txt"?

Best Regards,
Ezio Melotti

From tjreedy at udel.edu  Wed May 29 00:00:49 2013
From: tjreedy at udel.edu (Terry Reedy)
Date: Tue, 28 May 2013 18:00:49 -0400
Subject: [python-committers] hg clone cpython newrepo aborts
In-Reply-To: <CACBhJdGzb5VuCP=23k48BEjce=nOzxP0xCUZaDfK1+3q5eO==g@mail.gmail.com>
References: <CAPOVWOSn+Vd73Fgr9h2r7vCGbpN2rvTTAQhBDgKLj-0sYC68OQ@mail.gmail.com>
	<CAKmKYaAYu6vuKs+qn9n6UwvdnBv7uiDvQG72sRXvQrxwnK0SNQ@mail.gmail.com>
	<51A4FBAD.4030209@udel.edu>
	<CACBhJdGzb5VuCP=23k48BEjce=nOzxP0xCUZaDfK1+3q5eO==g@mail.gmail.com>
Message-ID: <51A52911.4090404@udel.edu>

On 5/28/2013 4:50 PM, Ezio Melotti wrote:
> On Tue, May 28, 2013 at 9:47 PM, Terry Reedy <tjreedy at udel.edu> wrote:
>> On 5/28/2013 10:19 AM, Dirkjan Ochtman wrote:
>>> It's possible something broke with the @-filename.
>> I am planning to change '@' to '_' anyway.
>>
> What's wrong with just "README" or "README.txt"?
>
As I said on the issue and in response to Benjamin's question, I prefer 
to have it appear near the top of the directory listing even when other 
non 'test_xxx' files are added.

From guido at python.org  Wed May 29 01:23:23 2013
From: guido at python.org (Guido van Rossum)
Date: Tue, 28 May 2013 16:23:23 -0700
Subject: [python-committers] hg clone cpython newrepo aborts
In-Reply-To: <51A52911.4090404@udel.edu>
References: <CAPOVWOSn+Vd73Fgr9h2r7vCGbpN2rvTTAQhBDgKLj-0sYC68OQ@mail.gmail.com>
	<CAKmKYaAYu6vuKs+qn9n6UwvdnBv7uiDvQG72sRXvQrxwnK0SNQ@mail.gmail.com>
	<51A4FBAD.4030209@udel.edu>
	<CACBhJdGzb5VuCP=23k48BEjce=nOzxP0xCUZaDfK1+3q5eO==g@mail.gmail.com>
	<51A52911.4090404@udel.edu>
Message-ID: <CAP7+vJJNOVc96zsjUtzCxT8_w8OKGNu1PmUdFOC=Umcc6dV_EA@mail.gmail.com>

On Tue, May 28, 2013 at 3:00 PM, Terry Reedy <tjreedy at udel.edu> wrote:
> As I said on the issue and in response to Benjamin's question, I prefer to
> have it appear near the top of the directory listing even when other non
> 'test_xxx' files are added.

I don't think that's a strong enough reason to give the name a
non-alphabetic prefix. Please just use README.txt.

-- 
--Guido van Rossum (python.org/~guido)

From tjreedy at udel.edu  Wed May 29 01:56:25 2013
From: tjreedy at udel.edu (Terry Reedy)
Date: Tue, 28 May 2013 19:56:25 -0400
Subject: [python-committers] hg clone cpython newrepo aborts
In-Reply-To: <CAP7+vJJNOVc96zsjUtzCxT8_w8OKGNu1PmUdFOC=Umcc6dV_EA@mail.gmail.com>
References: <CAPOVWOSn+Vd73Fgr9h2r7vCGbpN2rvTTAQhBDgKLj-0sYC68OQ@mail.gmail.com>
	<CAKmKYaAYu6vuKs+qn9n6UwvdnBv7uiDvQG72sRXvQrxwnK0SNQ@mail.gmail.com>
	<51A4FBAD.4030209@udel.edu>
	<CACBhJdGzb5VuCP=23k48BEjce=nOzxP0xCUZaDfK1+3q5eO==g@mail.gmail.com>
	<51A52911.4090404@udel.edu>
	<CAP7+vJJNOVc96zsjUtzCxT8_w8OKGNu1PmUdFOC=Umcc6dV_EA@mail.gmail.com>
Message-ID: <51A54429.40202@udel.edu>

On 5/28/2013 7:23 PM, Guido van Rossum wrote:
> On Tue, May 28, 2013 at 3:00 PM, Terry Reedy <tjreedy at udel.edu> wrote:
>> As I said on the issue and in response to Benjamin's question, I prefer to
>> have it appear near the top of the directory listing even when other non
>> 'test_xxx' files are added.
> I don't think that's a strong enough reason to give the name a
> non-alphabetic prefix. Please just use README.txt.
>
As I explained in response to Antoine on pydev, I do not like generic 
README and would prefer a more specific name beginning with 'A'; 
however, I will just delete the '@' in my next patch, which will fix the 
one buildbot breakage.

Terry


From guido at python.org  Wed May 29 02:03:42 2013
From: guido at python.org (Guido van Rossum)
Date: Tue, 28 May 2013 17:03:42 -0700
Subject: [python-committers] hg clone cpython newrepo aborts
In-Reply-To: <51A54429.40202@udel.edu>
References: <CAPOVWOSn+Vd73Fgr9h2r7vCGbpN2rvTTAQhBDgKLj-0sYC68OQ@mail.gmail.com>
	<CAKmKYaAYu6vuKs+qn9n6UwvdnBv7uiDvQG72sRXvQrxwnK0SNQ@mail.gmail.com>
	<51A4FBAD.4030209@udel.edu>
	<CACBhJdGzb5VuCP=23k48BEjce=nOzxP0xCUZaDfK1+3q5eO==g@mail.gmail.com>
	<51A52911.4090404@udel.edu>
	<CAP7+vJJNOVc96zsjUtzCxT8_w8OKGNu1PmUdFOC=Umcc6dV_EA@mail.gmail.com>
	<51A54429.40202@udel.edu>
Message-ID: <CAP7+vJK1pX35_AmrQO99P3YmsAMEwF29hPW_teW3qB5XB5sHrw@mail.gmail.com>

I think we have a zen rule about this: Special cases aren't special
enough to break the rules. (And I know what the next rule is, but I
don't think it applies here. :-)

On Tue, May 28, 2013 at 4:56 PM, Terry Reedy <tjreedy at udel.edu> wrote:
> On 5/28/2013 7:23 PM, Guido van Rossum wrote:
>>
>> On Tue, May 28, 2013 at 3:00 PM, Terry Reedy <tjreedy at udel.edu> wrote:
>>>
>>> As I said on the issue and in response to Benjamin's question, I prefer
>>> to
>>> have it appear near the top of the directory listing even when other non
>>> 'test_xxx' files are added.
>>
>> I don't think that's a strong enough reason to give the name a
>> non-alphabetic prefix. Please just use README.txt.
>>
> As I explained in response to Antoine on pydev, I do not like generic README
> and would prefer a more specific name beginning with 'A'; however, I will
> just delete the '@' in my next patch, which will fix the one buildbot
> breakage.
>
> Terry
>
>
> _______________________________________________
> python-committers mailing list
> python-committers at python.org
> http://mail.python.org/mailman/listinfo/python-committers



-- 
--Guido van Rossum (python.org/~guido)

From senthil at uthcode.com  Wed May 29 14:41:05 2013
From: senthil at uthcode.com (Senthil Kumaran)
Date: Wed, 29 May 2013 05:41:05 -0700
Subject: [python-committers] hg clone cpython newrepo aborts
In-Reply-To: <51A54429.40202@udel.edu>
References: <CAPOVWOSn+Vd73Fgr9h2r7vCGbpN2rvTTAQhBDgKLj-0sYC68OQ@mail.gmail.com>
	<CAKmKYaAYu6vuKs+qn9n6UwvdnBv7uiDvQG72sRXvQrxwnK0SNQ@mail.gmail.com>
	<51A4FBAD.4030209@udel.edu>
	<CACBhJdGzb5VuCP=23k48BEjce=nOzxP0xCUZaDfK1+3q5eO==g@mail.gmail.com>
	<51A52911.4090404@udel.edu>
	<CAP7+vJJNOVc96zsjUtzCxT8_w8OKGNu1PmUdFOC=Umcc6dV_EA@mail.gmail.com>
	<51A54429.40202@udel.edu>
Message-ID: <CAPOVWOQR00goMpbzx05j8ayMhKGOnVgL=eLBDkKFpDc5_74X5w@mail.gmail.com>

On Tue, May 28, 2013 at 4:56 PM, Terry Reedy <tjreedy at udel.edu> wrote:

> On 5/28/2013 7:23 PM, Guido van Rossum wrote:
>
>> On Tue, May 28, 2013 at 3:00 PM, Terry Reedy <tjreedy at udel.edu> wrote:
>>
>>> As I said on the issue and in response to Benjamin's question, I prefer
>>> to
>>> have it appear near the top of the directory listing even when other non
>>> 'test_xxx' files are added.
>>>
>> I don't think that's a strong enough reason to give the name a
>> non-alphabetic prefix. Please just use README.txt.
>>
>>  As I explained in response to Antoine on pydev, I do not like generic
> README and would prefer a more specific name beginning with 'A'; however, I
> will just delete the '@' in my next patch, which will fix the one buildbot
> breakage.
>
>
Thanks for renaming the @README.txt to README.txt

The problem cropped up on my local machine again with repo I checked out
yesterday which had the older file. Specifically due to @ in the filename
(or the way it was added).

hg complained that

data/Lib/idlelib/idle_test/@README.txt.i at 83941: missing revlog!

This is hg (version 2.3.1) on Mac, case sensitive Apple_HFS file system,
throwing up on a recently cloned repo. This may likely be a bug with
mercurial. To deal with this, I am upgraded mercurial to 2.5 and cloned the
repo again.


$ hg verify
repository uses revlog format 1
checking changesets
checking manifests
crosschecking files in changesets and manifests
checking files
 data/Lib/idlelib/idle_test/@README.txt.i at 83941: missing revlog!
 83941: empty or missing Lib/idlelib/idle_test/@README.txt
 Lib/idlelib/idle_test/@README.txt at 83941: 7573717b9e6f in manifests not
found
warning: copy source of 'Modules/_threadmodule.c' not in parents of
60ad83716733
warning: copy source of 'Objects/bytesobject.c' not in parents of
64bb1d258322
warning: copy source of 'Objects/stringobject.c' not in parents of
357e268e7c5f
9872 files, 83957 changesets, 185453 total revisions
3 warnings encountered!
3 integrity errors encountered!
(first damaged changeset appears to be 83941)

$ hg --version
Mercurial Distributed SCM (version 2.3.1)

-- 
Senthil
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-committers/attachments/20130529/fbb21a4e/attachment.html>

From senthil at uthcode.com  Wed May 29 15:11:51 2013
From: senthil at uthcode.com (Senthil Kumaran)
Date: Wed, 29 May 2013 06:11:51 -0700
Subject: [python-committers] 3.2 -> 3.3 merge pending?
Message-ID: <CAPOVWORQWVsmdNHj-2F8QytQLpbkCHVSsdkvgQKLN9riUztb0g@mail.gmail.com>

Is there a merge pending from 3.2 to 3.3?

http://hg.python.org/cpython/graph/83973?revcount=240 shows that last 3.2
change occurred 10 days ago and the branch has not been merged into 3.3 yet.

http://hg.python.org/cpython/rev/b9b521efeba3?revcount=240

Is it pending intentionally or this should be merged and then we go forward
with our business as usual.

-- 
Senthil
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-committers/attachments/20130529/024590a6/attachment.html>

From rdmurray at bitdance.com  Wed May 29 16:41:04 2013
From: rdmurray at bitdance.com (R. David Murray)
Date: Wed, 29 May 2013 10:41:04 -0400
Subject: [python-committers] 3.2 -> 3.3 merge pending?
In-Reply-To: <CAPOVWORQWVsmdNHj-2F8QytQLpbkCHVSsdkvgQKLN9riUztb0g@mail.gmail.com>
References: <CAPOVWORQWVsmdNHj-2F8QytQLpbkCHVSsdkvgQKLN9riUztb0g@mail.gmail.com>
Message-ID: <20130529144104.C20672504B4@webabinitio.net>

On Wed, 29 May 2013 06:11:51 -0700, Senthil Kumaran <senthil at uthcode.com> wrote:
> Is there a merge pending from 3.2 to 3.3?
> 
> http://hg.python.org/cpython/graph/83973?revcount=240 shows that last 3.2
> change occurred 10 days ago and the branch has not been merged into 3.3 yet.
> 
> http://hg.python.org/cpython/rev/b9b521efeba3?revcount=240
> 
> Is it pending intentionally or this should be merged and then we go forward
> with our business as usual.

I asked about this on IRC and was told that 3.2 is now a standalone branch
like 2.7.  Security fixes will be applied by the release manager only,
and Georg doesn't see any point in null merging the commits.

--David

From jcea at jcea.es  Wed May 29 21:41:58 2013
From: jcea at jcea.es (Jesus Cea)
Date: Wed, 29 May 2013 21:41:58 +0200
Subject: [python-committers] 3.2 -> 3.3 merge pending?
In-Reply-To: <20130529144104.C20672504B4@webabinitio.net>
References: <CAPOVWORQWVsmdNHj-2F8QytQLpbkCHVSsdkvgQKLN9riUztb0g@mail.gmail.com>
	<20130529144104.C20672504B4@webabinitio.net>
Message-ID: <51A65A06.4030009@jcea.es>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 29/05/13 16:41, R. David Murray wrote:
> I asked about this on IRC and was told that 3.2 is now a
> standalone branch like 2.7.  Security fixes will be applied by the
> release manager only, and Georg doesn't see any point in null
> merging the commits.

Could this be written somewhere?. For instance, how the release
manager must be notified about a potential relevant changeset for
his/her branch.

- -- 
Jes?s Cea Avi?n                         _/_/      _/_/_/        _/_/_/
jcea at jcea.es - http://www.jcea.es/     _/_/    _/_/  _/_/    _/_/  _/_/
Twitter: @jcea                        _/_/    _/_/          _/_/_/_/_/
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 Thunderbird - http://www.enigmail.net/

iQCVAwUBUaZaBplgi5GaxT1NAQIS+QP/cd7KQ/RFaqK8U9AkMG9RuyoSHVJ9f00t
VuQY+UdzkhomJQez1viEWmP+9c3MMFTHtQFB3mxmZHNHoALUH1ct5DYVjPghkA6h
TsZSfZsCdvU0q9sPEjYXHOgF9LGtQCZgGzqlDl5zHzWTEFXxxLmritiSiZbvFhY/
cvAspNvbnBI=
=iaDN
-----END PGP SIGNATURE-----

From rdmurray at bitdance.com  Wed May 29 21:53:20 2013
From: rdmurray at bitdance.com (R. David Murray)
Date: Wed, 29 May 2013 15:53:20 -0400
Subject: [python-committers] 3.2 -> 3.3 merge pending?
In-Reply-To: <51A65A06.4030009@jcea.es>
References: <CAPOVWORQWVsmdNHj-2F8QytQLpbkCHVSsdkvgQKLN9riUztb0g@mail.gmail.com>
	<20130529144104.C20672504B4@webabinitio.net>
	<51A65A06.4030009@jcea.es>
Message-ID: <20130529195321.41C13250BD3@webabinitio.net>

On Wed, 29 May 2013 21:41:58 +0200, Jesus Cea <jcea at jcea.es> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> On 29/05/13 16:41, R. David Murray wrote:
> > I asked about this on IRC and was told that 3.2 is now a
> > standalone branch like 2.7.  Security fixes will be applied by the
> > release manager only, and Georg doesn't see any point in null
> > merging the commits.
> 
> Could this be written somewhere?. For instance, how the release
> manager must be notified about a potential relevant changeset for
> his/her branch.

By making it a release blocker in the tracker.  (Once it is
public...I would imagine release managers have to be on the
security mailing list...though I don't know that for a fact.)

I imagine there's something in the devguide about security
branches, this info could be added there.

--David

From senthil at uthcode.com  Wed May 29 22:27:02 2013
From: senthil at uthcode.com (Senthil Kumaran)
Date: Wed, 29 May 2013 13:27:02 -0700
Subject: [python-committers] 3.2 -> 3.3 merge pending?
In-Reply-To: <20130529144104.C20672504B4@webabinitio.net>
References: <CAPOVWORQWVsmdNHj-2F8QytQLpbkCHVSsdkvgQKLN9riUztb0g@mail.gmail.com>
	<20130529144104.C20672504B4@webabinitio.net>
Message-ID: <CAPOVWOS8Dod5LZK72D8fp9rdf5NC=+ufRax6Z=KWEJzUPSG1dQ@mail.gmail.com>

On Wed, May 29, 2013 at 7:41 AM, R. David Murray <rdmurray at bitdance.com>wrote:

>
> I asked about this on IRC and was told that 3.2 is now a standalone branch
> like 2.7.  Security fixes will be applied by the release manager only,
> and Georg doesn't see any point in null merging the commits.
>
>
Well, there is no harm in merging 3.2 to 3.3. I think, 3.1 remains merged
to 3.2 even if 3.1 is under security only mode.

It will be our practice that we do not port bug fixes to 3.2. This can be
mentioned in the Misc/README. But when it will be a security fix, it will
go through 3.2->3.3->default and having them merged may be a good idea.

-- 
Senthil
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-committers/attachments/20130529/209da268/attachment-0001.html>

From barry at python.org  Wed May 29 22:40:42 2013
From: barry at python.org (Barry Warsaw)
Date: Wed, 29 May 2013 16:40:42 -0400
Subject: [python-committers] 3.2 -> 3.3 merge pending?
In-Reply-To: <20130529195321.41C13250BD3@webabinitio.net>
References: <CAPOVWORQWVsmdNHj-2F8QytQLpbkCHVSsdkvgQKLN9riUztb0g@mail.gmail.com>
	<20130529144104.C20672504B4@webabinitio.net>
	<51A65A06.4030009@jcea.es>
	<20130529195321.41C13250BD3@webabinitio.net>
Message-ID: <20130529164042.23179c1a@limelight.wooz.org>

On May 29, 2013, at 03:53 PM, R. David Murray wrote:

>By making it a release blocker in the tracker.  (Once it is
>public...I would imagine release managers have to be on the
>security mailing list...though I don't know that for a fact.)

Yes, all release managers for active branches are on the security mailing
list.  (Well, Larry wasn't but is now :).

-Barry