[OE-core] [PATCH] meta/recipes-core/base-passwd/base-passwd/noshadow.patch: Split it into two parts

[Martin Jansa]

On Sat, Feb 08, 2014 at 12:20:15PM +0000, Richard Purdie wrote:
> On Sat, 2014-02-08 at 12:07 +0000, Laszlo Papp wrote:
> > Why is it a nightmare? For instance, maintainers in other projects
> > leave a "Pushed, thanks" note.
> > 
> > See how much discussion this generates already, instead of two words.
> > While you are at the change to merge it, you are already in place to
> > leave the comment. However, contributors need to go and find the
> > corresponding url, etc. Please note that contributors may want to know
> > whether their voluntary work got merged without even a checkout, for
> > instance double checking from mobile, etc.
> > 
> > ... or is the real problem the lack of maintainer man power?
> 
> Its both a man power problem and the process isn't as simple as
> described. 
> 
> The changes get batched together into large units, those get tested on
> the autobuilder. If they work out ok, the changes go in, if they fail,
> we pull out patches until we get a successful batch, then merge.
> 
> Upon failures, we do aim to mention those on list. Having to go back
> through emails to find the ones which merge and "ack" them is a pain
> though since we are "not already in place" as you put it.
> 
> There are only two people in general who do this on OE-Core, myself and
> Saul. We do have a ton of other pressures on our time, we do the best we
> can. If someone wants to ack patches that merge I'm happy for them to do
> so, it would be just as much work for them as it would for me/Saul.
> 
> I am aware there are patch management tools out there which can show
> status of patches. We've looked hard at them and in general they impose
> more overhead and process onto people who don't want it.

FWIW: for meta-oe I still use patchwork
(http://patchwork.openembedded.org/) the main advantage for me as
maintainer is that I can split incoming patches into different bundles
(categories) and leave some bundles for sublayers with own dedicated
maintainer for him to handle them.

The hook for automatic "Accepted" flag quite often doesn't close right
patch or doesn't close anything at all and contributers very rarely
update their own patches as well (e.g. when they send v2 they almost
never mark v1 as superseded) so the overall benefit from patchwork is
quite low, but still better than nothing for me.

From contributor POV I don't see need for "ack/Pushed" e-mail, I rebase all
my local changes quite often, so when some are merged I'll notice that
they are gone from my local branch. When some patch is stuck there for
very long time, it's again easy to spot this and send reminder on that
patch email. Another advantage of rebasing my submitted patches is that
I'll see if my patch was modified prior to merge or when older revision
of the patch was merged and rebase leaves me with some significant delta
between v1 and v2 which I can easily submit as incremental patch.

-- 
Martin 'JaMa' Jansa     jabber: Martin.Jansa at gmail.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://lists.openembedded.org/pipermail/openembedded-core/attachments/20140208/4e89439c/attachment-0002.sig>