2009/1/7 Nicholas Clark <n...@ccl4.org>: > 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.
I thought we agreed that it was ok to have to modules where blead leads? See the thing is, I would much rather have blead people apply commits to ExtUtils::Install and then I will occasionally update the dist and roll a new official release and also roll an update release for blead. I dont want people to have to wait on me if they can sort things in blead. > 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) You want `git status`, and then from there you move on to git diff with or without the --cache option. Alternatively you can just use git commit --interactive and do the whole thing interactively with a command line interface to control things. Use 'quit' to end the interactive session and create a commit. cheers, yves -- perl -Mre=debug -e "/just|another|perl|hacker/"
