Preparing for release - Freeze on master

Preparing for release - Freeze on master

[Khem Raj]

Hello All,

In order to get to the 2010.12 release, I would like to request to
stop pushing any changes to master until release. Please keep your
changes in you local tree ready for when the window
opens again after the release. Any bugfixes (and only bugfixes) that
are required for the release are ok to push after approval on mailing
list.

Please help in testing various combinations to make this release a
robust one. You should report the test results to the testing matrix
on wiki. More combinations we test better it is.
Report any bugs to the mailing list or even better if they come with fixes.

Lets make this release a success!

Thank you for your cooperation

-Khem

Re: Preparing for release - Freeze on master

[Paul Menzel]

[-- Attachment #1: Type: text/plain, Size: 634 bytes --]

Dear OE folks,


Am Dienstag, den 16.11.2010, 10:20 -0800 schrieb Khem Raj:

> In order to get to the 2010.12 release, I would like to request to
> stop pushing any changes to master until release. Please keep your
> changes in you local tree ready for when the window
> opens again after the release.

would it be a good idea, to either have each developer with commit
access create his/her own “next” branch or to have a common next branch,
where those changes could be published, so that work is not duplicated?

[…]


Thanks,

Paul


PS: Khem, thanks for taking the lead in getting this release done!

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 205 bytes --]

Re: Preparing for release - Freeze on master

[Khem Raj]

On Tue, Nov 16, 2010 at 2:39 PM, Paul Menzel
<paulepanter@users.sourceforge.net> wrote:
> Dear OE folks,
>
>
> Am Dienstag, den 16.11.2010, 10:20 -0800 schrieb Khem Raj:
>
>> In order to get to the 2010.12 release, I would like to request to
>> stop pushing any changes to master until release. Please keep your
>> changes in you local tree ready for when the window
>> opens again after the release.
>
> would it be a good idea, to either have each developer with commit
> access create his/her own “next” branch or to have a common next branch,
> where those changes could be published, so that work is not duplicated?
>

Either way is fine. If its posted to mailing list then it goes to
patchwork and after approvals I will sweep them
if devs publish a pull branch thats ok too.

> […]
>
>
> Thanks,
>
> Paul
>
>
> PS: Khem, thanks for taking the lead in getting this release done!
>
> _______________________________________________
> Openembedded-devel mailing list
> Openembedded-devel@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
>
>

Re: Preparing for release - Freeze on master

[Frans Meulenbroeks]

2010/11/16 Khem Raj <raj.khem@gmail.com>:
> On Tue, Nov 16, 2010 at 2:39 PM, Paul Menzel
> <paulepanter@users.sourceforge.net> wrote:
>> Dear OE folks,
>>
>>
>> Am Dienstag, den 16.11.2010, 10:20 -0800 schrieb Khem Raj:
>>
>>> In order to get to the 2010.12 release, I would like to request to
>>> stop pushing any changes to master until release. Please keep your
>>> changes in you local tree ready for when the window
>>> opens again after the release.
>>
>> would it be a good idea, to either have each developer with commit
>> access create his/her own “next” branch or to have a common next branch,
>> where those changes could be published, so that work is not duplicated?
>>
>
> Either way is fine. If its posted to mailing list then it goes to
> patchwork and after approvals I will sweep them
> if devs publish a pull branch thats ok too.
>
>> […]
>>
>>
>> Thanks,
>>
>> Paul
>>
>>
>> PS: Khem, thanks for taking the lead in getting this release done!
>>
>> _______________________________________________

What about new recipes?
I have a few new tasks and a new image that I was planning to add
tonight, but didn't get to it.
Also I will have a working uclibc++ recipe by tomorrow or so. (the
current one does not build for me).
I feel changes like those are pretty harmless.

Frans

Re: Preparing for release - Freeze on master

[Khem Raj]

