On Thu, 2015-11-12 at 22:00 +0100, Stefan Seyfried wrote:
I don't think anyone will be able to explain to me how a patch tag in the spec file increases the package quality when I already have a full
FUD ! Once and for all: PATCH TAGS ARE NOT MANDATORY. They CAN be a help for the package maintainer if the use it properly. https://en.opensuse.org/openSUSE:Packaging_Patches_guidelines lists two variants of patch markup: * in the spec file * in the .patch itself. it is REALLY a good idea to at least do ONE of them... if you use git- formatted patches, the 2nd part is already given. A description of what that commit does should be naturally required on all serious upstream projects If you think this info is not needed, I am sure I can find examples to challenge you what a patch is good for - especially if it was there for 2 years without explanation why it was added, what bug/error it tried to address. Don't live for the moment and for yourself: live for the future and consider that other people might not have all the info in their head as you do.
fledged patch header in the patch itself (and I'm the only contributor anyway).
I hope you can never guarantee that you're the only contributor.
Before fighting such windmills (having perfectly good packages rejected just because of missing patch tags, but all the others that depend on the rejected one checked in and thus being broken was a frequenc encounter), I prefer to simply keep stuff out of Factory.
FUD (I could repeat above statement.. but I guess it's clear that PATCH TAG LINES in the spec are NOT MANDATORY
(I'm not questioning that there are projects like GNOME:Factory or whatever, where people like patch tags and find them useful, but for me they are just annoying).
so don't use them - but make sure it's clear what the patch does in one way or another (patch description inside the .patch file for example)
The only mandatory policy in that regard is to mention added or removed patches in the .changes file in order to be able to track them.
And even this is often questionable when it is only the obvouis post-release build fix which was already accepted upstream and will automatically be removed next version update because it will only reverse apply anyway.
If you object that much adding a simple statement that you added a patch: ask upstream to release a build fix brown paper bag release - if they can't manage release tarballs to build properly, I'm sure a quick fix release should not be an issue (yes, I've seen such cases as well and in no case did I have an issue to convince an upstream to re- release a fixed tarball)
It's nice to have lots of policies to enforce and give people the power to reject the work of others, but don't be surprised if those othere decide to spend their time on more rewarding projects :-
/you really misunderstand the use of the guidelines - they are not there to give the power to reject - like in every review process, they are there to give a sort of consistency across the board. Try to submit a fix to any serious upstream.. you will get stuff rejected for using "main();" instead of "main ();" (or vice-versa) So far, we do not have a 'no white space policy enforced in Factory' Dominique -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org