Re: RFC: Rules for distro-friendly packages
Enrico Weigelt writes ("Re: RFC: Rules for distro-friendly packages"):
> Ian Jackson <ijackson@chiark.greenend.org.uk> schrieb:
> > We aren't in a position to dictate to upstream.
>
> No, we aren't. But we (as downstreams) can define rules on what we
> consider a good package engineering - if upstream cannot / doesnt
> want to follow the rules, OSS-QM can step in as man-in-the-middle ;-p
"Rules" is just wrong. "Guidelines" might be appropriate, but I would
suggest "Recommendations".
Perhaps I'm just getting hung up on individual words here, but words
are very important to tone. In English if you say "rules" you
generally mean something that /must/ be followed. Writing up a set of
_rules_ is only appropriate when you are in a position of authority in
relation to the subject matter (eg, you are the designer of a game, or
the person in charge of a government department, or whatever).
If you are _not_ in a position of authority, then behaving as if you
are is a very aggressive act and not likely to be received well. That
is what you seem to be doing, at least to my reading as a native
English speaker (and sometime upstream developer).
> That might come from the backgroud that it's actually meant to
> form a set of QM requirements. I'm going to implement an checklist
> system for the OSS-QM project [1] where all the releases are
> undergoing an approval process.
Undefined footnote error in "[1]". So I'll guess what "OSS-QM" is.
In general, if you recast your document as "we will take as input
upstream packages in general, and as output will will produce packages
which conform to these rules", then that's fine, because _your_
propject's output is something that you are legitimately in charge of.
Although I don't think that many Debian maintainers would prefer to
add an additional layer of intermediary between themselves and
upstream.
But if you're going to wave your document at upstreams, in order to
try to get them to do as you suggest, then you absolutely must phrase
the document in terms of _suggestions_ and _recommendations_, from a
position of humility.
Also, I guess "Q" stands for Quality. If you're going to be talking
to upstreams I would avoid using the word Quality to describe your
recommendations. Upstreams will have their own ideas about what
constitutes quality for their software (ie, depending on their own
goals), so you are at best going to cause confusion. At worst the
upstreams will be offended that you seem to be trying to redefine the
goals of their project, or that you are saying their project has poor
quality.
Ian.
Reply to: