Re: [oe-commits] Koen Kooi : angstrom 2009.X: bump automake-native to 1.10. 2 since some idiot deleted 1.10

Re: [oe-commits] Koen Kooi : angstrom 2009.X: bump automake-native to 1.10. 2 since some idiot deleted 1.10

[Michael 'Mickey' Lauer]

Am Dienstag, den 03.03.2009, 21:49 +0100 schrieb GIT User account:
> Module: openembedded.git
> Branch: org.openembedded.dev
> Commit: eee859a9c348871d6d644ece76bc57b151cc80e8
> URL:    http://gitweb.openembedded.net/?p=openembedded.git&a=commit;h=eee859a9c348871d6d644ece76bc57b151cc80e8
> 
> Author: Koen Kooi <koen@openembedded.org>
> Date:   Tue Mar  3 21:47:57 2009 +0100
> 
> angstrom 2009.X: bump automake-native to 1.10.2 since some idiot deleted 1.10

Ah, are we in that mood again? Take more pills.

-- 
:M:

Re: [oe-commits] Koen Kooi : angstrom 2009.X: bump automake-native to 1.10. 2 since some idiot deleted 1.10

[Philip Balister]

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

Michael 'Mickey' Lauer wrote:
> Am Dienstag, den 03.03.2009, 21:49 +0100 schrieb GIT User account:
>> Module: openembedded.git
>> Branch: org.openembedded.dev
>> Commit: eee859a9c348871d6d644ece76bc57b151cc80e8
>> URL:    http://gitweb.openembedded.net/?p=openembedded.git&a=commit;h=eee859a9c348871d6d644ece76bc57b151cc80e8
>>
>> Author: Koen Kooi <koen@openembedded.org>
>> Date:   Tue Mar  3 21:47:57 2009 +0100
>>
>> angstrom 2009.X: bump automake-native to 1.10.2 since some idiot deleted 1.10
> 
> Ah, are we in that mood again? Take more pills.

We need to have a serious discussion about deleting recipes. I know the 
deletion of python 2.5 will force me to address the 2.5->2.6 upgrade in 
gnuradio before the upstream developers are ready.

We need a way to remove recipes, but doing it as part of adding a new 
recipe is causing problems for OE users.

Philip

[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/x-pkcs7-signature, Size: 3303 bytes --]

Re: [oe-commits] Koen Kooi : angstrom 2009.X: bump automake-native to 1.10. 2 since some idiot deleted 1.10

[Michael 'Mickey' Lauer]

Am Dienstag, den 03.03.2009, 17:38 -0500 schrieb Philip Balister:
> Michael 'Mickey' Lauer wrote:
> > Am Dienstag, den 03.03.2009, 21:49 +0100 schrieb GIT User account:
> >> Module: openembedded.git
> >> Branch: org.openembedded.dev
> >> Commit: eee859a9c348871d6d644ece76bc57b151cc80e8
> >> URL:    http://gitweb.openembedded.net/?p=openembedded.git&a=commit;h=eee859a9c348871d6d644ece76bc57b151cc80e8
> >>
> >> Author: Koen Kooi <koen@openembedded.org>
> >> Date:   Tue Mar  3 21:47:57 2009 +0100
> >>
> >> angstrom 2009.X: bump automake-native to 1.10.2 since some idiot deleted 1.10
> > 
> > Ah, are we in that mood again? Take more pills.
> 
> We need to have a serious discussion about deleting recipes. I know the 
> deletion of python 2.5 will force me to address the 2.5->2.6 upgrade in 
> gnuradio before the upstream developers are ready.
> 
> We need a way to remove recipes, but doing it as part of adding a new 
> recipe is causing problems for OE users.

Yes, we need to have a serious discussion about lots of things
surrounding the OpenEmbedded project, before the popularity kills the
project. Judging from the amount of interest though, I don't see that
happening -- neither short term nor long term.

-- 
:M:

Re: [oe-commits] Koen Kooi : angstrom 2009.X: bump automake-native to 1.10. 2 since some idiot deleted 1.10

[Frans Meulenbroeks]

2009/3/3 Philip Balister <philip@balister.org>:
> Michael 'Mickey' Lauer wrote:
>>
>> Am Dienstag, den 03.03.2009, 21:49 +0100 schrieb GIT User account:
>>>
>>> Module: openembedded.git
>>> Branch: org.openembedded.dev
>>> Commit: eee859a9c348871d6d644ece76bc57b151cc80e8
>>> URL:
>>>  http://gitweb.openembedded.net/?p=openembedded.git&a=commit;h=eee859a9c348871d6d644ece76bc57b151cc80e8
>>>
>>> Author: Koen Kooi <koen@openembedded.org>
>>> Date:   Tue Mar  3 21:47:57 2009 +0100
>>>
>>> angstrom 2009.X: bump automake-native to 1.10.2 since some idiot deleted
>>> 1.10
>>
>> Ah, are we in that mood again? Take more pills.
>
> We need to have a serious discussion about deleting recipes. I know the
> deletion of python 2.5 will force me to address the 2.5->2.6 upgrade in
> gnuradio before the upstream developers are ready.
>
> We need a way to remove recipes, but doing it as part of adding a new recipe
> is causing problems for OE users.
>
> Philip

