Front page | perl.perl5.porters |
Postings from February 2007
On 2/28/07, Michael G Schwern <schwern@pobox.com> wrote: > 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 wasnt saying that what works for me has to work for anyone else. :-) > I get most of my patches via rt.cpan.org. Well i think that comparing a Win32 module and something ubiquitous like MakeMaker or Test::More is pretty close to comparing apples and oranges. Win32 boxes dont come with development tools so there is a good chance the user base doesnt know about patch or maybe even diff let alone have them installed.The vast majority of windows users are going to get their version of Win32API::File from ActiveState since until blead it wasnt in core. Most of them wont have make let alone a C compiler or patch so they wont be able to install a new version unless its via PPM anyway. So there is an extra layer of eyes involved anyway (the very competent eyes of activestate). > 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). Yes thats fair. But before I backport ill test with at least 5.6 so im personally not so worried about it. > 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. No argument here. Luckily im a pretty active p5p person so its unlikely ill miss stuff. Although in the interest of fairness and disclosure I did totally forget that I was a maintainer of Win32API::File when a recent patch went out (i plead post-GPW flu yerhonner!). But Steve Hay kindly reminded me. Nevertheless I would have at some point snapped out of it reviewed the differences and merged them back to cpan. > 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). > This is well worth thinking about. Yves -- perl -Mre=debug -e "/just|another|perl|hacker/"Thread Previous | Thread Next