2009/1/8 David Golden <[email protected]>:
> On Thu, Jan 8, 2009 at 9:12 AM, Rafael Garcia-Suarez
> <[email protected]> wrote:
>>
>> That patch steps over the changes below to Build.pm :
>>
>> commit e5c8c22050be81fb2e880f0c7a2fcbe5496ab5d7
>> Author: Rafael Garcia-Suarez <[email protected]>
>> Date: Mon Jan 5 10:47:45 2009 +0100
>>
>> Bump two module versions after Haiku port
>>
>> CPANPLUS and Module::Build
>> (see df00ff3beeb297b9622f8acbed9c80d320c87580)
>>
>> commit df00ff3beeb297b9622f8acbed9c80d320c87580
>> Author: Ingo Weinhold <[email protected]>
>> Date: Wed Oct 29 03:25:44 2008 +0100
>>
>> Haiku Port
>> Message-Id: <[email protected]>
>>
>> p4raw-id: //depot/p...@34630
>
> These have been addressed in the later patch that I sent, I believe.
I have still a patch backlog, so I need to look at the more recent
patches... sorry for the noise
>> In short I'd really appreciate that the Module::Build team integrates
>> the bleadperl changes before some more forkage happens. Putting
>> module-build@ in CC: for that.
>
> Did the bleadperl team send patches to the module-build when they happened?
> I don't recall. If not, that would have made it much easier to manage
> rather than having to now figure out where everything diverged. If so, then
> I suppose it's our bad for not applying the patches.
I do send patches; I don't whether other committers do, but they should.
Would cc:ing the RT CPAN queue be helpful ?
>> So, let's discuss a bit about that. The patches mentioned above are :
>> * parts of big porting patches
>> * specific to building within the core
>> * or small portability nits
>> That is to say, it makes sense for them to be applied to bleadperl,
>> because either they un-break bleadperl on some platforms, or make it
>> possible to build bleadperl on some new platforms. We can't stall
>> bleadperl development waiting for a new release of Module::Build to
>> hit the CPAN.
>
> I don't think bleadperl should stall for a release, but at the same time,
> it's easier if changes are kept upstream and pulled into blead from the M::B
> trunk or from a maintenance branch. There are now a number of people
> besides Ken with commit bits (Randy, Schwern, Eric, me, others?), so
> incorporating patches should be fairly easy.
Without a mechanism to merge patches between blead and MB, it's better
to always apply patches only to one side, yes.
>> However, since we have git now, it would make absolute sense to have
>> the Module::Build team maintain a branch, either on perl's main repo,
>> or on github, or somewhere else, from which I can merge the changes to
>> M::B, and to which the M::B team can merge the bleadperl changes.
>
> If blead incorporated the entirety of the M::B distribution, I'd be more
> comfortable with the idea of using a git branch and going back and forth,
> but since blead has a different layout ("t/" and "scripts/" under
> "lib/Module/Build") the diffs need to be applied file-by-file, not against
> the entire tree, so it's manual work no matter what.
The layout is a problem. There is some plan for bleadperl to move as
many modules as possible under ext/, so the layout of the CPAN
distribution is completely respected.
> Instead, maybe you should get a commit bit to the M::B repository on
> svn.perl.org and make changes there. The work I've done on add-packages.pl
> makes it fairly easy to bring in an M::B update to the perl git repo:
>
> * Patch M::B on svn.perl.org -- either trunk or branched from some stable
> release point
> * Run "Build distdir" -- to autogenerate some documentation
> * cd into the distdir and run "$perl_repo/Porting/add-packages.pl -r
> $perl_repo"
> * cd into the perl repo, examine the changes made in the new branch and
> commit if it looks good
>
> That would keep the patches flowing from upstream to blead fairly smoothly,
> I think.
I need to look at the recent changes to add-packages. Your proposed
workflow is a definite improvement upon the current situation. And my
user id on svn.perl.org is 'rafael'.
>> Before that happens, I'm reluctant to touch to blead's M::B version at
>> all.
>
> I've already patched M::B's trunk to address a couple of the changes in
> blead. If you can help me with tips on how to grep other differences out of
> the perl git logs, I'll try to sync it up and do yet another integration
> patch. (My spirit is willing, but my git-fu is weak.)
I mostly use "git log --stat <paths>".
