De : "Scott Gray" <[EMAIL PROTECTED]> > If anyone sees me commit a fix to the trunk that they think might be > applicable to the release branch they're welcome to ask and I'm more > than happy to provide details on how to replicate the bug. > > They can then see if the bug exists, merge the commit, test the > results and then perhaps create a jira issue with the merged patch. > > I just don't have the time, when I find a bug I want to fix it and > move on. But applying to the release branch involves opening up my > release version, doing an update, ant-clean, ant, check if the bug > exists, attempt to merge the patch, possibly another ant, test the > results and then be supremely confident that I didn't break anything > else :-) before I can commit it. > > It would also be a great way for relative newbies to build up > experience with different parts of the system while giving something > back to the community.
Wonderful world again Jacques > Regards > Scott > > On 15/11/2007, Jonathon -- Improov <[EMAIL PROTECTED]> wrote: > > If I understand correctly, I think David is right that it's quite alright > > to miss fixes to trunk > > and not have them applied to release branches. Better safe than sorry. Many > > of us (definitely me) > > rely heavily on the release branch being "frozen", ie no new bugs > > introduced. It's easier to tell > > my clients that "we've just encountered an old bug in release version, > > fixed it, and made release > > version more stable", than to tell them that "it's a new problem, don't > > know if more new problems > > will pop in later". > > > > I shudder at clients' comments like "it worked before, now it's broken". > > Huge confidence killer. > > > > If the release branch gets a bug report, and a subsequent bug fix, then > > that bug fix can directly > > be applied to the release branch. A bug fix for trunk will need extra > > reviews and processing to be > > applied to release branch. > > > > Personally, I think it's ok to have duplicate bug reports, one copy for > > trunk and one copy for > > release branch, long as the duplicates were unintentional. If someone > > happens to spot a bug that > > is *exactly* similar between trunk and release, and submits a single bug > > report, great. If not, > > it's alright that 2 or more folks submit duplicate bug reports > > unintentionally, since we can still > > relate the duplicates to each other. > > > > I think the release branch is getting quite stable now. I'll know better in > > 3 months' time! That's > > when I start my attempt to comprehensively document every > > above-the-framework framework > > (ERP-related "framework"). > > > > But Jacques is also right that the bug reporter will know better if his/her > > bug fix can be applied > > to both branches. Still, if the bug reporter doesn't have time to test the > > bug fix in the release > > branch, that's still alright. The folks who discover bugs in the release > > branch will still search > > for bug fixes in JIRA, and may try out bug fixes applied to trunk. > > > > Maybe David didn't want to say this outright, but here's what I understand. > > :P Those of us who > > feel that there are bug fixes to trunk that may be applicable to release, > > we should test those bug > > fixes on release, and then report to the committers the ones that are > > tested to be applicable. I > > may do just that systematically come December 2007. > > > > Jonathon > > > > David E Jones wrote: > > > > > > It doesn't matter too much who does it, but it is important to > > > distinguish between bugs and new features (that may introduce new > > > bugs...). > > > > > > Still, as I've said before, what the release branch REALLY needs is bug > > > reports and testing so that it can stabilize and achieve a certain level > > > of confidence. > > > > > > -David > > > > > > > > > On Nov 14, 2007, at 7:24 AM, Jacques Le Roux wrote: > > > > > >> I did it for a while. It's a delicate process has sometimes fixes are > > >> done over changes not in release4.0. So it's better than every > > >> commiter deals with his own commits > > >> > > >> Jacques > > >> > > >> De : "BJ Freeman" <[EMAIL PROTECTED]> > > >>> seems there are commits that are fixing the trunk for might be > > >>> applicable to ver 4.0 > > >>> > > >>> is there a review process for this? > > >>> > > >> > > > > > > > >