On Tue, Nov 16, 2010 at 2:52 PM, Frans Meulenbroeks
<fransmeulenbroeks@gmail.com> wrote:
> 2010/11/16 Khem Raj <raj.khem@gmail.com>:
>> On Tue, Nov 16, 2010 at 2:39 PM, Paul Menzel
>> <paulepanter@users.sourceforge.net> wrote:
>>> Dear OE folks,
>>>
>>>
>>> Am Dienstag, den 16.11.2010, 10:20 -0800 schrieb Khem Raj:
>>>
>>>> In order to get to the 2010.12 release, I would like to request to
>>>> stop pushing any changes to master until release. Please keep your
>>>> changes in you local tree ready for when the window
>>>> opens again after the release.
>>>
>>> would it be a good idea, to either have each developer with commit
>>> access create his/her own “next” branch or to have a common next branch,
>>> where those changes could be published, so that work is not duplicated?
>>>
>>
>> Either way is fine. If its posted to mailing list then it goes to
>> patchwork and after approvals I will sweep them
>> if devs publish a pull branch thats ok too.
>>
>>> […]
>>>
>>>
>>> Thanks,
>>>
>>> Paul
>>>
>>>
>>> PS: Khem, thanks for taking the lead in getting this release done!
>>>
>>> _______________________________________________
>
> What about new recipes?

Depending upon how they pan out. Suppose if you add a new recipe for a
working recipe
that has implications if it gets picked up by default so need to make
sure it works on tested sets.
some entirely new recipes should be ok recipes for version upgrade
need to be watched out

> I have a few new tasks and a new image that I was planning to add
> tonight, but didn't get to it.

post them if you think they make sense in release and do not involve
other meta recipes.

> Also I will have a working uclibc++ recipe by tomorrow or so. (the
> current one does not build for me).

Post them to ml.

> I feel changes like those are pretty harmless.
>
> Frans
>
> _______________________________________________
> Openembedded-devel mailing list
> Openembedded-devel@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
>

Re: Preparing for release - Freeze on master

[Frans Meulenbroeks]

2010/11/17 Khem Raj <raj.khem@gmail.com>:


>> What about new recipes?
>
> Depending upon how they pan out. Suppose if you add a new recipe for a
> working recipe
> that has implications if it gets picked up by default so need to make
> sure it works on tested sets.
> some entirely new recipes should be ok recipes for version upgrade
> need to be watched out

I agree on that. Actually I was referring to really new recipes, not
new versions of an existing recipe.
>
>> I have a few new tasks and a new image that I was planning to add
>> tonight, but didn't get to it.
>
> post them if you think they make sense in release and do not involve
> other meta recipes.

Whether they make sense depends probably on your perception.
I think they do, that's why I've been working on them, but it is
highly likely someone feels it does not make sense.

Rationale to get them in the archive is twofold:
- others can build and use the image too (it is an image for my james project)
- it can be incorporated in the regression testing. (and frankly I
would like to get them into this thursday's testing-next)

The new image does depend on the new tasks. No one depends on the new
tasks (that's why the are new)

>
>> Also I will have a working uclibc++ recipe by tomorrow or so. (the
>> current one does not build for me).
>
> Post them to ml.

Will do.
>
>> I feel changes like those are pretty harmless.
>>
>> Frans
>>
>> _______________________________________________
>> Openembedded-devel mailing list
>> Openembedded-devel@lists.openembedded.org
>> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
>>
>
> _______________________________________________
> Openembedded-devel mailing list
> Openembedded-devel@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
>

Re: Preparing for release - Freeze on master

[Koen Kooi]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 16-11-10 19:20, Khem Raj wrote:
> Hello All,
> 
> In order to get to the 2010.12 release, I would like to request to
> stop pushing any changes to master until release. Please keep your
> changes in you local tree ready for when the window
> opens again after the release.

At OEDEM we agreed that the release would pick a tested branch tag to
avoid such a draconic freeze.

regards,

Koen
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Darwin)

iD8DBQFM45yIMkyGM64RGpERAg3vAJwNA5rhbbvqBdlcooaaCAIdk3nixACbB698
NO2DRKlx0oh3IaUQH0rhH1w=
=66ST
-----END PGP SIGNATURE-----

Re: Preparing for release - Freeze on master

[Graeme Gregory]

On 17/11/2010 09:12, Koen Kooi wrote:
> On 16-11-10 19:20, Khem Raj wrote:
> > Hello All,
>
> > In order to get to the 2010.12 release, I would like to request to
> > stop pushing any changes to master until release. Please keep your
> > changes in you local tree ready for when the window
> > opens again after the release.
>
> At OEDEM we agreed that the release would pick a tested branch tag to
> avoid such a draconic freeze.
>
I must say I am puzzled why the freeze when git supports branches. In
the past we have just picked a point branched then cherry picked
anything interesting that went into org.openemedded.dev until release date.

Graeme

Re: Preparing for release - Freeze on master

[Koen Kooi]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 17-11-10 10:56, Graeme Gregory wrote:
> On 17/11/2010 09:12, Koen Kooi wrote:
>> On 16-11-10 19:20, Khem Raj wrote:
>>> Hello All,
>>
>>> In order to get to the 2010.12 release, I would like to request to
>>> stop pushing any changes to master until release. Please keep your
>>> changes in you local tree ready for when the window
>>> opens again after the release.
>>
>> At OEDEM we agreed that the release would pick a tested branch tag to
>> avoid such a draconic freeze.
>>
> I must say I am puzzled why the freeze when git supports branches. In
> the past we have just picked a point branched then cherry picked
> anything interesting that went into org.openemedded.dev until release date.

At OEDEM we decided that the release would be a tag, not branch of .dev.
To make this release easy and unobtrusive the release team would pick a
tag of the tested stuff that they thought is best. So the december
release might actually use a tag from september if that proves to be the
most "stable".

I would think our normal commit policy would cover "dangerous" commits
already, so I object to this draconion freeze proposal.

regards,

Koen
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Darwin)

