Field "Upstream Status" in patch headers
matthew at linuxfromscratch.org
Tue Aug 17 10:59:32 PDT 2004
On Tue, 17 Aug 2004 11:43:55 +0200
"Nico R." <n-roeser at gmx.net> wrote:
> The page <URL:http://www.linuxfromscratch.org/patches/submit.html>
> lists the field "Upstream Status" as mandatory.
> I am often unsure what to use as value for this field, and I think it
> might be valuable if we made some *suggestions* on that web page. For
> example, we could define the following values:
> * Do not submit
> * Not submitted
> * Submitted
> * Not Accepted
> * Accepted
> * Merged
FWIW I'd agree on some guidelines like the above. I'd prefer something
like the following though:
* "Do Not Submit" + a very good reason why it shouldn't be submitted.
The only reason I can think of at the moment is that it implements
behaviour peculiar to LFS/BLFS, e.g. the gcc specs & no_fixincludes
* "Submitted - awaiting feedback" - The author has submitted the patch
but upstream hasn't responded to it yet. A link to the appropriate
mailing list thread would be useful here, so that progress can be
tracked by anyone interested in doing so.
* "Submitted - not accepted" + the reason that upstream gave for not
including it. Again, a mailing list URL may be useful in this
* "Submitted - accepted" + date of acceptance and corresponding link to
mailing list archives. Dependent on the responsiveness of the upstream
devs then the patch may go straight to...
* "Submitted - merged" + date of merge into upstream sources (with
appropriate link to mailing list message, if they have a CVS/SVN/SCM
commit related list).
I don't think that "Not submitted" should be permitted. A patch should
either be submitted, or should qualify for "Do not submit" status IMO.
I don't see any reason, apart from laziness and/or not having the
courage of your convictions, why a patch shouldn't be submitted if it's
not particular to LFS/BLFS ways of doing things. All of these projects
provide us with the means by which we can put our books together, the
least we can do is give them something back in the way of patches.
More information about the patches