From: Darren Hart <dvhart@linux.intel.com>
To: Philip Balister <philip@balister.org>
Cc: Paul Eggleton <paul.eggleton@linux.intel.com>,
Koen Kooi <koen@dominion.thruhere.net>,
Patches and discussions about the oe-core layer
<openembedded-core@lists.openembedded.org>,
"Garman, Scott A" <scott.a.garman@intel.com>
Subject: Re: Stable Release Process
Date: Mon, 03 Jun 2013 09:22:57 -0700 [thread overview]
Message-ID: <51ACC2E1.9000206@linux.intel.com> (raw)
In-Reply-To: <51AC7B73.8040005@balister.org>
On 06/03/2013 04:18 AM, Philip Balister wrote:
> On 06/03/2013 02:00 AM, Koen Kooi wrote:
>>
>> Op 31 mei 2013, om 19:44 heeft Darren Hart <dvhart@linux.intel.com> het volgende geschreven:
>>>> I like subject tags, at least because they are nicely shown in
>>>> patchwork subject, so I can easily sort incoming patches to right
>>>> bundles.
>>>>
>>>> And this problem with scaling when sending a patch for multiple
>>>> releases we already have when tagging multiple affected layers
>>>> (which happens more often for meta-oe layers then multiple
>>>> releases).
>>>
>>> It has been expressed that this has been challenging to enforce
>>> (anything that is freeform is). Do you have any suggestions on how we
>>> could address that? Documentation? Firm maintainer policy of willfully
>>> ignoring non-tagged patches?
>>
>> An email saying "wrong tag, please read README and resubmit"
>> followed by willfully ignoring wrong tags has worked quite well in
>> the past. But only if the README clearly states the tags needed and
>> has a sample git-send-email cmdline.
>
> I find the sample git send-email line in the README to be a huge
> help for me.
>
> Philip
>
In my experience with this project and our maintainers, they are
exceptionally good-natured and eager to help compared to some other
projects. There would definitely be a painful period as they tried to
resist reminding people and just pulling the patch in anyway. I think it
could work, but we would have to be firm about it and document it well.
Some kind of a stable-release.txt README is definitely in order.
I went to check oe-core for some kind of existing documentation on
policies and came up empty. Perhaps just documenting this
pseudo-existing policy in a place where developers are likely to find it
and can be easily referred to would be a good first step.
--
Darren Hart
Intel Open Source Technology Center
Yocto Project - Technical Lead - Linux Kernel
prev parent reply other threads:[~2013-06-03 16:22 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-04-24 17:32 Stable Release Process Darren Hart
2013-05-31 16:34 ` Paul Eggleton
2013-05-31 17:27 ` Darren Hart
2013-05-31 17:34 ` Martin Jansa
2013-05-31 17:44 ` Darren Hart
2013-06-03 6:00 ` Koen Kooi
2013-06-03 11:18 ` Philip Balister
2013-06-03 16:22 ` Darren Hart [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=51ACC2E1.9000206@linux.intel.com \
--to=dvhart@linux.intel.com \
--cc=koen@dominion.thruhere.net \
--cc=openembedded-core@lists.openembedded.org \
--cc=paul.eggleton@linux.intel.com \
--cc=philip@balister.org \
--cc=scott.a.garman@intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.