Hm.
When I returned to oe 2 months ago I just created new recipes for new
versions (as was the common practice when I started my extended
vacation 2 years ago).
However at some point I stumbled upon
http://wiki.openembedded.net/index.php/Upgrading_Packages and started
using git mv (2 years ago the cumulation of recipes already became
cumbersome).
Part of the problem is that there is no good "algorithm" to decide
whether to keep the old version or not.

FM.

Re: [oe-commits] Koen Kooi : angstrom 2009.X: bump automake-native to 1.10. 2 since some idiot deleted 1.10

[Koen Kooi]

On 03-03-09 23:38, Philip Balister wrote:
> Michael 'Mickey' Lauer wrote:
>> Am Dienstag, den 03.03.2009, 21:49 +0100 schrieb GIT User account:
>>> Module: openembedded.git
>>> Branch: org.openembedded.dev
>>> Commit: eee859a9c348871d6d644ece76bc57b151cc80e8
>>> URL:
>>> http://gitweb.openembedded.net/?p=openembedded.git&a=commit;h=eee859a9c348871d6d644ece76bc57b151cc80e8
>>>
>>>
>>> Author: Koen Kooi <koen@openembedded.org>
>>> Date: Tue Mar 3 21:47:57 2009 +0100
>>>
>>> angstrom 2009.X: bump automake-native to 1.10.2 since some idiot
>>> deleted 1.10
>>
>> Ah, are we in that mood again? Take more pills.
>
> We need to have a serious discussion about deleting recipes. I know the
> deletion of python 2.5 will force me to address the 2.5->2.6 upgrade in
> gnuradio before the upstream developers are ready.
>
> We need a way to remove recipes, but doing it as part of adding a new
> recipe is causing problems for OE users.

