Front page | perl.perl5.porters |
Postings from February 2007
demerphq wrote:
>> Perhaps this is how it actually plays out most of the time, but
>> Porting/Contract has a very different take. In the case under
>> consideration, Win32API::File, removing the indirect object syntax
>> seemed to me something better done by way of the module owner(s)
>> rather than in bleadperl.
>
> I am one of the maintainers, and I would rather backport blead changes
> than the other way around. More peopl eare likely to test and patch
> the blead version than the cpan version (just due to self-selection,
> people on p5p are highly likely to be inclined to post patches, and
> Ill see them there.)
My experience with MakeMaker and Test::More have been the other way around.
I get most of my patches via rt.cpan.org.
I also don't want to have to backport blead changes especially if I try to
maintain backwards compat further back than 5.8. I'd rather the patches
were written in the first place with compatibility in mind then having to
backport it (with the possibility that it cannot be back ported).
And then blead has to be repatched with the backported version and the
inevitable conflicts which will make the merger's life more difficult.
Finally, now as a CPAN author I have to track changes in bleadperl to look
for changes in my module. In inevitably miss some. Now the person merging
my CPAN version into bleadperl must be diligent and make sure I didn't miss
and possibly revert a fix in bleadperl.
That said, it would be nice if bleadperl treated CPAN modules like you would
any other vendor code out of your control. That being you have a "vendor"
branch for each dual-lifed module. Then you have a local branch of that.
You patch up the local branch. The code in the local branch is what gets
merged into the trunk. When a new version is released on CPAN it is
committed to the vendor branch and the changes pulled into and merged with
the local branch. A diff between the vendor and local branch continues to
show where the local and vendor versions are different. You can look
through the log of the local branch and compare with the vendor changes file
to see what has and has not been accepted. I, as the author, can look at
your local branch of my module to find the changes. You can even set up
automatic emails to the author for each change.
And most of the problems with dual-lifed modules just goes away.
This is standard issue vendor branching, I do it all the time when I patch
CPAN code. I even do it with bleadperl since the repository is so damned
hard to get at. And decent, modern version control system supports it. In
SVK its just...
cd CPAN-Module-0.11
svk import //vendor/CPAN-Module -m 'CPAN-Module 0.11 from CPAN'
svk cp //vendor/CPAN-Module //local/CPAN-Module -m 'Local copy'
svk co //local/CPAN-Module ~/work/CPAN-Module
If a new version of CPAN-Module comes out its...
cd CPAN-Module-0.12
svk import //vendor/CPAN-Module -m 'CPAN-Module 0.12 from CPAN'
cd ~/work/CPAN-Module
svk pull
I'm sure git has something similar. Perforce and CVS not so much.
Subversion has various hacks to work around its lack of good branch
management (svnmerge).
Thread Previous
|
Thread Next