[OE-core] [PATCH 02/16] slang: Fix namespace conflict vis-a-vis posix_close

[Khem Raj]

> On Sep 9, 2015, at 3:23 AM, alexander.kanavin at linux.intel.com wrote:
> 
>>> +Exposed while compiling on musl
>>> +
>>> +Signed-off-by: Khem Raj <raj.khem at gmail.com>
>>> +---
>>> +Upstream-Status: Pending
>> 
>> If this has been submitted upstream (as you say in the cover letter for
>> this patchset), please provide a link for the submission in the
>> upstream-status. We can't afford to let the amount of 'Pending' patches in
>> oe-core grow indefinitely.
>> 
>> Same goes for other patches in this set.
> 
> 
> Actually scratch the above, it was too hasty. What I really wanted to say
> is that, ideally, you should first submit the patches upstream, have a
> prooflink of that, and only then send them here with that proof in the
> upstream-status. There are already too many eternal 'Pending' patches in
> oe-core that never made it to upsream. We can't afford more of them.

There is process for that. The upstreaming of a patch is an independent thing thats why pending status
is agreed upon probably it predates you in OE contributor's community.
since it deals with different community, and usually we carry a patch for a release or two
and then it gets merged or redone and we drop it. Many a times with recipe upgrades you will
see patches get dropped for these reasons. As integrators, the engagement of rule is a bit different for us. since every component community has its own interworking and nature, this way we make progress while upstreaming takes its own course. This process is followed by all major distro’s as well including OE.
Now if we want to step ahead and change a policy to first submit patch upstream then it will be accepted in OE
thats a fine idea, however that requires a wider discussion community wide and also needs tools to reject
patches with out upstream submission. It also has downside where a distro developer may not participate upstream
and hence with not enough momentum things will stall and people may prefer to carry own forks, so we have
to make it less burdensome. We can not go by grey area where we say this patch should be first submitted upstream and this we can accept without submission since that will put extra burden on maintainers of OE for deciding on code thats they may not be experts in.

So I encourage you to formulate a policy and make a proposal to community and get everyone on board in changing
the policy OE wide.

Cheers
-Khem

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 204 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.openembedded.org/pipermail/openembedded-core/attachments/20150909/a7b0f89b/attachment-0002.sig>