[oe] [oe-commits] Koen Kooi : angstrom 2009.X: bump automake-native to 1.10. 2 since some idiot deleted 1.10
Philip Balister
philip at balister.org
Wed Mar 4 15:43:30 UTC 2009
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 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.
>
>
+1
Philip
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3303 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.openembedded.org/pipermail/openembedded-devel/attachments/20090304/ef647844/attachment-0002.bin>
More information about the Openembedded-devel
mailing list