PATCH: clarify where to patch against

--envbJBWh7q8WU6mo
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline

Talking about Perl 5 git repo tonight, some questions came up about where
development really happens.  This patch is a bit of clarification about
where/why patches go to blead/maint.
-- 
rjbs
--envbJBWh7q8WU6mo
Content-Type: text/x-diff; charset=us-ascii
Content-Disposition: attachment; filename="0001-very-minor-tweaks-to-description-of-maint-blead.patch"
From 1b7ad6bc0c93abd2d9fad847e8449824e529ba24 Mon Sep 17 00:00:00 2001
From: Ricardo SIGNES <rjbs@cpan.org>
Date: Wed, 22 Jul 2009 22:29:10 -0700
Subject: [PATCH] very minor tweaks to description of maint/blead
---
 pod/perlrepository.pod |   17 ++++++++++-------
 1 files changed, 10 insertions(+), 7 deletions(-)
diff --git a/pod/perlrepository.pod b/pod/perlrepository.pod
index f961acf..97080d4 100644
--- a/pod/perlrepository.pod
+++ b/pod/perlrepository.pod
@@ -15,9 +15,9 @@ system we were using previously. This repository is accessible in
 different ways.
 
 The full repository takes up about 80MB of disk space. A check out of
-the blead branch (that is, the master branch, which contains bleadperl,
-the development version of perl 5) takes up about 160MB of disk space
-(including the repository). A build of bleadperl takes up about 200MB
+the blead branch (that is, the main development branch, which contains
+bleadperl, the development version of perl 5) takes up about 160MB of disk
+space (including the repository). A build of bleadperl takes up about 200MB
 (including the repository and the check out).
 
 =head1 GETTING ACCESS TO THE REPOSITORY
@@ -256,10 +256,11 @@ that you're on the I<blead> branch, and your repository is up to date:
   % git checkout blead
   % git pull
 
-(It's preferable to patch against the latest blead version, since
-patches are usually integrated from blead to the maintenance branches.
-This does not apply, obviously, in the rare case where your patch is
-specific to a maintaince release.)
+It's preferable to patch against the latest blead version, since
+this is where new development occurs for all changes other than critical
+bug fixes.  Critical bug fix patches should be made against the relevant
+maint branches, or should be submitted with a note indicating all the
+branches where the fix should be applied.
 
 Now that we have everything up to date, we need to create a temporary
 new branch for these changes and switch into it:
@@ -665,6 +666,8 @@ And then push back to the repository:
 
 =head1 COMMITTING TO MAINTENANCE VERSIONS
 
+Maintenance versions should only be altered to add critical bug fixes.
+
 To commit to a maintenance version of perl, you need to create a local
 tracking branch:
 
-- 
1.6.3.1

--envbJBWh7q8WU6mo--
0
perl
7/23/2009 5:58:51 AM
📁 perl.perl5.porters
📃 48287 articles.
⭐ 1 followers.

💬 7 Replies
👁️‍🗨️ 737 Views


