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 <
[hidden email]> 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" <
[hidden email]>
> >>> seems there are commits that are fixing the trunk for might be
> >>> applicable to ver 4.0
> >>>
> >>> is there a review process for this?
> >>>
> >>
> >
>
>
Locked
smime.p7s (3K)