release-2010.12 branch ready for testing

release-2010.12 branch ready for testing

[Khem Raj]

Hello all,

The work branch for upcoming 2010.12 release has been created. Please
lend your hand in testing this branch and cherry-picking
fixes that we need to make the release a robust one. Testing as many
combinations of machine/distro/image as possible would be
nice. Please use the Testing matrix to report the results.

If you are not cloning then ignore the first step

$ git clone git://git.openembedded.org/openembedded
$ cd openembedded
$ git checkout -b release-2010.12 origin/release-2010.12

Cherry pick the patches that need to go into this branch and when you
are ready to push them then do

$ git push -v origin release-2010.12:release-2010.12

this will only push the commits meant for release branch and other
branches wont be pushed

Please send the patches that need to be cherry picked to mailing list
for review with subject line prefixed with [release-2010.12]
or discuss on IRC.

Thank you for help

Lets make this release a success

-Khem

Re: release-2010.12 branch ready for testing

[Frans Meulenbroeks]

2010/11/18 Khem Raj <raj.khem@gmail.com>:
> Hello all,
>
> The work branch for upcoming 2010.12 release has been created. Please
> lend your hand in testing this branch and cherry-picking
> fixes that we need to make the release a robust one. Testing as many
> combinations of machine/distro/image as possible would be
> nice. Please use the Testing matrix to report the results.
>
> If you are not cloning then ignore the first step
>
> $ git clone git://git.openembedded.org/openembedded
> $ cd openembedded
> $ git checkout -b release-2010.12 origin/release-2010.12
>
> Cherry pick the patches that need to go into this branch and when you
> are ready to push them then do
>
> $ git push -v origin release-2010.12:release-2010.12
>
> this will only push the commits meant for release branch and other
> branches wont be pushed
>
> Please send the patches that need to be cherry picked to mailing list
> for review with subject line prefixed with [release-2010.12]
> or discuss on IRC.
>
> Thank you for help
>
> Lets make this release a success
>
> -Khem
>

I suggest as one of the tests to do a real clean build.
Typically my tests start with an empty TMPDIR, but I tend to reuse my
downloads dir. Also normally for packages not in downloads I use a
local premirror (at least at work).

Yesterday I found that php did not fetch any more from the src as a
new version was made available and the old version moved to a
different address (museum).
Could be there are more of this.
Suggestion is that a build is tested with an empty downloads dir and
without any mirror (but can't set it up such a test easily at the
moment)

For php I have a crude patch, but will try to improve it this weekend.

The crude patch is to change php.inc with:
diff --git a/recipes/php/php.inc b/recipes/php/php.inc
index bfee93c..ae9c7e2 100644
--- a/recipes/php/php.inc
+++ b/recipes/php/php.inc
@@ -3,7 +3,7 @@ HOMEPAGE = "http://www.php.net"
 SECTION = "console/network"
 LICENSE = "PHP"

-SRC_URI =     "http://us2.php.net/distributions/php-${PV}.tar.bz2;name=src \
+SRC_URI =     "http://museum.php.net/php5/php-${PV}.tar.bz2;name=src \
                file://acinclude-xml2-config.patch \
                file://php-m4-divert.patch"

However, that does not allow having the newest version and an older
version in a recipe as the SRC_URI mismatches
Plan is to move SRC_URI outside the inc and to the individual recipes,
but it'll be sat or sun before I get to that.
I'll also try to peek at upgrading php for master.

Frans

Re: release-2010.12 branch ready for testing

[Koen Kooi]

-----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?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Darwin)

iD8DBQFM5lKsMkyGM64RGpERApvMAJ43a/hkKcQwWaddIANExDaEbLsECQCeJZvG
F6e/1Z8cFoj3D78lV7Io3a4=
=PwWn
-----END PGP SIGNATURE-----

Re: release-2010.12 branch ready for testing

[Tom Rini]

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?

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...

-- 
Tom Rini
Mentor Graphics Corporation

Re: release-2010.12 branch ready for testing

[Koen Kooi]

-----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?
> 
> 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.

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?


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

iD8DBQFM5oahMkyGM64RGpERAk1OAJ9Oo6sMLydFi5HYoVQAfQr4AoVVrQCfRd0V
v06+p6STeoj35fihSo/Lu2I=
=d9+8
-----END PGP SIGNATURE-----

Re: release-2010.12 branch ready for testing

[Martin Jansa]

On Fri, Nov 19, 2010 at 03:16:02PM +0100, Koen Kooi wrote:
> 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.
> 
> 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?

Hi,

I think that short-lived branch is better, because every testing branch
had few easy-to-fix issues which were fixed almost immediately in .dev 
after testing branched and it would be hard to choose which branch was best.

But tag from any testing branch + first few quick fixes would be almost as 
good as based on any other testing branch. 

And I also agree with Phil that this short lived branch should be
removed when the tag is created (to show that it's final state without
maintainance).

Just my 2c.

Regards,

-- 
Martin 'JaMa' Jansa     jabber: Martin.Jansa@gmail.com

Re: release-2010.12 branch ready for testing

[Philip Balister]

On 11/19/2010 06:44 AM, Martin Jansa wrote:
....


> I think that short-lived branch is better, because every testing branch
> had few easy-to-fix issues which were fixed almost immediately in .dev
> after testing branched and it would be hard to choose which branch was best.
>
> But tag from any testing branch + first few quick fixes would be almost as
> good as based on any other testing branch.
>
> And I also agree with Phil that this short lived branch should be
> removed when the tag is created (to show that it's final state without
> maintainance).

I also think a *short lived* branch is a good route to try. I've been 
thinking about how the git history looks of a tag after you delete the 
branch leading up to it.

For emphasis, the short lived branch will not be used to maintain the tag.

Philip

Re: 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@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel

Re: release-2010.12 branch ready for testing

[Khem Raj]

On Fri, Nov 19, 2010 at 9:34 AM, Philip Balister <philip@balister.org> wrote:
> On 11/19/2010 06:44 AM, Martin Jansa wrote:
> ....
>
>
>> I think that short-lived branch is better, because every testing branch
>> had few easy-to-fix issues which were fixed almost immediately in .dev
>> after testing branched and it would be hard to choose which branch was
>> best.
>>
>> But tag from any testing branch + first few quick fixes would be almost as
>> good as based on any other testing branch.
>>
>> And I also agree with Phil that this short lived branch should be
>> removed when the tag is created (to show that it's final state without
>> maintainance).
>
> I also think a *short lived* branch is a good route to try. I've been
> thinking about how the git history looks of a tag after you delete the
> branch leading up to it.
>
> For emphasis, the short lived branch will not be used to maintain the tag.
>

Yes this is exactly a short lived branch. The patches would come via
master mostly.

here are steps.

1. Tag master with branchpoint
2. Create branch
3. Cherry-pick fixes (usually commit to master first) -- (current state)
4. Tag the branch for release
5. Collapse branch to master
6. Delete release branch
7. Announce the release

Thanks
-Khem

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