On Thu, Jul 23, 2009 at 12:58 AM, Ricardo
SIGNES<perl.p5p@rjbs.manxome.org> wrote:
>
> Talking about Perl 5 git repo tonight, some questions came up about where
> development really happens. =A0This patch is a bit of clarification about
> where/why patches go to blead/maint.
>
> --
I'm not entirely sure about this patch.  Rarely should a patch ever be
applied directly to maint without hitting blead first.  I can only
think of one case where I had a patch applied to maint only and that
was due to API differences between blead and maint.  I'd rather that
patches be pointed at blead than at maint without being directed by
the appropriate pumpking.
Steve Peters
steve@fisharerojo.org
0
steve
7/23/2009 1:17:00 PM
2009/7/23 Steve Peters <steve@fisharerojo.org>:
> On Thu, Jul 23, 2009 at 12:58 AM, Ricardo
> SIGNES<perl.p5p@rjbs.manxome.org> wrote:
>>
>> Talking about Perl 5 git repo tonight, some questions came up about wher=
e
>> development really happens. =A0This patch is a bit of clarification abou=
t
>> where/why patches go to blead/maint.
>>
>> --
>
> I'm not entirely sure about this patch. =A0Rarely should a patch ever be
> applied directly to maint without hitting blead first. =A0I can only
> think of one case where I had a patch applied to maint only and that
> was due to API differences between blead and maint. =A0I'd rather that
> patches be pointed at blead than at maint without being directed by
> the appropriate pumpking.
Chip has already applied it, although with another commit message,
with a workflow leak somehow:
http://perl5.git.perl.org/perl.git/commitdiff/7f4ffa9dba4691a2cd3285cfb3fd7=
6f6f6bd661
0
rgarciasuarez
7/23/2009 1:36:16 PM
On Thu, Jul 23, 2009 at 8:36 AM, Rafael
Garcia-Suarez<rgarciasuarez@gmail.com> wrote:
> 2009/7/23 Steve Peters <steve@fisharerojo.org>:
>> On Thu, Jul 23, 2009 at 12:58 AM, Ricardo
>> SIGNES<perl.p5p@rjbs.manxome.org> wrote:
>>>
>>> Talking about Perl 5 git repo tonight, some questions came up about whe=
re
>>> development really happens. =A0This patch is a bit of clarification abo=
ut
>>> where/why patches go to blead/maint.
>>>
>>> --
>>
>> I'm not entirely sure about this patch. =A0Rarely should a patch ever be
>> applied directly to maint without hitting blead first. =A0I can only
>> think of one case where I had a patch applied to maint only and that
>> was due to API differences between blead and maint. =A0I'd rather that
>> patches be pointed at blead than at maint without being directed by
>> the appropriate pumpking.
>
> Chip has already applied it, although with another commit message,
> with a workflow leak somehow:
> http://perl5.git.perl.org/perl.git/commitdiff/7f4ffa9dba4691a2cd3285cfb3f=
d76f6f6bd661
>
Maybe Ricardo and/or Chip can fill us in on the conversation that led
to this patch.  It certainly is not an accurate description of current
practice.  Particularly the statement, "Maintenance versions should
only be altered to add critical bug fixes," is a pretty radical change
and raises more questions than it answers (such as what constitutes
"critical").  Even if that's a release workflow we can or should get
to, it's a long way from here to there and at the very least the doc
patch is more predictive than descriptive.
0
craig
7/23/2009 4:29:26 PM
On Thu, Jul 23, 2009 at 11:29:26AM -0500, Craig A. Berry wrote:
> Maybe Ricardo and/or Chip can fill us in on the conversation that led to
> this patch.
Our develoment resources and enthusiasms are diffused between blead and
maint, mostly because of the incredibly long blead release cycle; anyone who
wants to see something new and therefore pushes for inclusion in maint has
been making s rational choice (until now).  More development emphasis on
blead, and an increase blead release frequency, will fix this problem; it
will be good for the project, and will happen.  This emphasis is, of
necessity, at the expense of backporting non-critical patches into maint.
I don't imagine Dave would disagree that maint is pulling in too much stuff.
$DEITY, after the delay on 5.10.1, a person could be forgiven for wishing
for a separate "critical-maint" branch.  And that's just nuts.
Of course the adjective "critical" is imprecise, because it's human natural
language.  As always patches will be considered on their individual merits.
-- 
Chip Salzenberg
0
chip
7/23/2009 4:59:18 PM
On Thu, Jul 23, 2009 at 09:59:18AM -0700, Chip Salzenberg wrote:
> I don't imagine Dave would disagree that maint is pulling in too much stuff.
> $DEITY, after the delay on 5.10.1, a person could be forgiven for wishing
> for a separate "critical-maint" branch.  And that's just nuts.
What Dave actually thinks is that he'd like to have a good long discussion
about this once 5.10.1 is out of the door, rather than being railroaded
into going along with some hasty decisions made by a few "unelected"
people at OSCON last night, who came to the conclusion that by ignoring
most issues, they have solved them.
-- 
That he said that that that that is is is debatable, is debatable.
0
davem
7/23/2009 6:17:16 PM
On Thu, Jul 23, 2009 at 07:17:16PM +0100, Dave Mitchell wrote:
> On Thu, Jul 23, 2009 at 09:59:18AM -0700, Chip Salzenberg wrote:
> > I don't imagine Dave would disagree that maint is pulling in too much stuff.
> > $DEITY, after the delay on 5.10.1, a person could be forgiven for wishing
> > for a separate "critical-maint" branch.  And that's just nuts.
> 
> What Dave actually thinks is that he'd like to have a good long discussion
> about this once 5.10.1 is out of the door ...
Fair enough; consider the question of your opinion on this tabled.
For my part, I've tested the 5.10.1 snapshot (successfully) with some
DarkPAN code, and will attempt to resolve some of
  http://rt.perl.org/rt3//Public/Search/Simple.html?Query=MemberOf%3D66092+and+status!=%27resolved%27
which is a list of 5.10 bugs any core hacker would do well to look at.
-- 
Chip Salzenberg
0
chip
7/23/2009 6:23:57 PM
On Jul 23, 2009, at 11:17 AM, Dave Mitchell wrote:
> What Dave actually thinks is that he'd like to have a good long  
> discussion
> about this once 5.10.1 is out of the door, rather than being  
> railroaded
> into going along with some hasty decisions made by a few "unelected"
> people at OSCON last night, who came to the conclusion that by  
> ignoring
> most issues, they have solved them.
I think that might be overstating what conclusions we came to, but it  
would definitely be worthwhile to have that good, long discussion  
after 5.10.1 ships.
Best,
David
0
david
7/23/2009 7:26:17 PM
Reply: