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. 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? > >>> > >> > > > >
