[csw-maintainers] Policies and special cases

[Philip Brown]

On 11/18/10, Maciej (Matchek) Blizinski <maciej at opencsw.org> wrote:
> No dia 16 de Novembro de 2010 21:18, Philip Brown <phil at bolthole.com>
> escreveu:
>> ..
>.... When
> rejecting packages, you quite often say something that resembles a
> policy, but when I look at a catalog, it turns out that other packages
> don't follow what you said.  And that's fine - policies are changing,
> what was fine a week ago might not be fine now.  At this point I'd
> expect you to say: "Yes, there are packages that don't follow that
> policy, they would best be fixed."  But you don't say that. Instead,
> you say "It's not a policy really, it's a case by case thing".

Hey now, be fair: sometimes I say the first thing :) But yes, other
times I say "case by case"



> This way, you basically reserve the right to say whatever you please
> on any package you please and always claim it's a case by case basis.
> When submitting a package, a maintainer can never tell whether a
> package will or will not be accepted.  I would expect that if there's
> a well understood aspect of packaging, the policy should be clear and
> the same for all packages.  If the aspect is complex, the policy can
> be complex too, this is fine.  But complex does not mean case by case.


I *have* attempted to improve the 'detail' of these descriptions of
policy this year.
I think the other problem we run into, is that our 'policy-related'
documents are getting larger, and more spread out, so no-one really
reads all of them. Or forgets them. OR, heck, I forget sometimes that
what I'm describing, has already been written up on some page last
updated 3 years ago :)



> I'm not saying that you can put rules on absolutely everything.  But
> I'm saying that if there is some kind of reasoning that suggests a
> particular solution, the same reasoning applies to other packages too,
> and is worth documenting.  If it's not worth documenting and applying
> across the catalog (to the packages it applies to), perhaps it just
> doesn't matter that much, and therefore my package can be safely
> included in the catalog.

There really are things that are "specific to the package/software".
The big, obvious example, is "where to put config files.", and the
case-by-case factor of, "does this software most often get deployed
with a global config, or with a machine-local config?"

This is a completely non-automatable, case-by-case scenario.


Usually, the maintainer is the best source for this, and I try to respect.
Sometimes, though, there is a conflict between the maintainer saying,
"well, *I* usually deploy it this way", vs what the community at large
most commonly expects.
The release manager needs to be mindful of that potential conflict.





> Each well understood aspect of packaging should have related policy.
> I expect that if I submit a package that conforms to the policy, it
> gets accepted.  In the unlikely event that my package gets rejected, I
> expect a change to the policy, or a new policy put in place -- and
> from now on all packages have to follow that policy too.

I completely understand a maintainer's  desire to understand where a
package is going to fall, before they put the work into it.
This touches on another email you already posted, where there's a
"problem" with the release manager getting notified only at the very
end of the package creation process, vs the beginning. It's always
nice to see someone ask me, or the maintainers list in general,
packaging design questions up front, vs arguing after the fact.

>  I don't want
> my packages to be at the mercy of a single person who can make stuff
> up as they go along.  Is that reasonable?
There's a difference between "making stuff up as they go along", vs
"judgement call".

I'll respond more about the basis for my judgement, in another email,
since you already raised that topic elsewhere.