iD8DBQFM462iMkyGM64RGpERAvkmAJ4glGYefhsTMST+UGbZFHI6pjS2qACgrS9g
AvU3Xy0Y1105HoW1/vLGU2I=
=EVng
-----END PGP SIGNATURE-----

Re: Preparing for release - Freeze on master

[Khem Raj]

On Wed, Nov 17, 2010 at 2:25 AM, Koen Kooi <k.kooi@student.utwente.nl> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 17-11-10 10:56, Graeme Gregory wrote:
>> On 17/11/2010 09:12, Koen Kooi wrote:
>>> On 16-11-10 19:20, Khem Raj wrote:
>>>> Hello All,
>>>
>>>> In order to get to the 2010.12 release, I would like to request to
>>>> stop pushing any changes to master until release. Please keep your
>>>> changes in you local tree ready for when the window
>>>> opens again after the release.
>>>
>>> At OEDEM we agreed that the release would pick a tested branch tag to
>>> avoid such a draconic freeze.
>>>
>> I must say I am puzzled why the freeze when git supports branches. In
>> the past we have just picked a point branched then cherry picked
>> anything interesting that went into org.openemedded.dev until release date.
>
> At OEDEM we decided that the release would be a tag, not branch of .dev.
> To make this release easy and unobtrusive the release team would pick a
> tag of the tested stuff that they thought is best. So the december
> release might actually use a tag from september if that proves to be the
> most "stable".

well. if thats the case then I guess there is not much to be done isn't it.
we just convert a tag into release tag. I was trying to cover more
than what we usually
test on weekly bases in coming couple of tags. Should we create a release branch
before we release and solidify that ? and how many of us would be
willing to help there
if there are not many then it would not work.

>
> I would think our normal commit policy would cover "dangerous" commits
> already, so I object to this draconion freeze proposal.
>

No, commits happen without review and they break stuff for others its
an ongoing thing which is OK for a dev branch
but can be a problem when we are trying to release. This is a minimize
that effect until release.

> regards,
>
> Koen
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.5 (Darwin)
>
> iD8DBQFM462iMkyGM64RGpERAvkmAJ4glGYefhsTMST+UGbZFHI6pjS2qACgrS9g
> AvU3Xy0Y1105HoW1/vLGU2I=
> =EVng
> -----END PGP SIGNATURE-----
>
>
> _______________________________________________
> Openembedded-devel mailing list
> Openembedded-devel@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
>

Re: Preparing for release - Freeze on master

[Phil Blundell]

On Wed, 2010-11-17 at 11:26 -0800, Khem Raj wrote:
> Should we create a release branch before we release and solidify that ? 

Yes, please do that.  We discussed this issue at yesterday's TSC meeting
(full minutes to follow shortly) and the consensus was that trying to
enforce a complete freeze on master at short notice is not going to be
practical.

Obviously the exact process you use is up to you, but I would suggest
something along the lines of:

1. make a stabilisation branch from some semi-arbitrary point, maybe one
of the existing weekly test versions.

2. do testing on this branch.

3. cherry-pick and/or revert changesets on the branch as
necessary/desired.

4. iterate steps 2/3 until you are happy with the quality or the
deadline is reached.

5. tag the release from the current head of that branch.

p.

Re: Preparing for release - Freeze on master

