Front page | perl.perl5.porters |
Postings from August 2001
Re: The case for SDKs
From:
Randy J. Ray
Date:
August 3, 2001 15:15
Subject:
Re: The case for SDKs
Message ID:
200108032216.f73MGdv02437@tzimisce.cygnus.com
Wow, and here I just yesterday sent a long e-mail to my (newly-assigned)
manager explaining what we'd talked about at tpc, how it overlapped what
folks at RH were already working on, and why I thought we (RH) would be
better served by having someone work towards this goal so that RH can use
it and benefit from it, rather than having two implementations of basically
the same task. I also asked him if he'd consider letting me slice out a
reasonable part of my weekly schedule to be that person. And I implied that
I'd like to volunteer to take on the pumpking-equivalent role, provided
someone more qualified isn't already interested (I feel capable of it, but
I will also recognize other interested parties who have more and better
qualifications). Of course, I haven't gotten a reply, so I'm not yet
outright volunteering. But I am voluntarily declaring my interest, in case
I do get the green light.
Moving on to the topic, here are the thoughts and feelings I took away from
the p5p meeting. For references' sake, I should point out that a lot of
what Jarkko and I said and pointed out during that part of the meeting
arose from a conversation we had (along with Paul Kulchenko, and several
other porters who wandered in and out of our little circle) earlier that
day. The original chat started as a plan to have Paul and I duke it out
over the "XML-RPC" title, but to everyone's surprise Paul and I agreed on
most of the points immediately, so we let ourselves get sidetracked on the
modules/SDK issue.
1. Bundles are a good thing, and a reasonable place to start in terms of
how we would consider defining and implementing SDKs. But they will
either need beefing up, or something new drawn up (using them as a sort
of prototype) eventually. Matt pointed out that they had little version
control readily available. While Elaine was quick in pointing out that
you *do* have versioning abilities, I also agree that a given SDK
should be more than just a Bundle::* entry on CPAN. It should have some
sort of Charter (as Matt also suggested), specific point for seeking
information, explanation of decisions made ("Why we used XML::LibXML
in place of XML::Parser" for example), that sort of thing.
2. The need to have several smaller SDKs rather than one or two
"penultimate" ones is pretty clear, and generally accepted across the
boards. That implies (at least): (a) An "SDK Pumpking" who monitors
the "owners" of individual SDKs and coordinates volunteer energy with
matching projects; (b) A conflict-identification and -resolution
process for cases where two SDKs utilize the same module, but have
slight-yet-significant version issues with the given module (for
example, the current issue of XML::Parser 2.30 not working with Apache
on some systems); (c) Some sort of integration-testing framework, not
only for the SDKs themselves, but to check how well they play with each
other and (more importantly) how they react to a new patch/release of
Perl itself.
3. SDKs should aim towards being viable as single, "meta" packages all by
themselves. Software vendors (including not only RH but Debian, SuSE,
*BSD, ActiveState, etc.) would benefit from this, as it would ease the
creation of additional installable packages (or "groups"). Using RPM as
an example (simply because of personal familiarity), look at Apache in
Red Hat, Mandrake, SuSE or others: you have "apache", "apache-devel",
"apache-manual", "apache-mod_ssl", "apache-mod_php[34]", etc. My ISP
(which runs on FreeBSD) recently made PHP4 widely available (mod_perl
has been for quite some time) because of the ease with which it could
be installed. If I asked the support dept. to compile and install some
random Apache module, I'd probably get more resistance.
4. One ultimate (and ulterior) goal we should have is the ability to give
a particular module a blessing of validity. I mentioned this several
times at the meeting. Perl has a single point of authentication in
that as a community we only release after getting the go-ahead from key
members. Python, GNOME, Qt, KDE, even Linux itself shares this sense
of clarity. Any SDK effort should at least keep this goal in mind, even
if it isn't part of the initial list of milestones.
That summarizes my personal notes on the matter (save for those things that
others have already said under this thread. For now, I'm just hoping that I
get to devote more time to Perl in general. If not, then I'm not going to
volunteer for anything I don't feel I have time to fulfill.
Randy
--
-------------------------------------------------------------------------------
Randy J. Ray | Buy a copy of a baby naming book and you'll never be at a
rjray@redhat.com | loss for variable names. Fred is a wonderful name, and easy
+1 408 543-9482 | to type. --Roedy Green, "How To Write Unmaintainable Code"