[csw-maintainers] Define supported use cases and work from there

[Philip Brown]

On Thu, Jul 1, 2010 at 10:09 AM, Peter Bonivart <bonivart at opencsw.org> wrote:
> On Thu, Jul 1, 2010 at 6:53 PM, Philip Brown <phil at bolthole.com> wrote:
>> If you have suggestions to make this stuff better visible to
>> maintainers, please speak up.
>
> For me, it's not about making it more visible, it's about removing the
> "requirement". I wonder how it got there in the first place..?
>....
> I'm not asking for better documentation, I'm asking for us to rethink
> what we want to offer. When was the last time we did that?
>
> --

That's where I thought you were really heading, even though you
muddied the waters in your original email by talking about lack of
documentation :-)

So, you are proposing a change in our existing documented list of what
we support.

I have now posted some amount of rationale as to WHY we officially
support what is currently documented; the sharing of /opt/csw across
machines.

If you think we should change that, my suggestion is that you write a
proper proposal for it.
The proposal should ideally contain the following:

- An analysis of benefits for the change
- An analysis of negatives for the change

I'll point out that 'costs' of maintainance for the existing setup are
relatively low, for the average maintainer. First of all,
90%+(guesstimate) of our packages are completely non-affected by the
issue either way.
For the remaining stuff, maintainers just have to follow standards for
where to put stuff. If they do that, they dont have to do any extra
work at all.
The "work" is actually done by the maintainer of the appropriate CSW
utility scripts, in gar, cswclassutils, and now also in the
"alternatives" implementation.

I've handled one of those already: the alternatives implementation.
Gar mostly just hands things off to the other scripts.
So the remaining chunk is in the cswclassutils scripts.
I have already said I will recode the biggest difficulty; the cswinitsmf one.

So its unclear to me who is going to lose out by sticking to existing
standards, and who is going to benefit, if we changed them?

I will also mention an additional negative to change:
We have committed, for many years, to support /opt/csw sharing. (even
though we've done less than a stellar job of it lately). We also have
to consider impact to our credibility, if we decide to revoke it,
without even a major polling of our userbase.

>Just because we (as in you?) have documented something, it doesn't
>mean we should stick to it until hell freezes over. We finally dropped
>Solaris 8 after all. :-)

The ditching sol8 was not a random, "oh we dont feel like putting in
the effort any more" change.
It was part of our pre-existing, documented support life cycle, and
had been known and published for years.