Hello. On Wed, 2011-02-09 at 12:30, Khem Raj wrote: > On Wed, Feb 9, 2011 at 2:18 AM, Koen Kooi <[email protected]> wrote: > > On 09-02-11 10:56, Stefan Schmidt wrote: > > > >>> 2. Do not delete the release branch after 2011.03 will be released (just > >>> like > >>> it was done for 2010.12), but let it live and allow developpers > >>> committing > >>> bug-fixes (backporting choosen things?) reported back by OE users > >>> (some would > >>> would be happy to contribute this way) > >> > >> That was already discussed. We make a tag with the release rev from which > >> can be > >> branched again _if_ people are stepping up to support this branch on a mid > >> or > >> long term base. > >> > >> The branch Tom is using until the release is pretty useless froma history > >> point > >> of view (all changes must be in master as well). When he thinks the > >> release is > >> good enough the tag gets added and the old branch deleted. For the last > >> release > >> nobody cared to support it afterwards with bugfixes so no release branch > >> was > >> created. > >> > >> I'm thinking about this for the upcoming release. If all works well we > >> will base > >> a product on it which I would like to support directly from such a release > >> branch. > >> > >> The hard part is how people could decide on pooling resources on this. > >> Defining > >> goals for such a branch and stuff. E.g. only take serious fixes? What about > >> package updates? Security fixes? changes on the toolchain or classes? > >> > > I would suggest to take only bugfixes and refrain from infrastructure > changes which usually > happen metadata wide and toolchain and classes are biggest part of > this and with time backports > into long term branches become more and more complex and painful and > it may be that you have to do > entirely different patch to solve the same issue in this branch which > has been fixed differently upstream
Staying away from infrastructure and toolchain changes is something I really want to see for such a branch. >From my BugLabs side I would expect bug fixes but also some package updates. That would be stuff based on the java/osgi framework we are deploying so hopefully it would not make problems for anyone else. I don't expect to much problems with that. With regards to the lifetime I don't see this as a several years branch fo our product (thinking about oe-core for the next release). Obviously it is still fine for other people to use it that long. The current stable branch is a good example for this. It is still used and different companies/people are happy with it having no updates at all for some time. :) I would expect something else for the branch on top of the 2011-03 release. Some more changes in the begining while fixing problems that poped up after the tag was created but commits will slow down after some months. > I think if such a branch is to be created it should be created from > the release tag after the release happens Agreed. > >> This is up to the group who wants to support such a branch. Anyone else > >> interested in doing this for 2011-03? > > If such a branch is expected for long term then its better to decide > its policies on patches > from upstream pov all fixes that go into this branch should first go > into master if its not > a direct backport of some sort. That way we can be sure that we dont > lose changes that should be in master. Agreed as well. It gets a mess if we start fixing stuff in the release branch only. regards Stefan Schmidt _______________________________________________ Openembedded-devel mailing list [email protected] http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
