* Re: [STABLE] branch created: stable/2009
2009-03-31 16:37 [STABLE] branch created: stable/2009 Marcin Juszkiewicz
@ 2009-03-31 17:00 ` Koen Kooi
2009-03-31 17:17 ` Tom Rini
2009-03-31 20:02 ` Robert Schuster
` (2 subsequent siblings)
3 siblings, 1 reply; 16+ messages in thread
From: Koen Kooi @ 2009-03-31 17:00 UTC (permalink / raw)
To: openembedded-devel
On 31-03-09 18:37, Marcin Juszkiewicz wrote:
>
> Hi
>
> I would like to announce creation of new branch: stable/2009 in
> OpenEmbedded repository. It was branched few days ago, build tested and
> got some bugfixes which were added to .dev tree (and back to
> stable/2009).
>
> What was in build test? Distro "angstrom-2008.1", machines: qemuarm
> (armv5te), at91sam9263ek (armv5te), beagleboard (armv7a), qemux86 (i586)
> and vortex86sx (486sx). I tested building of next images: console,
> console-base, x11, beagleboard-demo for each of those machines. So far
> only glibc builds were tested, uclibc one is queued.
>
> I also imported BitBake 1.8.12 (last release) into "stable/2009" branch
> as this is minimal stable version which works with this repository.
>
> Feel free to clone and do tests. I will write more later.
Great!
I already have a few patches queued up for the stablebranch:
http://dominion.thruhere.net/koen/OE/for-stable/
What's the proper procedure for getting those in?
regards,
Koen
^ permalink raw reply [flat|nested] 16+ messages in thread* Re: [STABLE] branch created: stable/2009
2009-03-31 17:00 ` Koen Kooi
@ 2009-03-31 17:17 ` Tom Rini
2009-03-31 19:49 ` Marcin Juszkiewicz
0 siblings, 1 reply; 16+ messages in thread
From: Tom Rini @ 2009-03-31 17:17 UTC (permalink / raw)
To: openembedded-devel
On Tue, Mar 31, 2009 at 07:00:59PM +0200, Koen Kooi wrote:
> On 31-03-09 18:37, Marcin Juszkiewicz wrote:
>>
>> Hi
>>
>> I would like to announce creation of new branch: stable/2009 in
>> OpenEmbedded repository. It was branched few days ago, build tested and
>> got some bugfixes which were added to .dev tree (and back to
>> stable/2009).
>>
>> What was in build test? Distro "angstrom-2008.1", machines: qemuarm
>> (armv5te), at91sam9263ek (armv5te), beagleboard (armv7a), qemux86 (i586)
>> and vortex86sx (486sx). I tested building of next images: console,
>> console-base, x11, beagleboard-demo for each of those machines. So far
>> only glibc builds were tested, uclibc one is queued.
>>
>> I also imported BitBake 1.8.12 (last release) into "stable/2009" branch
>> as this is minimal stable version which works with this repository.
>>
>> Feel free to clone and do tests. I will write more later.
>
> Great!
>
> I already have a few patches queued up for the stablebranch:
>
> http://dominion.thruhere.net/koen/OE/for-stable/
>
> What's the proper procedure for getting those in?
And please answer in the form of a link to a wiki page :)
--
Tom Rini
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [STABLE] branch created: stable/2009
2009-03-31 17:17 ` Tom Rini
@ 2009-03-31 19:49 ` Marcin Juszkiewicz
2009-04-01 11:42 ` Koen Kooi
2009-04-02 10:49 ` [RFC] more streamlined review procedure, was: " Koen Kooi
0 siblings, 2 replies; 16+ messages in thread
From: Marcin Juszkiewicz @ 2009-03-31 19:49 UTC (permalink / raw)
To: openembedded-devel
Dnia wtorek, 31 marca 2009 o 19:17:27 Tom Rini napisał(a):
> > Great!
> >
> > I already have a few patches queued up for the stablebranch:
> >
> > http://dominion.thruhere.net/koen/OE/for-stable/
> >
> > What's the proper procedure for getting those in?
>
> And please answer in the form of a link to a wiki page :)
http://wiki.openembedded.net/index.php/Stable contains first
informations.
Regards,
--
JID: hrw@jabber.org
Website: http://marcin.juszkiewicz.com.pl/
LinkedIn: http://www.linkedin.com/in/marcinjuszkiewicz
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [STABLE] branch created: stable/2009
2009-03-31 19:49 ` Marcin Juszkiewicz
@ 2009-04-01 11:42 ` Koen Kooi
2009-04-02 10:49 ` [RFC] more streamlined review procedure, was: " Koen Kooi
1 sibling, 0 replies; 16+ messages in thread
From: Koen Kooi @ 2009-04-01 11:42 UTC (permalink / raw)
To: openembedded-devel
On 31-03-09 21:49, Marcin Juszkiewicz wrote:
> Dnia wtorek, 31 marca 2009 o 19:17:27 Tom Rini napisał(a):
>>> Great!
>>>
>>> I already have a few patches queued up for the stablebranch:
>>>
>>> http://dominion.thruhere.net/koen/OE/for-stable/
>>>
>>> What's the proper procedure for getting those in?
>>
>> And please answer in the form of a link to a wiki page :)
>
> http://wiki.openembedded.net/index.php/Stable contains first
> informations.
Thanks, to make getting the patches a bit easier I created a public
patchwork bundle:
http://patchwork.openembedded.org/bundle/koen/koen-for-stable-20090331/
And if everyone uses the [STABLE] tag in mail subjects my patchwork
filter will make it easier to pick them out.
regards,
Koen
^ permalink raw reply [flat|nested] 16+ messages in thread
* [RFC] more streamlined review procedure, was: Re: [STABLE] branch created: stable/2009
2009-03-31 19:49 ` Marcin Juszkiewicz
2009-04-01 11:42 ` Koen Kooi
@ 2009-04-02 10:49 ` Koen Kooi
2009-04-02 15:31 ` Marco Cavallini
1 sibling, 1 reply; 16+ messages in thread
From: Koen Kooi @ 2009-04-02 10:49 UTC (permalink / raw)
To: openembedded-devel
On 31-03-09 21:49, Marcin Juszkiewicz wrote:
> Dnia wtorek, 31 marca 2009 o 19:17:27 Tom Rini napisał(a):
>>> Great!
>>>
>>> I already have a few patches queued up for the stablebranch:
>>>
>>> http://dominion.thruhere.net/koen/OE/for-stable/
>>>
>>> What's the proper procedure for getting those in?
>>
>> And please answer in the form of a link to a wiki page :)
>
> http://wiki.openembedded.net/index.php/Stable contains first
> informations.
I've found that there's a huge flaw in this setup:
Currently there are 8 people signed up as 'maintainers' for the stable
branch, but only 2 (yes, two) have looked at some of the patches posted
2 days ago. Another said he didn't want to look at patches for machines
he didn't build for. No idea why the other 4 haven't responded, but if
this continues then the stable branch can be closed down immediately.
Why? The current procedure requires an ACK from a stable 'maintainer'
(not including yourself, of course), but you won't get an ACK or even a
NACK.
This is annoying since I've had the first bugreports from users that
were solved by patches that are 'under review'.
The previous stable branch tried to guarantee that you'd get at least a
reaction on all your patches within 24 hours, so submitters knew what
was happening. A 'reaction', not a 'review', so "will look at it next
week" is perfectly well.
So my proposal:
* within 24 hours of posting at least 1 reaction from any stable
'maintainer'
* No review within a week means automatic approval, commit must have
"UNREVIEWED" marker to signify that.
Also:
I still have unreviewed patches in my for-stable bundle:
http://patchwork.openembedded.org/bundle/koen/koen-for-stable-20090331/
regards,
Koen
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [RFC] more streamlined review procedure, was: Re: [STABLE] branch created: stable/2009
2009-04-02 10:49 ` [RFC] more streamlined review procedure, was: " Koen Kooi
@ 2009-04-02 15:31 ` Marco Cavallini
2009-04-02 17:31 ` Koen Kooi
0 siblings, 1 reply; 16+ messages in thread
From: Marco Cavallini @ 2009-04-02 15:31 UTC (permalink / raw)
To: openembedded-devel
Koen Kooi ha scritto:
> I've found that there's a huge flaw in this setup:
>
> Currently there are 8 people signed up as 'maintainers' for the stable
> branch, but only 2 (yes, two) have looked at some of the patches posted
> 2 days ago. Another said he didn't want to look at patches for machines
> he didn't build for. No idea why the other 4 haven't responded, but if
> this continues then the stable branch can be closed down immediately.
>
> Why? The current procedure requires an ACK from a stable 'maintainer'
> (not including yourself, of course), but you won't get an ACK or even a
> NACK.
>
> This is annoying since I've had the first bugreports from users that
> were solved by patches that are 'under review'.
>
> The previous stable branch tried to guarantee that you'd get at least a
> reaction on all your patches within 24 hours, so submitters knew what
> was happening. A 'reaction', not a 'review', so "will look at it next
> week" is perfectly well.
>
> So my proposal:
>
> * within 24 hours of posting at least 1 reaction from any stable
> 'maintainer'
> * No review within a week means automatic approval, commit must have
> "UNREVIEWED" marker to signify that.
Hi
I'm trying to understand the best way to proceed.
I think you shouldn't ACK a patch that you can't test.
Maybe I'm wrong or I'm misunderstanding the goal of a 'stable' branch?
/marco
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [RFC] more streamlined review procedure, was: Re: [STABLE] branch created: stable/2009
2009-04-02 15:31 ` Marco Cavallini
@ 2009-04-02 17:31 ` Koen Kooi
0 siblings, 0 replies; 16+ messages in thread
From: Koen Kooi @ 2009-04-02 17:31 UTC (permalink / raw)
To: openembedded-devel
On 02-04-09 17:31, Marco Cavallini wrote:
> Koen Kooi ha scritto:
>> I've found that there's a huge flaw in this setup:
>>
>> Currently there are 8 people signed up as 'maintainers' for the stable
>> branch, but only 2 (yes, two) have looked at some of the patches posted
>> 2 days ago. Another said he didn't want to look at patches for machines
>> he didn't build for. No idea why the other 4 haven't responded, but if
>> this continues then the stable branch can be closed down immediately.
>>
>> Why? The current procedure requires an ACK from a stable 'maintainer'
>> (not including yourself, of course), but you won't get an ACK or even a
>> NACK.
>>
>> This is annoying since I've had the first bugreports from users that
>> were solved by patches that are 'under review'.
>>
>> The previous stable branch tried to guarantee that you'd get at least a
>> reaction on all your patches within 24 hours, so submitters knew what
>> was happening. A 'reaction', not a 'review', so "will look at it next
>> week" is perfectly well.
>>
>> So my proposal:
>>
>> * within 24 hours of posting at least 1 reaction from any stable
>> 'maintainer'
>> * No review within a week means automatic approval, commit must have
>> "UNREVIEWED" marker to signify that.
>
> Hi
> I'm trying to understand the best way to proceed.
> I think you shouldn't ACK a patch that you can't test.
> Maybe I'm wrong or I'm misunderstanding the goal of a 'stable' branch?
It seems you didn't read http://wiki.openembedded.net/index.php/Stable:
"It is important to note that we will test for building. Testing on
target devices is left for users which can (and should) report bugs if
something is not working. More about reporting bugs later in that text."
There's no "can't" when it comes for testing for the stable branch.
regards,
Koen
PS: I do think we should test on a target device whenever possible
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [STABLE] branch created: stable/2009
2009-03-31 16:37 [STABLE] branch created: stable/2009 Marcin Juszkiewicz
2009-03-31 17:00 ` Koen Kooi
@ 2009-03-31 20:02 ` Robert Schuster
2009-04-02 9:55 ` Marcin Juszkiewicz
2009-04-01 7:32 ` Marco Cavallini
2009-04-02 10:52 ` Esben Haabendal
3 siblings, 1 reply; 16+ messages in thread
From: Robert Schuster @ 2009-03-31 20:02 UTC (permalink / raw)
To: openembedded-devel
[-- Attachment #1: Type: text/plain, Size: 1411 bytes --]
Hi,
is it possible/allowed to port things into the stable which IMO make its
maintenance easier? E.g. I've just cleaned up the llvm recipes and made
them side by side installable (multiple version). The stable branch
would be more of a burden when these things differ so much from each other.
Apart from that llvm is not used from anything but the llvm-gcc recipes
which I saw and which look not inspiring confidence.
Last but not least I was going to base the Jalimo recipes on that and
then finally move them into OE.
Regards
Robert
Marcin Juszkiewicz schrieb:
> Hi
>
> I would like to announce creation of new branch: stable/2009 in
> OpenEmbedded repository. It was branched few days ago, build tested and
> got some bugfixes which were added to .dev tree (and back to
> stable/2009).
>
> What was in build test? Distro "angstrom-2008.1", machines: qemuarm
> (armv5te), at91sam9263ek (armv5te), beagleboard (armv7a), qemux86 (i586)
> and vortex86sx (486sx). I tested building of next images: console,
> console-base, x11, beagleboard-demo for each of those machines. So far
> only glibc builds were tested, uclibc one is queued.
>
> I also imported BitBake 1.8.12 (last release) into "stable/2009" branch
> as this is minimal stable version which works with this repository.
>
> Feel free to clone and do tests. I will write more later.
>
> Regards,
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 268 bytes --]
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [STABLE] branch created: stable/2009
2009-03-31 16:37 [STABLE] branch created: stable/2009 Marcin Juszkiewicz
2009-03-31 17:00 ` Koen Kooi
2009-03-31 20:02 ` Robert Schuster
@ 2009-04-01 7:32 ` Marco Cavallini
2009-04-02 10:52 ` Esben Haabendal
3 siblings, 0 replies; 16+ messages in thread
From: Marco Cavallini @ 2009-04-01 7:32 UTC (permalink / raw)
To: openembedded-devel
Marcin Juszkiewicz ha scritto:
> Hi
>
> I would like to announce creation of new branch: stable/2009 in
> OpenEmbedded repository. It was branched few days ago, build tested and
> got some bugfixes which were added to .dev tree (and back to
> stable/2009).
>
> What was in build test? Distro "angstrom-2008.1", machines: qemuarm
> (armv5te), at91sam9263ek (armv5te), beagleboard (armv7a), qemux86 (i586)
> and vortex86sx (486sx). I tested building of next images: console,
> console-base, x11, beagleboard-demo for each of those machines. So far
> only glibc builds were tested, uclibc one is queued.
>
> I also imported BitBake 1.8.12 (last release) into "stable/2009" branch
> as this is minimal stable version which works with this repository.
>
> Feel free to clone and do tests. I will write more later.
>
> Regards,
What command do you use to get it ?
/marco
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [STABLE] branch created: stable/2009
2009-03-31 16:37 [STABLE] branch created: stable/2009 Marcin Juszkiewicz
` (2 preceding siblings ...)
2009-04-01 7:32 ` Marco Cavallini
@ 2009-04-02 10:52 ` Esben Haabendal
2009-04-02 11:25 ` Marcin Juszkiewicz
3 siblings, 1 reply; 16+ messages in thread
From: Esben Haabendal @ 2009-04-02 10:52 UTC (permalink / raw)
To: openembedded-devel
On Tue, Mar 31, 2009 at 6:37 PM, Marcin Juszkiewicz
<marcin@juszkiewicz.com.pl> wrote:
>
> I also imported BitBake 1.8.12 (last release) into "stable/2009" branch
> as this is minimal stable version which works with this repository.
Is this the new strategy for handling depedency on specific versions of BitBake?
/Esben
--
Esben Haabendal, Senior Software Consultant
DoréDevelopment ApS, Ved Stranden 1, 9560 Hadsund, DK-Denmark
Phone: +45 51 92 53 93, E-mail: eha@doredevelopment.dk
WWW: http://www.doredevelopment.dk
^ permalink raw reply [flat|nested] 16+ messages in thread* Re: [STABLE] branch created: stable/2009
2009-04-02 10:52 ` Esben Haabendal
@ 2009-04-02 11:25 ` Marcin Juszkiewicz
2009-04-03 16:18 ` Esben Haabendal
0 siblings, 1 reply; 16+ messages in thread
From: Marcin Juszkiewicz @ 2009-04-02 11:25 UTC (permalink / raw)
To: openembedded-devel
Dnia czwartek, 2 kwietnia 2009 o 12:52:51 Esben Haabendal napisał(a):
> On Tue, Mar 31, 2009 at 6:37 PM, Marcin Juszkiewicz
>
> <marcin@juszkiewicz.com.pl> wrote:
> > I also imported BitBake 1.8.12 (last release) into "stable/2009"
> > branch as this is minimal stable version which works with this
> > repository.
>
> Is this the new strategy for handling depedency on specific versions
> of BitBake?
No, but we require minimal versions of BitBake to be used with OE
metadata so I prefer to have version which is granted to work. Imagine
situation when OE.dev will require BitBake 1.8.22 which will not work
with 'stable/2009' branch.
Regards,
--
JID: hrw@jabber.org
Website: http://marcin.juszkiewicz.com.pl/
LinkedIn: http://www.linkedin.com/in/marcinjuszkiewicz
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [STABLE] branch created: stable/2009
2009-04-02 11:25 ` Marcin Juszkiewicz
@ 2009-04-03 16:18 ` Esben Haabendal
2009-04-03 17:51 ` Marcin Juszkiewicz
0 siblings, 1 reply; 16+ messages in thread
From: Esben Haabendal @ 2009-04-03 16:18 UTC (permalink / raw)
To: openembedded-devel
On Thu, Apr 2, 2009 at 1:25 PM, Marcin Juszkiewicz
<marcin@juszkiewicz.com.pl> wrote:
> Dnia czwartek, 2 kwietnia 2009 o 12:52:51 Esben Haabendal napisał(a):
>> On Tue, Mar 31, 2009 at 6:37 PM, Marcin Juszkiewicz
>>
>> <marcin@juszkiewicz.com.pl> wrote:
>> > I also imported BitBake 1.8.12 (last release) into "stable/2009"
>> > branch as this is minimal stable version which works with this
>> > repository.
>>
>> Is this the new strategy for handling depedency on specific versions
>> of BitBake?
>
> No, but we require minimal versions of BitBake to be used with OE
> metadata so I prefer to have version which is granted to work. Imagine
> situation when OE.dev will require BitBake 1.8.22 which will not work
> with 'stable/2009' branch.
I fully understand the situation, but I am just wondering if we shouldn't be
paying more attention to this problem.
For the stable branches I need to maintain, I have had to make a solution
control which version of bitbake is used with each branch. Maybe it would
be worth to try work out a more general version of such a solutin.
But, I think it would be great if we "encode" into the OpenEmbedded
metadata which version of bitbake is recommended, and maybe even
which versions work and which is not expected to work. It could be
something as simple as adding a ".bitbake" to the top of the
metadata which contains a single line in the style of
"tags/bitbake-1.8.10", which would then make it possible for
people to know which version to use, and even automate
this in their setups.
We could then also make bitbake aware of this file, and then print
out a warning if a "wrong" version is used.
I am sure I am not the only one who have had to debug strange
problems before finding out that it would just be easier to go back
to an older bitbake version...
It is not that it is a big problem to import BitBake into OpenEmbedded,
although it generally is not the best solution to many things, as it
makes it a bit painful to propagate eventual critical fixes to all
the places where it is needed, but I just think that this is an
important issue that is worth to find a proper solution for.
Regards,
--
Esben Haabendal, Senior Software Consultant
DoréDevelopment ApS, Ved Stranden 1, 9560 Hadsund, DK-Denmark
Phone: +45 51 92 53 93, E-mail: eha@doredevelopment.dk
WWW: http://www.doredevelopment.dk
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [STABLE] branch created: stable/2009
2009-04-03 16:18 ` Esben Haabendal
@ 2009-04-03 17:51 ` Marcin Juszkiewicz
2009-04-03 23:55 ` Esben Haabendal
0 siblings, 1 reply; 16+ messages in thread
From: Marcin Juszkiewicz @ 2009-04-03 17:51 UTC (permalink / raw)
To: openembedded-devel
Dnia piątek, 3 kwietnia 2009 o 18:18:49 Esben Haabendal napisał(a):
> > No, but we require minimal versions of BitBake to be used with OE
> > metadata so I prefer to have version which is granted to work.
> > Imagine situation when OE.dev will require BitBake 1.8.22 which
> > will not work with 'stable/2009' branch.
> I fully understand the situation, but I am just wondering if we
> shouldn't be paying more attention to this problem.
>
> For the stable branches I need to maintain, I have had to make a
> solution control which version of bitbake is used with each branch.
> Maybe it would be worth to try work out a more general version of
> such a solutin.
>
> But, I think it would be great if we "encode" into the OpenEmbedded
> metadata which version of bitbake is recommended, and maybe even
> which versions work and which is not expected to work. It could be
> something as simple as adding a ".bitbake" to the top of the
> metadata which contains a single line in the style of
> "tags/bitbake-1.8.10", which would then make it possible for
> people to know which version to use, and even automate
> this in their setups.
>
> We could then also make bitbake aware of this file, and then print
> out a warning if a "wrong" version is used.
>
> I am sure I am not the only one who have had to debug strange
> problems before finding out that it would just be easier to go back
> to an older bitbake version...
>
> It is not that it is a big problem to import BitBake into
> OpenEmbedded, although it generally is not the best solution to many
> things, as it makes it a bit painful to propagate eventual critical
> fixes to all the places where it is needed, but I just think that
> this is an important issue that is worth to find a proper solution
> for.
sanity.conf sets one variable: BB_MIN_VERSION = "1.8.12" and this is
checked on start of each build. We bump that only when BitBake is
released and if change is really required.
Regards,
--
JID: hrw@jabber.org
Website: http://marcin.juszkiewicz.com.pl/
LinkedIn: http://www.linkedin.com/in/marcinjuszkiewicz
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [STABLE] branch created: stable/2009
2009-04-03 17:51 ` Marcin Juszkiewicz
@ 2009-04-03 23:55 ` Esben Haabendal
0 siblings, 0 replies; 16+ messages in thread
From: Esben Haabendal @ 2009-04-03 23:55 UTC (permalink / raw)
To: openembedded-devel
2009/4/3 Marcin Juszkiewicz <marcin@juszkiewicz.com.pl>:
> sanity.conf sets one variable: BB_MIN_VERSION = "1.8.12" and this is
> checked on start of each build. We bump that only when BitBake is
> released and if change is really required.
Ok.
Would it be a sane solution to them simply use the BitBake version specified
in BB_MIN_VERSION, or do the "if change is really required" mean that
it sometimes
makes good sense to use a newer version?
If so, it would be nice to have something like BB_RECOMMENDED_VERSION
Also, is the BB_MIN_VERSION defined so it will/must always be a tagged
version of bitbake?
/Esben
^ permalink raw reply [flat|nested] 16+ messages in thread