[csw-maintainers] commentary on shared library naming proposal

[Philip Brown]

On 11/16/10, Maciej (Matchek) Blizinski <maciej at opencsw.org> wrote:
> No dia 16 de Novembro de 2010 17:00, Philip Brown <phil at bolthole.com>
> escreveu:
>
> How does the release manager know what's the best for the user?  It's
> not a rhetorical question.  I'm interested to know in the process.

Maciej, we've been round this particular discussion at least 3 times
before :-/ Previously, you have been asking with an eye to "well, tell
me the process, and then we'll automate it".
To which the reply has been, is, and always will be, "you cant
automate EVERYTHING. Certainly, the things that can be, we should. But
there are things that cannot be".

If you are NOT asking in that "Give me machine readable procedure"
context, but truly out of inquiry, then I will attempt to give you a
good faith answer.
(It's a pain in the butt. I WISH it could be more automated :) Your
extra gar-checkpkg stuff has helped, which is nice)


My registration script gives me a quick overview of what files are in
the package, what dependancies it has, and what shared libs it uses.
(maybe one or two other things i forget).
For trivial packages, I usually just "wave them through".
 **
For new maintainers, I try to spend a bit more time digging.
For new packages, I try to spend a bit more time digging.
For packages that have changed (names, etc) I try to spend a bit more
time digging.
If I notice some odd pathnames, I query the maintainer.
If I notice some odd/obsolete/non-optimal dependancies, I query the maintainer
For packages that have not been updated in a very long time, I try to
spend a bit more time digging.

Some types of package I tend to wave through, UNLESS they have
obnoxious names or other blatant oddities.
eg: perl, ruby, and python packages.
If someone wanted to actually spend TIME being a (perl/ruby/python)
release manager, I would welcome the extra scrutiny. I myself am not
qualified to deeply examine them, so I usually just pass them through,
with the exception of the libpython, and "where do the scripts live"
issues, which I attempt to keep consistent for the good of all.

Some things that will be viewed as inconsistent:
I have limited time. I'm not paid for this. So, sometimes, things get
delayed, when I think, "this one should probably be looked at more,
but I dont have time right now".
And sometimes, I wave them through because they've waited long enough,
and I just hope to look at them more 'next time around'.
Or, "the maintainer has already done 10 of this type, I'm sure this
one is the same"

And sometimes, I was simply not aware of a problem the first time(or
2nd or 3rd) a package
goes through. But after seeing similar issues with other packages, I
will then hold up something to bug a maintainer, for an issue which
they previously thought was okay.
Sometimes, a particular thing does not seem like an issue to me at
first. but then when I notice 3 or 4 packages going through the same
way, my mind may notice something and say "Hey wait a minute!" and bug
that maintainer.
Nothing against that maintainer personally... its just at that point
that my eyes happen to notice something in the file listings scrolling
by, or whatever.



> I guess there's also the question of the reasons for rejecting a
> package.  The release manager, despite having more power, can't reject
> a package because, let's say, he doesn't like the maintainer.  There
> has to be a valid reason.  I hope you agree.

Of course.
 I can say with all honesty that I have *never* rejected a package
because I "dont like" someone.  Some people may claim that I have...
but its important to note that they usually make this claim, instead
of doing work to alter what I'm complaining about. If they had just
done the work, they would have seen the package go through.

Bad feeling may build up, when a maintainer goes through multiple
times of rebuilding a package, but it's nothing about the maintainer
personally. Its just that when I reach a problem, I say "fix this
please", without looking further.
Once they fix the problem, then I continue looking through it.


What is unfortunate for positive feeling, is that I do usually look
harder at a package that has had a problem already. NOT because I
"dislike the maintainer", but because it is very often the case, that
when a package has one problem, it usually has more. So when I hit a
problem with a package, I do look even harder once I get a repackage
of it.
Not because I dislike the maintainer, but because I want our packages
to be as clean for our users as possible. So where there are likely
more problems, I look for more problems.
I havent kept records, but it does seem like packages more often have
2+ problems, than just 1.

and if you're wondering how I judge "problem", I go by our "core value":
'to provide a straightforward, easy-to-use experience for the user'
The tricky bit is in balancing the needs from all of our different
types of user: home, corporate, smallscale, and large scale. It
requires a lot of human judgement. For which, I use my 7 years
experience as a release manager, and 20 years experience as a
sysadmin.