[Graham Gower]

 Everyone is going to want to apply fixes to the release, so it makes
sense to have this as a new stable branch.

OE is in a relatively stable state right now with no major changes
causing large fallout recently. So, why not just branch it already and
apply the same commit policy as the existing stable branch.

More importantly are the logistics of handling what fixes go onto the
both branches or only the dev branch. Since the current stable branch
has been stale since I became involved in OE, I don't really know how
this works but I am very interested in submitting fixes for a stable
branch over the next few months.

-Graham

Re: Preparing for release - Freeze on master

[Phil Blundell]

On Thu, 2010-11-18 at 21:31 +1030, Graham Gower wrote:
> So, why not just branch it already and apply the same commit policy as 
> the existing stable branch.

Essentially because nobody has yet volunteered to do the ongoing
maintenance work that would be involved in having a long-lived stable
branch.  And, if OE is going to have releases off master on a fairly
frequent schedule (I think the proposal is four releases per year or
thereabouts) then the requirement for such a branch is somewhat
diminished.

If you're interested in doing the work to maintain a new stable branch
along the same lines as stable/2009, and you can commit the time that is
required to make it work, then you are certainly very welcome to do so.
You don't need any particular permission to do this: you can (subject to
the Branching Policy) create a new branch at any time.

p.

Re: Preparing for release - Freeze on master

[Philip Balister]

On 11/18/2010 03:31 AM, Phil Blundell wrote:
> On Thu, 2010-11-18 at 21:31 +1030, Graham Gower wrote:
>> So, why not just branch it already and apply the same commit policy as
>> the existing stable branch.
>
> Essentially because nobody has yet volunteered to do the ongoing
> maintenance work that would be involved in having a long-lived stable
> branch.  And, if OE is going to have releases off master on a fairly
> frequent schedule (I think the proposal is four releases per year or
> thereabouts) then the requirement for such a branch is somewhat
> diminished.
>
> If you're interested in doing the work to maintain a new stable branch
> along the same lines as stable/2009, and you can commit the time that is
> required to make it work, then you are certainly very welcome to do so.
> You don't need any particular permission to do this: you can (subject to
> the Branching Policy) create a new branch at any time.

I'd like to emphasize this point, the tag is a sane place for people to 
start from. The OE project deliver meta-data for people to build 
products on. It is the responsibility of the people delivering 
images/packages to people to manage their own branches for maintenance.

We certainly encourage groups of people to collaborate with each other 
to maintain branches, but I don't see a one policy suits all branch.

One man's stable is anothers stagnant.

Philip

Re: Preparing for release - Freeze on master

[Frans Meulenbroeks]

2010/11/18 Phil Blundell <philb@gnu.org>:

>
> 1. make a stabilisation branch from some semi-arbitrary point, maybe one
> of the existing weekly test versions.

Seems fine with me. I suggest to start with the testing branch that is
to be made today.
that avoids having to pick the changes that are done for the release
on the master branch last week.

Frans

Re: Preparing for release - Freeze on master

[Chris Larson]

On Thu, Nov 18, 2010 at 4:09 AM, Frans Meulenbroeks <
fransmeulenbroeks@gmail.com> wrote:

> 2010/11/18 Phil Blundell <philb@gnu.org>:
>
> >
> > 1. make a stabilisation branch from some semi-arbitrary point, maybe one
> > of the existing weekly test versions.
>
> Seems fine with me. I suggest to start with the testing branch that is
> to be made today.
> that avoids having to pick the changes that are done for the release
> on the master branch last week.
>

Just a reminder that this stabilization branch should only exist from this
semi-arbitrary point to the point when the release is tagged -- the branch
should then be removed, to ensure no one thinks it is a long term
maintenance branch, which it is not.
-- 
Christopher Larson
clarson at kergoth dot com
Founder - BitBake, OpenEmbedded, OpenZaurus
Maintainer - Tslib
Senior Software Engineer, Mentor Graphics

Re: Preparing for release - Freeze on master

[Khem Raj]

