[oe] [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 at 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 at 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