[csw-pkgsubmissions] newpkgs libruby18_1, ruby, ruby18, ruby18_dev(...)

[Philip Brown]

On Fri, Mar 18, 2011 at 1:14 PM, Ben Walton <bwalton at opencsw.org> wrote:
> Excerpts from Philip Brown's message of Fri Mar 18 15:35:14 -0400 2011:
>
>> Its unfortunate you did not choose to reply further to the thread on
>> the maintainers list, and chose instead to just push the package. So
>> now I have to address it here :(
>
> I had nothing more to say on the matter at that time.  I find it
> unfortunate that you use the release manager position as a tool to
> force your viewpoint on this.  Discussion is fine, but sitting on
> packages is not.

I am not forcing my viewpoint. I am forcing *discussion* on an
important issue, since the issue does not have explicit policy.


>> (up front note: If you would like "the rest of the packages" pushed
>> through, and we just hold
>> ruby18_gcc4* for discussion purposes, I'm willing to do that)
>
> Nope.  All or none, since not pushing this would be reducing existing
> functionality.

Ah. I was initially pondering how you were saying that, since current
packages do not use alternatives. Some explaination would have been
useful here. After doing my own poking, it would seem that current
ruby package supports gcc only. I was not aware(or at least, have
forgotten)  that the current package was in violation of our usual
standards.
As such, are you changing the default behaviour, if a person does only
"pkgxxxx upgrade ruby".
Is that correct?

Maybe that's not such a good thing if so.



>  I'm sticking with this approach (at least for now) as
> it mimicks the existing behaviour.  The only change from previous
> packages is that I'm now using a standard tool to implement the
> switching behaviour.

how was it done previously?
If it really matches what you've put there, then this is no longer a
gating factor.
However, unfortunately, there's another issue which I realized over lunch.
Given that this email is now rather long, I will make a separate email
to maintainers, about it.



>> It is pretty short work, to make that config file auto-configuring,
>> since the file is itself ruby code.
>
> And yet it's fragile in the face of change.  That makes maintenance
> aggravating.

you are only guessing at that. you havent tried future builds. For all
you know, the patch may translate well.
There are also ways to make it more "robust".

> And since I've yet to see a use case, it's not time well
> spent.

I would be willing to give you a more "robust" autopatcher, if you are
willing to commit to using it.


> The end user is the sysadmin from our perspective.

This is probably something that we need to clarify in a vote, for our
official policy.

Sysadmins.. professional ones at least.. do not install packages
merely for their own benefit. They install them because they need to
serve THEIR users.
If our packages fail their users, we then also by inheritance, fail
the sysadmins as well.


>> In large site installations, where some users may use Sun CC, and
>> others use gcc, this is fatal; either for one set of users, or for
>> that site using our packages. Most likely in toto; they would reject
>> ALL our packages, if we are not large-site considerate.
>
> When I see a bug filed (not by you to make a point), I'll entertain
> it.  Until then it's speculation.

1. It's not a common occurence
2. large sites already come in with the presumption that "free"
projects are not likely to accomodate large-site installation needs
3. If the user did a google search on opencsw, ruby in the future, and
probably running into your unwillingness to patch, even when the work
is handed to you, just how likely do you think it is that they will
bother to file a patch?



>> Please let me know what you think about it, given the above
>> discussion points.
>
> When I see bug reports, I'll reconsider.  Until then, it's more work
> than it's worth.

This is a really really user-hostile attitude.
Most users, even ones who run into problems, DO NOT FILE BUGS. They
just look elsewhere.

It's also a maintainer-hostile attitude.
maintainers are supposed to pay MORE attention to use cases of other
maintainers.
I have just told you that your package will not function properly, in
my real-life large site installation. This is not a hypothetical. This
is REAL WORLD USE.
 And you have told me that you are going to ignore that fact, simply
because it is *my*
site?
Really insulting, Ben
(and for what it's worth; no, I did NOT set up the layout at my site;
I inherited it. It's been this way for 20 years)

And  as I have just mentioned, I have volunteered to do the work for
you. So the "more work than it is worth", is rather hollow.