On Thu, Nov 18, 2010 at 2:08 AM, Phil Blundell <philb@gnu.org> wrote:
> On Wed, 2010-11-17 at 11:26 -0800, Khem Raj wrote:
>> Should we create a release branch before we release and solidify that ?
>
> Yes, please do that.  We discussed this issue at yesterday's TSC meeting
> (full minutes to follow shortly) and the consensus was that trying to
> enforce a complete freeze on master at short notice is not going to be
> practical.
>
> Obviously the exact process you use is up to you, but I would suggest
> something along the lines of:
>
> 1. make a stabilisation branch from some semi-arbitrary point, maybe one
> of the existing weekly test versions.
>
> 2. do testing on this branch.
>
> 3. cherry-pick and/or revert changesets on the branch as
> necessary/desired.
>
> 4. iterate steps 2/3 until you are happy with the quality or the
> deadline is reached.
>
> 5. tag the release from the current head of that branch.
>

Yes, thats a sensible approach. Starting from testing tag is a sane
thing to start with.

Thanks
-Khem

> p.
>
>
>
> _______________________________________________
> Openembedded-devel mailing list
> Openembedded-devel@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
>

Re: Preparing for release - Freeze on master

[Koen Kooi]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 18-11-10 11:08, Phil Blundell wrote:
> On Wed, 2010-11-17 at 11:26 -0800, Khem Raj wrote:
>> Should we create a release branch before we release and solidify that ? 
> 
> Yes, please do that.  We discussed this issue at yesterday's TSC meeting
> (full minutes to follow shortly) and the consensus was that trying to
> enforce a complete freeze on master at short notice is not going to be
> practical.
> 
> Obviously the exact process you use is up to you, but I would suggest
> something along the lines of:
> 
> 1. make a stabilisation branch from some semi-arbitrary point, maybe one
> of the existing weekly test versions.

At OEDEM we decided that there would be no branch, only a tag, could the
TSC elaborate why they are going against that?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Darwin)

iD8DBQFM5lF3MkyGM64RGpERAr/pAJwIE46snPNsW42xpR6J3wKJGxpw0gCgkvhZ
MFR65AifpMR/v69fhN6JwNQ=
=aCtY
-----END PGP SIGNATURE-----

Re: Preparing for release - Freeze on master

[Khem Raj]

On Wed, Nov 17, 2010 at 1:56 AM, Graeme Gregory <dp@xora.org.uk> wrote:
> On 17/11/2010 09:12, Koen Kooi wrote:
>> On 16-11-10 19:20, Khem Raj wrote:
>> > Hello All,
>>
>> > In order to get to the 2010.12 release, I would like to request to
>> > stop pushing any changes to master until release. Please keep your
>> > changes in you local tree ready for when the window
>> > opens again after the release.
>>
>> At OEDEM we agreed that the release would pick a tested branch tag to
>> avoid such a draconic freeze.
>>
> I must say I am puzzled why the freeze when git supports branches. In
> the past we have just picked a point branched then cherry picked
> anything interesting that went into org.openemedded.dev until release date.
>

I guess wrong choice of words, I should have said caution. We can use
branch to solidify release thats ok
given we have enough people testing it out and working on it which I
am a bit doubtful can happen. Thats why
slowing down a bit on commits for a bit, tag the release and keep going.


> Graeme
>
>
> _______________________________________________
> Openembedded-devel mailing list
> Openembedded-devel@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
>

Re: Preparing for release - Freeze on master

[Khem Raj]

On Wed, Nov 17, 2010 at 1:12 AM, Koen Kooi <k.kooi@student.utwente.nl> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 16-11-10 19:20, Khem Raj wrote:
>> Hello All,
>>
>> In order to get to the 2010.12 release, I would like to request to
>> stop pushing any changes to master until release. Please keep your
>> changes in you local tree ready for when the window
>> opens again after the release.
>
> At OEDEM we agreed that the release would pick a tested branch tag to
> avoid such a draconic freeze.
>

I guess you misunderstood. We are tagging tested releases. It will be
similar but this time
as we are making release, I want people to be more cautious of what is
committed. As we do not
branch and tag master thats why the request to be a bit careful
because if you look at the
tested tags we have broken builds for some weeks. The release will be
a tag and not a branch from master
after release if need be and there is enough developer interest to get
bug fixes to the release and maintain
it thats fine to branch at that point from the tag

> regards,
>
> Koen
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.5 (Darwin)
>
> iD8DBQFM45yIMkyGM64RGpERAg3vAJwNA5rhbbvqBdlcooaaCAIdk3nixACbB698
> NO2DRKlx0oh3IaUQH0rhH1w=
> =66ST
> -----END PGP SIGNATURE-----
>
>
> _______________________________________________
> Openembedded-devel mailing list
> Openembedded-devel@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
>