[oe] release-2010.12 branch ready for testing

[Khem Raj]

On (19/11/10 15:16), Koen Kooi wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> On 19-11-10 14:46, Tom Rini wrote:
> > On 11/19/2010 03:34 AM, Koen Kooi wrote:
> >> -----BEGIN PGP SIGNED MESSAGE-----
> >> Hash: SHA1
> >>
> >> On 18-11-10 22:27, Khem Raj wrote:
> >>> Hello all,
> >>>
> >>> The work branch for upcoming 2010.12 release has been created.
> >>
> >> Why was this created? We were *very* clear at OEDEM that there would be
> >> no branch, only a tag.
> >>
> >> Why was this changed? I only see some vague handwaving from the TSC
> >> (well, from Phil, saying it was the TSC) who didn't consult the OE
> >> developers at all.
> >>
> >> The whole point of releases was that they are based of a tag from .dev,
> >> not some random branch. Again, why was that changed?

We intend to make releases which works on wider number of platforms, as
we want to keep master open for all kind of commits it can hinder the
release as you also voiced your opposition to let master slow down on commits
too. So we dont have a master which is release quality everyday, we dont
want to wait on commits on master so only way left out is create a
stabilzation branch and release from there. Its clearly mentioned that
this branch is dead after release.

> > 
> > At least for making a release tag exist, if we can't have a freeze on
> > .dev (or otherwise an agreement that .dev should focus on making the
> > testing packages build and work, over new work) making a temporary
> > branch to cherry-pick into seems to be the next possible solution.
> > Otherwise the release tag is just another testing tag...
> 
> Well, that was the whole point. The release is supposed to be only a
> testing tag...
> 
> We were very clear at OEDEM, no *branch* only a tag. If .dev isn't
> working, find a testing tag in the past that does work and use that as a
> release.

thats was because we were not releasing and its also a measure when someone
wants to be close to master but really not on bleeding edge. I am sure
if we have predictable release cycle a lot of users will like to use
the releases thats one reason to get it in good shape.

> 
> It seems people are trying to polarize issues, when they shouldn't. So
> no "freeze .dev", but "pay more attention to .dev" and no "release
> branch" but "encourage getting more green into tinderbox".
> 
> The idea was to get a release out and see how people are using it to
> improve the process and test conditions, not making a kneejerk process
> for this release.
> 
> I've seen no discussion on this list why we need a branch or a freeze
> instead of following the OEDEM plam, only people stating that we need
> it. So what's wrong with the original plan of getting the release out
> and using actual experience as feedback for future releases?
> 

I think if we make a flaky release which is not usable for a bit wider
range of machines/images, it wont do any good to users and not many will use it.
and it will turn out to be a bad experience.
Therefore It should be a bit better than weekly testing IMO. 
If we could have agreed on some sort
of commit holds on master for a week or two, it could have been done as a tag
from master too but there were no concensus on that. May be we would have
improved the process so much next time that we could do the same with much
less time but we did not take that approach.

I am happy to do whatever people want, we need a decision and stick with it and
not waste time and effort by changing directions sometimes its good to disagree and commit to a given approach.

> 
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.5 (Darwin)
> 
> iD8DBQFM5oahMkyGM64RGpERAk1OAJ9Oo6sMLydFi5HYoVQAfQr4AoVVrQCfRd0V
> v06+p6STeoj35fihSo/Lu2I=
> =d9+8
> -----END PGP SIGNATURE-----
> 
> 
> _______________________________________________
> Openembedded-devel mailing list
> Openembedded-devel at lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel