[OE-core] [PATCH] mtd-utils: remove double hashtable iterator definition

[Burton, Ross]

On 19 January 2018 at 14:23, Oleg Kokorin <ole2mail at mail.com> wrote:

> hello Ross
>
> the whole patch supply procedure these days is completely messed-up IMHO.
>
> if I'm not sending to upstream, then why the damn patch being e-mailed? or
> perhaps
> just because I can't understand the difference in between "pending"
> (where?), "submitted" (definitely is),
> "accepted" (by who?), "backport" (to where?), "denied" (do you really
> assume someone will push the patch with the flag "denied" in it?
>
> you've added too much complexity requirements to apply inside the patch
> file.
> how could I know what means for you "sending or not" to upstream?
>
> from the wiki point, it's completely unclear what kind of status should I
> apply for the patch by default.
> https://www.openembedded.org/wiki/Commit_Patch_Message_Guidelines
> so what do you want for "Upstream-Status:" instead of pending?
>

"Upstream" in distribution-builder-land means "the maintainer of the
package that I'm trying to build".  So in this case, the mtd-utils
maintainers.  If you've got a patch and cannot  be bothered to submit it
upstream, Pending is correct. Submitted means you've submitted it to the
maintainers.  Accepted means they've accepted it.  Backport means you've
backported the patch from the upstream source.  Denied means upstream have
refused the patch but we need it for some reason.


> and by the way, a robot refused my patch again, because it's not in sync
> with whatever the new stuff is in.
> if "git pull --rebase" is not enough, it would be WAY better to mention
> this command specifically in the WIKI about.
> I see a lot of completely useless text in the wiki but it helped not at
> all to push the patch an easy and more important the fast way.
>

That should be sufficient, I can confirm that your patch doesn't apply to
master, and the last time this file was modified was in December, so maybe
you're not working from the right branch?

and, GIT know's well who is signign and what is the commit message, so if
> you need patches with the git log attached ahead of each, why not to
> mention in wiki special command about injecting log message inside patch
> file. this definitely will simplify patches submission.
>

It's entirely appropriate for the patch to have a much longer explanatory
message than the commit.  Also I can send a patch to oe-core which contains
a patch that someone else has authored, in which case copying it
automatically wouldn't be correct.

All we're asking is that any patches added say what they do, if they're
upstream, and who wrote it.

Ross
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openembedded.org/pipermail/openembedded-core/attachments/20180119/261fca46/attachment-0002.html>