Field "Upstream Status" in patch headers
n-roeser at gmx.net
Tue Aug 17 11:38:21 PDT 2004
-----BEGIN PGP SIGNED MESSAGE-----
Matthew Burgess wrote:
> * "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
Another reason is hacks. I am thinking of patches that fix the build of
a package, but are definitely wrong and should never be merged
upstream. For example some of those freetype patc^H^H^H^Hhacks we
If we do not allow such hacks, we must make all patches technically
correct (which is worthwile anyway!) or take the solutions from
upstream and convert them to patches. This may result in several
packages re-running the autotools (libtoolize, automake, autoconf)
automatically, or in packages where we must do this manually. Even
though this is the correct way to handle things, we might hit version
incompatibilities, because LFS normally uses one of the most recent and
some packages use ancient versions of the autotools.
My personal opinion is that we should always patch things "the Right
Way", and run the autotools if necessary. Sending a report of "please
upgrade your autotools" to upstream maintainers could also be counted
as a way of improving package quality and helping the community. ;-)
> 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.
You could have a patch that works, but you are unsure whether it is
Hmm... No, that doesn't warrant "Not submitted".
You're right; in that case you should submit it and wait for feedback.
If it's wrong, you'll probably get a better solution from upstream. If
it's right, the patch will be accepted/merged upstream, or they'll
improve it and merge the result.
> 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.
Fully agreed, that's the Right Thing to do. :-) Various projects are
presented with a wide base of testers through LFS. We shouldn't keep
our results to ourselves.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)
-----END PGP SIGNATURE-----
More information about the patches