On Sat, Sep 24, 2011 at 7:34 PM, Christian Müller <christian.muel...@gmail.com> wrote: > Hello Claus! > > Thank you for your work updating the WIKI page. I didn't know them... >
Yeah there is some good to know wiki pages for Camel team members here http://camel.apache.org/developers.html > But I have to "stress" this topic a bit more, because I still have open > questions: > 1) Is it a problem when different committers use different merge tools (the > Java program, the Python script, simply Git, ...)? Dan already explained. For windows users you may use cygwin or some unix emulator to be able to run the python script. Or maybe adjust the source code in DoMerges.java and have it invoked the windows .exe port of the svnmerge.py. > 2) What is our policy about backporting issues (only bugs, dependency > upgrades for bug fix versions, improvements, new features, dependency > upgrades which are not bug fix versions, ...)? It ought to be bug fixes only, with zero dependency upgrades. However there could be just cause to upgrade a dependency due to a security fix, or very important bug fixes in a dependency. For example Apache CXF has many bugs in recent releases which gets fixed. (eg CXF 2.4.2 have 59 bug fixes - https://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=true&jqlQuery=project+%3D+CXF+AND+fixVersion+%3D+%222.4.2%22+ORDER+BY+issuetype+ASC%2C+key+DESC) At Apache Camel we did that for Camel 2.8.1 release. However the current state of 2.8.2 is unfortunately not following that practice. There seems to be backported *too* many commits. For example the state of 2.8.2, even include commits which was *deliberately* omitted for the 2.8.1. Granted the svnmerge.py should possible have some of those tickets set as "blocked". But the commits was done without any prior heads-up. The offset ought to have started from 2.8.1 release and then the changes since. But the offset was started from the Camel 2.8.0 release, and thus includes commits which we * deliberately* omitted in Camel 2.8.1. The Karaf team seems to have a better practice, by discussing on the @dev which tickets to backport (especially if non-bug tickets). We the Camel team ought to follow their example IMHO, and also discuss which tickets to backport. Especially for non-bug tickets. Likewise I don't believe there is one uber-person (that would include me as that uber-person, in case you wonder) who should sit and backport a batch of commits. Its the duty of all of us to backport tickets. In fact I think its primary the persons who actually worked on the tickets, at the given time, is the best person to judge if the ticket is "safe" to backport. But having a weekly/semi-weekly procedure of discussing and backport any "left overs" is a good idea. Then we ensure that the maintenance branches is not becoming doormat and we have a repeatable procedure in place, that the community can rely upon. And they over time get familiar with. If they keep an eye on the commit logs / JIRA - they see the progress and that tickets get backport in timely manner. There are possible a rare number of people who may even try out SNAPSHOT versions of maintenance branches. So it would help if tickets is back ported on a regularly basis. We may also consider adding some note/field in JIRA if a ticket is "not safe" to backport. Sometimes you work on a bug/improvement that is just too complicated/or too big/risk of introducing side effects/or rely upon other improvements/new features etc. that its not feasible to backport. For example if we have a known work-around it could be better to notice the workaround in the release notes for that given release. > 3) Still not clear why we backport many issues to 2.8.2 and not to 2.7.4. > > I stess this to make it clear for everybody, document it and to provide a > better mentoring for new committers. > > Christian > > Sent from a mobile device > -- Claus Ibsen ----------------- FuseSource Email: cib...@fusesource.com Web: http://fusesource.com Twitter: davsclaus, fusenews Blog: http://davsclaus.blogspot.com/ Author of Camel in Action: http://www.manning.com/ibsen/
