Re: Summer of Code Proposal
On Apr 6, 2009, at 4:28, Jonathan Yu wrote:
Hi all:
Hi Jonathan,
I'm looking for someone to possibly mentor my proposal, if it is
accepted for Debian's Google Summer of Code. Gregor has mentioned that
he is too busy to do so, but hopefully one of you out there can help
me out. I've been working at packaging but I'm no expert, so just to
have someone I can ask questions of and to supervise my work to keep
me on the right track would be wonderful.
I cannot offer to mentor you unfortunately, my apologies.
I've posted the draft proposal to this page on the
Wiki:http://wiki.debian.org/jawnsy/CPAN_Smoker-like_system_for_Debian_Perl_package_Auto-Building_and_Testing
It's missing some stuff that I haven't written yet...
Hopefully I can get your comments (feel free to just edit the Wiki) on
things you might like to see, and hopefully I will be able to find
someone willing to mentor me developing this solution.
I would like to find out a little more about what you want to do and
how you want to do it. :-) I am a little taken aback by your statement
on the wiki saying that maintaining perl modules in debian is a
"becoming a pretty tough task". I am not sure you are wrong per se, I
just am not sure about what is tough and why you feel it is becoming
so. Is this an issue of scale? What exactly is hard about the current
system and work flow?
You cite that modules are becoming stale but I am not sure about how
stale they in fact are. One or two point releases away is not
necessarily bad, one might want to wait in fact until new
functionality or another reason to upgrade a package makes itself
evident and not just slavishly follow the latest version. An hour or
two with uscan might quickly update all the pending 35 packages with a
new upstream release, so I am unconvinced that there is a big issue
here, but there may be something I am missing.
Running a local buildd instance in conjunction with lintian and a
relevant CPAN test suite certainly sounds interesting though. Of
course debian is not going to be as cross-platform as perl so there
will be a natural limit to cross-platform testing.
Main ideas right now are:
o Some way of automatically testing policy compliance of control files
(though I guess lintian serves this purpose)
Lintinan in fact does give us a great deal of compliance checking and
any automated tool you develop ought to incorporate linitian in some
way. You might build a smolder bot with lintian support and then test
the resulting package in pbuilder or something.
Whatever route you decide to go, you ought to be aware of CPAN's own
attempt to integrate debian checks into CPANTS. This integration has
been spotty, mostly because I have not been as involved as I should be
in following up on Gabor Szabo's ideas and advice regarding debian
testing data and CPANTS integration, but there is lot to do there.
Contact Gabor, he knows a lot about CPANTS and can offer tips on what
might be useful upstream. Also note that there is an automatic package
builder in CPANPLUS which you may want to cannabilize or send patches
to, or not. Also, any work you do end up doing ought to be available
on CPAN as well as in debian itself. Just organizing the disparate
half-complete debian related packages on CPAN might be a good summer
of code project. :-)
Lastly, whatever you plan to do, don't under estimate the work
involved. Perl's testing tools are excellent and debian has lost of
points of contact for good test suites, but a lot of work has already
been done and integration will be a big task. You will learn a great
deal about packaging if you follow through with this though.
I'll try to stay up-to-date with your project and help when I can.
Warm regards,
Jeremiah
Reply to: