Front page | perl.perl5.porters |
Postings from November 2014
Cherry-picking for Perl 5.20.2
Thread Next
From:
Steve Hay
Date:
November 29, 2014 17:50
Subject:
Cherry-picking for Perl 5.20.2
Message ID:
CADED=K6t9c0VJLgOM-EyTTZ3spOYXa3_sy8gMkFCHXCAvz36AA@mail.gmail.com
Perl 5.20.2 is slated for a January release, and I will shortly start
cherry-picking commits into maint-5.20 in preparation for it.
There was some discussion back in September about how best to manage
the voting for cherry-picks. I've responded to the last message from
that thread below, my conclusion being that a plain text file (*)
dropped into Porting/ is probably the simplest solution for now. More
details to follow when I've started compiling a list of cherry-pick
proposals to fill it up with...
(*) or maybe a simple HTML file so that it can have clickable links
for easily viewing the proposed commits.
On 8 September 2014 at 07:21, Rafael Garcia-Suarez <rgs@consttype.org> wrote:
> On 8 September 2014 01:59, Ricardo Signes <perl.p5p@rjbs.manxome.org> wrote:
>> * Steve Hay <steve.m.hay@googlemail.com> [2014-09-07T10:29:03]
>>> For 5.20.2 I would like to try to find some better way of managing
>>> this. Some years ago people used a program called cherrymaint intended
>>> to make this process more manageable. It's still there
>>> (Porting/cherrymaint), but I don't think I ever used it or know
>>> exactly how it works (if it still does).
>>>
>>> Does anyone recall why it seems to have fallen into disuse?
>>
>> My recollection was that there were two main problems. Note: my recollection
>> is not always the best thing.
>>
>> 1. it was made for "one maint branch exists," but now we have two
>> 2. it didn't make it easy to say "I've reviewed this commit, never list it
>> again"
>
> Those can be fixed. We had also scalability issues with lots of commits IIRC
>
> See also: https://github.com/rgs/cherrymaint
This looks interesting, but unfortunately I can add another problem to
the list: It currently doesn't want to play ball on Windows :-/
I changed the config.yml file to:
layout: "main"
logger: "file"
template: template_toolkit
gitpath: "C:/PROGRA~2/Git/bin/git.exe"
gitroot: "C:/Dev/Git/perl"
datafile: "~/cherrymaint.db"
lock: "~/cherrymaint.lock"
# branches : maintenance track name -> range [ start tag, end head ]
branches:
"maint-5.20":
- "v5.20.1"
- blead
"maint-5.18":
- "v5.18.4"
- "maint-5.20"
testing: 0
but when I run "perl cherrymaint.pl" it outputs this (after fighting
with Socket to give it an inet_ntop() implementation on Windows; see
CPAN RT#84600...):
Smartmatch is experimental at cherrymaint.pm line 27.
>> Dancer 1.3132 server 19632 listening on http://0.0.0.0:3000
== Entering the development dance floor ...
The IP address doesn't quite look right there (!), but it does respond
on http://127.0.0.1:3000/ ... but only to say "Internal Server Error"
:-(
I think I will probably go with Father C's idea of a simple plain text
file dropped into Porting/ for now, but I would still be interested to
see this GitHub cherrymaint dancing and may switch over to it later if
it does work out.
>
>> 3. it was only at the commit level, which made it difficult to know how things
>> would need to be picked and applied, and we too often ended up with
>> conflicts or failures to apply
>>
>> So I guess that's three.
>>
>> As I recall, Rafael did do work to address some of this, but #3 was such a
>> problem that I said I didn't see myself likely to use anything that didn't
>> really address that.
>
> #3 is more complex to address. We don't really have that kind of
> meta-information
> (because no topic branches) and related commits can be separated by days or
> weeks, making them hard to locate. I don't find an easy, low-overhead way to
> integrate this with the current workflow...
I don't have any good solution to that problem either, but I think we
can probably live without it given the conservative nature of commits
that go into maint now.
In the more distant past virtually everything that didn't break binary
compatibility used to get integrated, which must have required great
efforts to keep track of which commits depended on which other
commits, but now that we mostly just cherry-pick isolated bug fixes
and documentation patches I think there is less need for tracking such
dependencies. It certainly didn't seem to arise as an issue during the
release of 5.20.1 anyway.
Thread Next
-
Cherry-picking for Perl 5.20.2
by Steve Hay