On Wed, Jan 07, 2009 at 10:05:59AM -0500, David Golden wrote: > I think the "problem" is that porters are patching M::B in blead instead of > in the M::B upstream repository, so as M::B development moves forward, the > two sources drift out of sync. The "haiku" line does not appear in the > current M::B trunk (which happens to be the same as the 0.31 release). > > My understanding is that there is discussion of moving more and more modules > to a "dual-life" state and so this kind of coordination will need to > improve.
> Going forward, I would suggest that changes be made upstream to M::B and > then either a release with the changes should be pulled into blead -- or, > worst case, the M::B trunk should be pulled into blead if something can't > wait for a new M::B release. Yes, this is what is supposed to be happening for all dual life modules. The only reason I see as valid for patching something in core (and tweaking the version number in core, and then immediately submitting that change upstream) is because smoke tests are failing, and the change would rectify that. Apart from that, patches sent to p5p that affect dual life modules should be sent upstream without application. (Or the sections of complex patches that affect dual life modules.) Porting/Maintainers makes it easy to determine whether files are part of dual life modules. (Patches welcome for adding functionality to interrogate git to determine which files are modified, akin to the current --opened option for perforce) Nicholas Clark
