On 08-08-2022 23:51, Andreas Enge wrote:
Hello,Am Fri, Aug 05, 2022 at 03:59:14PM +0200 schrieb Maxime Devos:Here's a v2. I've changed the structure to something close to what Julien proposed, it looks a lot better now to me!thanks, it does! I still find it a bit too verbose compared to Liliana's suggestion, which I would prefer as a starting point of the discussion.
WDYM with 'still' here? The v2 patch I sent preceded Liliana's patch. I'm not seeing a 'too verbose'-ity or a difference in verbosity myself --- Something I liked about Julien's proposed structure is:
-- i.e., if I want to do $FOO, I could quickly find out how to do it. In the v2 I sent, this was reflected in the subsections, each subsection is a 'howto $FOO'. Whereas the patch Liliana sent is kind of the inverse -- each @item corresponds to a 'what can the method $FOO be used for'. Similarly, in the v1 I sent, I followed a similar structure (an item for patches, an item for snippets, an item for phases).[...] derive rules for specific cases, based on these principles: How do I remove non-free software? -> snippet because … How do I remove bundled libraries? -> snippet or phase because …How do I fix a build issue? -> patch or snippet if this affects building from source, can also be a phase if the result of --sources can still buildA test issue? …This leaves some cases up to interpretation, but that's probably not so different from "it's not an absolute rule". It's also much clearer and quicker to figure out in which case you are. If not documented as a case, you can fall back to the general principles.
As such, the v2 I sent seems a better basis to me. Greetings, Maxime.
OpenPGP_0x49E3EE22191725EE.asc
Description: OpenPGP public key
OpenPGP_signature
Description: OpenPGP digital signature