Especially for 'core' recipes like busybox, automake and to a lesser 
extent, python.
The last time angstrom changed automake version multiple people had 
tested the the change and verified that the produced images worked as 
well as before the upgrade. That took some weeks to do. Now someone 
forced me (I didn't even look up who deleted 1.10) to used an untested 
version without asking or any heads up before the deletion.
Does this mean that I can add glibc 2.9 and delete all other versions?

regards,

Koen

Re: [oe-commits] Koen Kooi : angstrom 2009.X: bump automake-native to 1.10. 2 since some idiot deleted 1.10

[Stanislav Brabec]

Philip Balister wrote in Tue 03/03 2009 at 17:38 -0500:

> We need to have a serious discussion about deleting recipes. I know the 
> deletion of python 2.5 will force me to address the 2.5->2.6 upgrade in 
> gnuradio before the upstream developers are ready.

packages/networkmanager/netm-cli_0.2.bb use syntax like:
DEPENDS = "python (<2.6)"

> We need a way to remove recipes, but doing it as part of adding a new 
> recipe is causing problems for OE users.

Maybe we need an automatic check tool. Something like
check-if-I-can-delete-this-bb and check-if-I-can-delete-this-inc or
wipe-out-obsolete-recipes.


________________________________________________________________________
Stanislav Brabec
http://www.penguin.cz/~utx/zaurus

Re: [oe-commits] Koen Kooi : angstrom 2009.X: bump automake-native to 1.10. 2 since some idiot deleted 1.10

[Martyn Welch]

Michael 'Mickey' Lauer wrote:
> Am Dienstag, den 03.03.2009, 17:38 -0500 schrieb Philip Balister:
>> Michael 'Mickey' Lauer wrote:
>>> Am Dienstag, den 03.03.2009, 21:49 +0100 schrieb GIT User account:
>>>> Module: openembedded.git
>>>> Branch: org.openembedded.dev
>>>> Commit: eee859a9c348871d6d644ece76bc57b151cc80e8
>>>> URL:    http://gitweb.openembedded.net/?p=openembedded.git&a=commit;h=eee859a9c348871d6d644ece76bc57b151cc80e8
>>>>
>>>> Author: Koen Kooi <koen@openembedded.org>
>>>> Date:   Tue Mar  3 21:47:57 2009 +0100
>>>>
>>>> angstrom 2009.X: bump automake-native to 1.10.2 since some idiot deleted 1.10
>>> Ah, are we in that mood again? Take more pills.
>> We need to have a serious discussion about deleting recipes. I know the 
>> deletion of python 2.5 will force me to address the 2.5->2.6 upgrade in 
>> gnuradio before the upstream developers are ready.
>>
>> We need a way to remove recipes, but doing it as part of adding a new 
>> recipe is causing problems for OE users.
> 
> Yes, we need to have a serious discussion about lots of things
> surrounding the OpenEmbedded project, before the popularity kills the
> project. Judging from the amount of interest though, I don't see that
> happening -- neither short term nor long term.
> 

Ok, so if a serious discussion is out of the question, lets just have a normal discussion.

I see this issue to be partially related to the on going discussions regarding submissions. I assume that the "Commit_Policy"[1] on the wiki is either unofficial, out-of-date or optional as it states:

* Changes to core toolchain components need review (gcc, binutils, 
   libtool, pkgconfig, automake, autoconf etc.)

Where:

"Review" is defined as posting it on the mailing lists and getting positive agreement from two or more core developers. 

Now a quick check of my OpenEmbedded mail folder doesn't chuck up any messages with automake in the title that have a patch with this commit. Maybe I'm looking on the wrong mailing list.

Given that the commit policy does seem to be quite a sensible suggestion (it's part of the mechanism that seems to work quit well for the Linux kernel), maybe it needs a little bit of work to qualify it a little (which mailing list for example) and get some more links to it (for example there is no mention of a commit policy in the "adding packages"[2] section of the "Getting started guide".

If nobody objects, I will happily add the link.

Martyn

[1] http://wiki.openembedded.net/index.php/Commit_Policy
[2] http://wiki.openembedded.net/index.php/Getting_started#Adding_Packages

-- 
Martyn Welch MEng MPhil MIET (Principal Software Engineer)   T:+44(0)1327322748
GE Fanuc Intelligent Platforms Ltd,        |Registered in England and Wales
Tove Valley Business Park, Towcester,      |(3828642) at 100 Barbirolli Square,
Northants, NN12 6PF, UK T:+44(0)1327359444 |Manchester,M2 3AB  VAT:GB 729849476

Re: [oe-commits] Koen Kooi : angstrom 2009.X: bump automake-native to 1.10. 2 since some idiot deleted 1.10

[Koen Kooi]

On 04-03-09 10:59, Martyn Welch wrote:
> Michael 'Mickey' Lauer wrote:
>> Am Dienstag, den 03.03.2009, 17:38 -0500 schrieb Philip Balister:
>>> Michael 'Mickey' Lauer wrote:
>>>> Am Dienstag, den 03.03.2009, 21:49 +0100 schrieb GIT User account:
>>>>> Module: openembedded.git
>>>>> Branch: org.openembedded.dev
>>>>> Commit: eee859a9c348871d6d644ece76bc57b151cc80e8
>>>>> URL:
>>>>> http://gitweb.openembedded.net/?p=openembedded.git&a=commit;h=eee859a9c348871d6d644ece76bc57b151cc80e8
>>>>>
>>>>>
>>>>> Author: Koen Kooi <koen@openembedded.org>
>>>>> Date: Tue Mar 3 21:47:57 2009 +0100
>>>>>
>>>>> angstrom 2009.X: bump automake-native to 1.10.2 since some idiot
>>>>> deleted 1.10
>>>> Ah, are we in that mood again? Take more pills.
>>> We need to have a serious discussion about deleting recipes. I know
>>> the deletion of python 2.5 will force me to address the 2.5->2.6
>>> upgrade in gnuradio before the upstream developers are ready.
>>>
>>> We need a way to remove recipes, but doing it as part of adding a new
>>> recipe is causing problems for OE users.
>>
>> Yes, we need to have a serious discussion about lots of things
>> surrounding the OpenEmbedded project, before the popularity kills the
>> project. Judging from the amount of interest though, I don't see that
>> happening -- neither short term nor long term.
>>
>
> Ok, so if a serious discussion is out of the question, lets just have a
> normal discussion.
>
> I see this issue to be partially related to the on going discussions
> regarding submissions. I assume that the "Commit_Policy"[1] on the wiki
> is either unofficial, out-of-date or optional as it states:
>
> * Changes to core toolchain components need review (gcc, binutils,
> libtool, pkgconfig, automake, autoconf etc.)
>
> Where:
>
> "Review" is defined as posting it on the mailing lists and getting
> positive agreement from two or more core developers.
> Now a quick check of my OpenEmbedded mail folder doesn't chuck up any
> messages with automake in the title that have a patch with this commit.
> Maybe I'm looking on the wrong mailing list.

I haven't seen anything like that either, and upgrading automake *did* 
break, since a lot of apps now do 'install -s' which calls host strip :(
This is exactly why we did extensive testing the last time we touched 
automake.

regards,

Koen

Re: [oe-commits] Koen Kooi : angstrom 2009.X: bump automake-native to 1.10. 2 since some idiot deleted 1.10

[Michael 'Mickey' Lauer]

Am Mittwoch, den 04.03.2009, 09:59 +0000 schrieb Martyn Welch:
> "Review" is defined as posting it on the mailing lists and getting positive agreement from two or more core developers. 

Let me propose these kinds of patches being promoted in an unstable
branch rather than via mailing list. This eases testing and playing
around with the patch.

Although there were 0 comments (among those none in favour, but also
none against), I still think that org.oe.{stable,testing(dev),unstable}
with a strict only-cherry-picking-from-right-to-left-allowed policy
would improve our workflow and overall stability.

-- 
:M:

Re: [oe-commits] Koen Kooi : angstrom 2009.X: bump automake-native to 1.10. 2 since some idiot deleted 1.10

[Koen Kooi]

On 04-03-09 11:21, Michael 'Mickey' Lauer wrote:
> Am Mittwoch, den 04.03.2009, 09:59 +0000 schrieb Martyn Welch:
>> "Review" is defined as posting it on the mailing lists and getting positive agreement from two or more core developers.
>
> Let me propose these kinds of patches being promoted in an unstable
> branch rather than via mailing list. This eases testing and playing
> around with the patch.

Patches posted to the mailinglist get more eyes on them.

> Although there were 0 comments (among those none in favour, but also
> none against), I still think that org.oe.{stable,testing(dev),unstable}
> with a strict only-cherry-picking-from-right-to-left-allowed policy
> would improve our workflow and overall stability.

That will just boil down to people only using stable or testing, so 
unstable won't get any testing. Which means you get a false sense of 
security and get to keep the same breakages we see now.
So no, I won't support such a move.

Why are people so affraid of getting their patches reviewed on the 
mailinglist?

regards,

Koen

Re: [oe-commits] Koen Kooi : angstrom 2009.X: bump automake-native to 1.10. 2 since some idiot deleted 1.10

[Michael 'Mickey' Lauer]

Am Mittwoch, den 04.03.2009, 11:54 +0100 schrieb Koen Kooi:
> On 04-03-09 11:21, Michael 'Mickey' Lauer wrote:
> > Am Mittwoch, den 04.03.2009, 09:59 +0000 schrieb Martyn Welch:
> >> "Review" is defined as posting it on the mailing lists and getting positive agreement from two or more core developers.
> >
> > Let me propose these kinds of patches being promoted in an unstable
> > branch rather than via mailing list. This eases testing and playing
> > around with the patch.
> 
> Patches posted to the mailinglist get more eyes on them.

More eyes but less actual testing, since it involves patching your
current tree to be able to see the effects.

> > Although there were 0 comments (among those none in favour, but also
> > none against), I still think that org.oe.{stable,testing(dev),unstable}
> > with a strict only-cherry-picking-from-right-to-left-allowed policy
> > would improve our workflow and overall stability.
> 
> That will just boil down to people only using stable or testing

All but those who actually work on the branch -- which sounds like a
good thing to me, since that's what stable and testing are about.

-- 
:M:

Re: [oe-commits] Koen Kooi : angstrom 2009.X: bump automake-native to 1.10. 2 since some idiot deleted 1.10

[Koen Kooi]

On 04-03-09 12:23, Michael 'Mickey' Lauer wrote:
> Am Mittwoch, den 04.03.2009, 11:54 +0100 schrieb Koen Kooi:
>> On 04-03-09 11:21, Michael 'Mickey' Lauer wrote:
>>> Am Mittwoch, den 04.03.2009, 09:59 +0000 schrieb Martyn Welch:
>>>> "Review" is defined as posting it on the mailing lists and getting positive agreement from two or more core developers.
>>> Let me propose these kinds of patches being promoted in an unstable
>>> branch rather than via mailing list. This eases testing and playing
>>> around with the patch.
>> Patches posted to the mailinglist get more eyes on them.
>
> More eyes but less actual testing, since it involves patching your
> current tree to be able to see the effects.

The current patch reviews have picked out a lot of potential bugs just 
by looking at it, which we would loose by going branch only.

Again, why are people so affraid of posting intrusive patches for review?

>>> Although there were 0 comments (among those none in favour, but also
>>> none against), I still think that org.oe.{stable,testing(dev),unstable}
>>> with a strict only-cherry-picking-from-right-to-left-allowed policy
>>> would improve our workflow and overall stability.
>> That will just boil down to people only using stable or testing
>
> All but those who actually work on the branch -- which sounds like a
> good thing to me, since that's what stable and testing are about.

But noone would be working on it, since they have better things to do 
than play guinnea pig. I for one wouldn't be working on it.

Something like userbranches like poky has would be a better idea, people 
still get a no-holds-barred playground and when things work properly 
they can merge it, maybe asking for advice before merging.

regards,

Koen

Re: [oe-commits] Koen Kooi : angstrom 2009.X: bump automake-native to 1.10. 2 since some idiot deleted 1.10

[Martyn Welch]

Michael 'Mickey' Lauer wrote:
> Am Mittwoch, den 04.03.2009, 11:54 +0100 schrieb Koen Kooi:
>> On 04-03-09 11:21, Michael 'Mickey' Lauer wrote:
>>> Am Mittwoch, den 04.03.2009, 09:59 +0000 schrieb Martyn Welch:
>>>> "Review" is defined as posting it on the mailing lists and getting positive agreement from two or more core developers.
>>> Let me propose these kinds of patches being promoted in an unstable
>>> branch rather than via mailing list. This eases testing and playing
>>> around with the patch.
>> Patches posted to the mailinglist get more eyes on them.
> 
> More eyes but less actual testing, since it involves patching your
> current tree to be able to see the effects.
> 

But had a patch deleting multiple versions of a core package been posted to the mailing list, people would have had a chance to object. In some cases the effect that a patch will have can be quite evident enough by looking at it, the patch wouldn't necessarily have needed to actually have been applied.

Martyn

-- 
Martyn Welch MEng MPhil MIET (Principal Software Engineer)   T:+44(0)1327322748
GE Fanuc Intelligent Platforms Ltd,        |Registered in England and Wales
Tove Valley Business Park, Towcester,      |(3828642) at 100 Barbirolli Square,
Northants, NN12 6PF, UK T:+44(0)1327359444 |Manchester,M2 3AB  VAT:GB 729849476

Re: [oe-commits] Koen Kooi : angstrom 2009.X: bump automake-native to 1.10. 2 since some idiot deleted 1.10

[Martyn Welch]

Koen Kooi wrote:
> On 04-03-09 10:59, Martyn Welch wrote:
>> Michael 'Mickey' Lauer wrote:
>>> Am Dienstag, den 03.03.2009, 17:38 -0500 schrieb Philip Balister:
>>>> Michael 'Mickey' Lauer wrote:
>>>>> Am Dienstag, den 03.03.2009, 21:49 +0100 schrieb GIT User account:
>>>>>> Module: openembedded.git
>>>>>> Branch: org.openembedded.dev
>>>>>> Commit: eee859a9c348871d6d644ece76bc57b151cc80e8
>>>>>> URL:
>>>>>> http://gitweb.openembedded.net/?p=openembedded.git&a=commit;h=eee859a9c348871d6d644ece76bc57b151cc80e8 
>>>>>>
>>>>>>
>>>>>>
>>>>>> Author: Koen Kooi <koen@openembedded.org>
>>>>>> Date: Tue Mar 3 21:47:57 2009 +0100
>>>>>>
>>>>>> angstrom 2009.X: bump automake-native to 1.10.2 since some idiot
>>>>>> deleted 1.10
>>>>> Ah, are we in that mood again? Take more pills.
>>>> We need to have a serious discussion about deleting recipes. I know
>>>> the deletion of python 2.5 will force me to address the 2.5->2.6
>>>> upgrade in gnuradio before the upstream developers are ready.
>>>>
>>>> We need a way to remove recipes, but doing it as part of adding a new
>>>> recipe is causing problems for OE users.
>>>
>>> Yes, we need to have a serious discussion about lots of things
>>> surrounding the OpenEmbedded project, before the popularity kills the
>>> project. Judging from the amount of interest though, I don't see that
>>> happening -- neither short term nor long term.
>>>
>>
>> Ok, so if a serious discussion is out of the question, lets just have a
>> normal discussion.
>>
>> I see this issue to be partially related to the on going discussions
>> regarding submissions. I assume that the "Commit_Policy"[1] on the wiki
>> is either unofficial, out-of-date or optional as it states:
>>
>> * Changes to core toolchain components need review (gcc, binutils,
>> libtool, pkgconfig, automake, autoconf etc.)
>>
>> Where:
>>
>> "Review" is defined as posting it on the mailing lists and getting
>> positive agreement from two or more core developers.
>> Now a quick check of my OpenEmbedded mail folder doesn't chuck up any
>> messages with automake in the title that have a patch with this commit.
>> Maybe I'm looking on the wrong mailing list.
> 
> I haven't seen anything like that either, and upgrading automake *did* 
> break, since a lot of apps now do 'install -s' which calls host strip :(
> This is exactly why we did extensive testing the last time we touched 
> automake.
> 

TBH, I think that the commit policy seems to have evolved over time to include a number of tips as well as policies.

Rolf: it seems that you are the maintainer of this part of the wiki. Would you please consider the following version which I have re-ordered to try and bring greater clarity to what requires a review, what requires the consultation of the maintainer or interested party and what are tips rather than policy?:

----

Making changes to the core infrastructure can impact many other users and
developers. Whilst we don't want to discourage people hacking on and improving
the core infrastructure, more care is needed in those areas compared to recipes
with no dependants.

Above all else, commits are based on a gentleman's agreement. The following
rules are not hard fast rules and the changes a developer is allowed to commit
without review will depend on their experience. Anyone found to be committing
inappropriate changes could have their access to the repository revoked (at 
the discression of the core team).

More draconian review and commit policies may exist for topic branches, such as
the stable branch. Should these policies exist, they should be documented in a
README file in the root of the branch or a link provided in the README to the
location of the policies.

Developers without commit access should post their changes as patches to the
OpenEmbedded Developer mailing list (openembedded-devel@openembedded.org).

The following changes require a review:

  * Changes to class files (classes/*)
  * Changes to global .conf files (e.g. bitbake.conf)
  * Changes to core toolchain components (gcc, binutils, 
    libtool, pkgconfig, automake, autoconf, etc.)

A "review" is defined as posting the proposed change as a patch to the
OpenEmbedded Developer mailing list (OpenEmbedded-Devel) and receiving agreement
from two or more core developers.

Where present, the apropriate maintainer should be consulted before the
following changes are made:

  * Machine configs (machine maintainer)
  * Distro configs (distribution maintainer)
  * Recipes (recipe maintainer)

It's fine to fix a recipe you don't maintain, however an attempt should be made
to contact anyone else actively maintaining that recipe (the git logs show when
and who made changes to the file in question). Try to contact the maintainer, if
contact details can not be found (see MAINTAINERS), send a note to the
OpenEmbedded Developer mailing list. 

Please try to comply with the following rules when committing changes to
OpenEmbedded:

  * Split your changes into their logical subparts. It's easier to track down
    problems afterwards when developers have stuck to the "one change, one
    patch" approach. This also makes it possible to cherrypick suitable changes
    into other branches (such as a stable branch).

  * Provide a clear commit message (see the [[commit log example|example]]):
     - The first line of commit is a summary of the changes and start with the
       name of the affected recipe.
     - Provide concise details of the change made and it's affect as
       appropriate.
     - If appropriate, mention the bug number(s) that the patch resolves.
     - Give credit where credit is due. If you commit someone else's work more
       or less verbatim, you should use ''git commit --author $mail-of-author''.
       If pulling changes from somewhere like Poky or OpenMoko there is no
       problem with that but mention where the changes came from.
     - Include a Signed-off-by: line to provide the commit with a valid
       certificate of origin [http://lwn.net/Articles/139916/ as per the Linux kernel]

Other tips for making good commits:

  * Think twice before using an override, usually overrides can be 
    avoided, especially ones like this:
 
      do_compile() {
          oe_runmake
      } 
 
      do_compile_myfirstdisto() {
          oe_runmake -D_GNU_SOURCE
      }
 
    In 99% of the cases your fix will resolve issues in other distros rather
    than breaking them. An override will only resolve the issue for a subset of
    users, forcing others to duplicate the effort of resolving the problem.  

    If an override is really needed, its probably useful to document why its
    been added and why most people wouldn't want to use it.

  * If working in your own branch, sync early, sync often. Nobody likes to
    reinvent the wheel. Merging is easy with git, so don't hesitate to run sync
    just before your plane takes off and your wifi gets disconnected.


-- 
Martyn Welch MEng MPhil MIET (Principal Software Engineer)   T:+44(0)1327322748
GE Fanuc Intelligent Platforms Ltd,        |Registered in England and Wales
Tove Valley Business Park, Towcester,      |(3828642) at 100 Barbirolli Square,
Northants, NN12 6PF, UK T:+44(0)1327359444 |Manchester,M2 3AB  VAT:GB 729849476

Re: [oe-commits] Koen Kooi : angstrom 2009.X: bump automake-native to 1.10. 2 since some idiot deleted 1.10

[GNUtoo]

> Again, why are people so affraid of posting intrusive patches for review?
I usually ask for review on the mailing list when I am told to do so or
I know I really have to.
The reason for it is that I usually ask for some hints or some help on
IRC Before asking on the mailing-list.
Often I also ask stupid questions on IRC,then find the answer myself.
that clearly do not belongs to the mailing-list.
Denis.

Re: [oe-commits] Koen Kooi : angstrom 2009.X: bump automake-native to 1.10. 2 since some idiot deleted 1.10

[Philip Balister]

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

Martyn Welch wrote:
> Michael 'Mickey' Lauer wrote:
>> Am Mittwoch, den 04.03.2009, 11:54 +0100 schrieb Koen Kooi:
>>> On 04-03-09 11:21, Michael 'Mickey' Lauer wrote:
>>>> Am Mittwoch, den 04.03.2009, 09:59 +0000 schrieb Martyn Welch:
>>>>> "Review" is defined as posting it on the mailing lists and getting 
>>>>> positive agreement from two or more core developers.
>>>> Let me propose these kinds of patches being promoted in an unstable
>>>> branch rather than via mailing list. This eases testing and playing
>>>> around with the patch.
>>> Patches posted to the mailinglist get more eyes on them.
>>
>> More eyes but less actual testing, since it involves patching your
>> current tree to be able to see the effects.
>>
> 
> But had a patch deleting multiple versions of a core package been posted 
> to the mailing list, people would have had a chance to object. In some 
> cases the effect that a patch will have can be quite evident enough by 
> looking at it, the patch wouldn't necessarily have needed to actually 
> have been applied.

I think both approaches have merit. Patches sent to the list get more 
exposure, but there are some changes that will benefit from preparing 
the change in a branch so it is easier for people to do some tests.

Mickey's suggestion may even work well with patches reviewed on the 
list. I need to read his email when I am not trying to get on a plane :)

Philip

[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/x-pkcs7-signature, Size: 3303 bytes --]

Re: [oe-commits] Koen Kooi : angstrom 2009.X: bump automake-native to 1.10. 2 since some idiot deleted 1.10

[Philip Balister]

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

Martyn Welch wrote:
> Koen Kooi wrote:
>> On 04-03-09 10:59, Martyn Welch wrote:
>>> Michael 'Mickey' Lauer wrote:
>>>> Am Dienstag, den 03.03.2009, 17:38 -0500 schrieb Philip Balister:
>>>>> Michael 'Mickey' Lauer wrote:
>>>>>> Am Dienstag, den 03.03.2009, 21:49 +0100 schrieb GIT User account:
>>>>>>> Module: openembedded.git
>>>>>>> Branch: org.openembedded.dev
>>>>>>> Commit: eee859a9c348871d6d644ece76bc57b151cc80e8
>>>>>>> URL:
>>>>>>> http://gitweb.openembedded.net/?p=openembedded.git&a=commit;h=eee859a9c348871d6d644ece76bc57b151cc80e8 
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Author: Koen Kooi <koen@openembedded.org>
>>>>>>> Date: Tue Mar 3 21:47:57 2009 +0100
>>>>>>>
>>>>>>> angstrom 2009.X: bump automake-native to 1.10.2 since some idiot
>>>>>>> deleted 1.10
>>>>>> Ah, are we in that mood again? Take more pills.
>>>>> We need to have a serious discussion about deleting recipes. I know
>>>>> the deletion of python 2.5 will force me to address the 2.5->2.6
>>>>> upgrade in gnuradio before the upstream developers are ready.
>>>>>
>>>>> We need a way to remove recipes, but doing it as part of adding a new
>>>>> recipe is causing problems for OE users.
>>>>
>>>> Yes, we need to have a serious discussion about lots of things
>>>> surrounding the OpenEmbedded project, before the popularity kills the
>>>> project. Judging from the amount of interest though, I don't see that
>>>> happening -- neither short term nor long term.
>>>>
>>>
>>> Ok, so if a serious discussion is out of the question, lets just have a
>>> normal discussion.
>>>
>>> I see this issue to be partially related to the on going discussions
>>> regarding submissions. I assume that the "Commit_Policy"[1] on the wiki
>>> is either unofficial, out-of-date or optional as it states:
>>>
>>> * Changes to core toolchain components need review (gcc, binutils,
>>> libtool, pkgconfig, automake, autoconf etc.)
>>>
>>> Where:
>>>
>>> "Review" is defined as posting it on the mailing lists and getting
>>> positive agreement from two or more core developers.
>>> Now a quick check of my OpenEmbedded mail folder doesn't chuck up any
>>> messages with automake in the title that have a patch with this commit.
>>> Maybe I'm looking on the wrong mailing list.
>>
>> I haven't seen anything like that either, and upgrading automake *did* 
>> break, since a lot of apps now do 'install -s' which calls host strip :(
>> This is exactly why we did extensive testing the last time we touched 
>> automake.
>>
> 
> TBH, I think that the commit policy seems to have evolved over time to 
> include a number of tips as well as policies.
> 
> Rolf: it seems that you are the maintainer of this part of the wiki. 
> Would you please consider the following version which I have re-ordered 
> to try and bring greater clarity to what requires a review, what 
> requires the consultation of the maintainer or interested party and what 
> are tips rather than policy?:
> 
> ----
> 
> Making changes to the core infrastructure can impact many other users and
> developers. Whilst we don't want to discourage people hacking on and 
> improving
> the core infrastructure, more care is needed in those areas compared to 
> recipes
> with no dependants.
> 
> Above all else, commits are based on a gentleman's agreement. The following
> rules are not hard fast rules and the changes a developer is allowed to 
> commit
> without review will depend on their experience. Anyone found to be 
> committing
> inappropriate changes could have their access to the repository revoked 
> (at the discression of the core team).
> 
> More draconian review and commit policies may exist for topic branches, 
> such as
> the stable branch. Should these policies exist, they should be 
> documented in a
> README file in the root of the branch or a link provided in the README 
> to the
> location of the policies.
> 
> Developers without commit access should post their changes as patches to 
> the
> OpenEmbedded Developer mailing list (openembedded-devel@openembedded.org).
> 
> The following changes require a review:
> 
>  * Changes to class files (classes/*)
>  * Changes to global .conf files (e.g. bitbake.conf)
>  * Changes to core toolchain components (gcc, binutils,    libtool, 
> pkgconfig, automake, autoconf, etc.)
> 
> A "review" is defined as posting the proposed change as a patch to the
> OpenEmbedded Developer mailing list (OpenEmbedded-Devel) and receiving 
> agreement
> from two or more core developers.
> 
> Where present, the apropriate maintainer should be consulted before the
> following changes are made:
> 
>  * Machine configs (machine maintainer)
>  * Distro configs (distribution maintainer)
>  * Recipes (recipe maintainer)
> 
> It's fine to fix a recipe you don't maintain, however an attempt should 
> be made
> to contact anyone else actively maintaining that recipe (the git logs 
> show when
> and who made changes to the file in question). Try to contact the 
> maintainer, if
> contact details can not be found (see MAINTAINERS), send a note to the
> OpenEmbedded Developer mailing list.
> Please try to comply with the following rules when committing changes to
> OpenEmbedded:
> 
>  * Split your changes into their logical subparts. It's easier to track 
> down
>    problems afterwards when developers have stuck to the "one change, one
>    patch" approach. This also makes it possible to cherrypick suitable 
> changes
>    into other branches (such as a stable branch).
> 
>  * Provide a clear commit message (see the [[commit log example|example]]):
>     - The first line of commit is a summary of the changes and start 
> with the
>       name of the affected recipe.
>     - Provide concise details of the change made and it's affect as
>       appropriate.
>     - If appropriate, mention the bug number(s) that the patch resolves.
>     - Give credit where credit is due. If you commit someone else's work 
> more
>       or less verbatim, you should use ''git commit --author 
> $mail-of-author''.
>       If pulling changes from somewhere like Poky or OpenMoko there is no
>       problem with that but mention where the changes came from.
>     - Include a Signed-off-by: line to provide the commit with a valid
>       certificate of origin [http://lwn.net/Articles/139916/ as per the 
> Linux kernel]
> 
> Other tips for making good commits:
> 
>  * Think twice before using an override, usually overrides can be    
> avoided, especially ones like this:
> 
>      do_compile() {
>          oe_runmake
>      }
>      do_compile_myfirstdisto() {
>          oe_runmake -D_GNU_SOURCE
>      }
> 
>    In 99% of the cases your fix will resolve issues in other distros rather
>    than breaking them. An override will only resolve the issue for a 
> subset of
>    users, forcing others to duplicate the effort of resolving the problem. 
>    If an override is really needed, its probably useful to document why its
>    been added and why most people wouldn't want to use it.
> 
>  * If working in your own branch, sync early, sync often. Nobody likes to
>    reinvent the wheel. Merging is easy with git, so don't hesitate to 
> run sync
>    just before your plane takes off and your wifi gets disconnected.
> 
> 

+1

Philip

[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/x-pkcs7-signature, Size: 3303 bytes --]

Re: [oe-commits] Koen Kooi : angstrom 2009.X: bump automake-native to 1.10. 2 since some idiot deleted 1.10

[Otavio Salvador]

Koen Kooi <k.kooi@student.utwente.nl> writes:

> On 04-03-09 11:21, Michael 'Mickey' Lauer wrote:
>> Am Mittwoch, den 04.03.2009, 09:59 +0000 schrieb Martyn Welch:
>>> "Review" is defined as posting it on the mailing lists and getting positive agreement from two or more core developers.
>>
>> Let me propose these kinds of patches being promoted in an unstable
>> branch rather than via mailing list. This eases testing and playing
>> around with the patch.
>
> Patches posted to the mailinglist get more eyes on them.
>
>> Although there were 0 comments (among those none in favour, but also
>> none against), I still think that org.oe.{stable,testing(dev),unstable}
>> with a strict only-cherry-picking-from-right-to-left-allowed policy
>> would improve our workflow and overall stability.
>
> That will just boil down to people only using stable or testing, so
> unstable won't get any testing. Which means you get a false sense of
> security and get to keep the same breakages we see now.
> So no, I won't support such a move.
>
> Why are people so affraid of getting their patches reviewed on the
> mailinglist?

[...]

I'm on same page as you Koen. I also disagree the idea of having a
branch. A project like OE that takes too long to test some kind of
patches does need a human review before even thinking about pushing a
patch against a core component.

-- 
Otavio Salvador                  O.S. Systems
E-mail: otavio@ossystems.com.br  http://www.ossystems.com.br
Mobile: +55 53 9981-7854         http://projetos.ossystems.com.br

Re: [oe-commits] Koen Kooi : angstrom 2009.X: bump automake-native to 1.10. 2 since some idiot deleted 1.10

[Otavio Salvador]

Michael 'Mickey' Lauer <mickey@vanille-media.de> writes:

> Am Mittwoch, den 04.03.2009, 11:54 +0100 schrieb Koen Kooi:
>> On 04-03-09 11:21, Michael 'Mickey' Lauer wrote:
>> > Am Mittwoch, den 04.03.2009, 09:59 +0000 schrieb Martyn Welch:
>> >> "Review" is defined as posting it on the mailing lists and getting positive agreement from two or more core developers.
>> >
>> > Let me propose these kinds of patches being promoted in an unstable
>> > branch rather than via mailing list. This eases testing and playing
>> > around with the patch.
>> 
>> Patches posted to the mailinglist get more eyes on them.
>
> More eyes but less actual testing, since it involves patching your
> current tree to be able to see the effects.
>
>> > Although there were 0 comments (among those none in favour, but also
>> > none against), I still think that org.oe.{stable,testing(dev),unstable}
>> > with a strict only-cherry-picking-from-right-to-left-allowed policy
>> > would improve our workflow and overall stability.
>> 
>> That will just boil down to people only using stable or testing
>
> All but those who actually work on the branch -- which sounds like a
> good thing to me, since that's what stable and testing are about.

I belive this can be fixed using a merge window and using a pull based
model.

Instead of we do pushes against devel branch, core devels could do the
pull and we could have a -next tree the pulls automatically and reports
conflicts by mail. This is more or less what is done in Linux nowadays.

-- 
Otavio Salvador                  O.S. Systems
E-mail: otavio@ossystems.com.br  http://www.ossystems.com.br
Mobile: +55 53 9981-7854         http://projetos.ossystems.com.br