develooper Front page | perl.perl5.porters | Postings from October 2009

Re: future of maint

Thread Previous | Thread Next
From:
David E. Wheeler
Date:
October 9, 2009 11:10
Subject:
Re: future of maint
Message ID:
B1FD56FA-BC15-4F36-86B5-06F5F9701752@kineticode.com
On Oct 8, 2009, at 3:48 PM, Dave Mitchell wrote:

> One serious possibility is to scrap maint altogether. This is  
> essentially
> what the Linux kernel did a few years back.

I think maintaing two maints back is reasonable assuming more  
frequent, regular releases of blead (once per year would be ideal).

> Another is just the critical fixes (ie (1) above). So, we release  
> 5.10.0,
> then a month or two later out comes 5.10.1 with most of the things we
> broke in 5.10.0 fixed. Then a few subsequent releases as a few  
> remaining
> regressions are spotted, and/or critical security patches are  
> released,
> with frequency of releases tapering off.

+1

> However, (3) is also important; CPAN developers often want to test
> their code against older perls, but often they won't build on their
> current h/w, which is why it would be nice to produce new versions  
> with
> all the latest Configure, hints/ etc changes. However, the build
> toolchain also includes a whole bunch of dual-life CPAN modules like
> MakeMaker, so they would probably need to be pulled in too. And my
> experience with 5.10.1 of getting all those modules in consistent  
> state
> that play with each other was exceedingly unpleasant. You also run  
> into
> things like the great post-5.10.1 lib/ext->ext/cpan/dist migration,  
> which
> puts a great kibosh on cherry-picking the bits you need without  
> pulling in
> the entire migration, plus all the other updated CPAN modules etc.

-1 Yeah, don't bother with build maintenance except for bug fixes, I  
say.

> If we don't include all the newer CPAN releases, then over time  
> we'll be
> releasing maint with old crusty CPAN modules, and users and module  
> authors
> will rightly castigate us for shipping old broken crud. But pulling  
> in all
> the latest CPAN releases, while making sure we're synced with CPAN  
> and that
> everything works is really, really hard.  That was basically what  
> the last
> three months before 5.10.1 was released were taken up with.

Again, if there are regular releases of blead, this will not be as big  
an issue. And frankly, users are stuck with crusty CPAN modules *now*,  
because of how long it takes to do a blead release. This is not to the  
pumpking's advantage in any way, nor to the community's.

> Maintaining binary compatibility is really, really hard. You have to  
> be
> totally on your guard, since any core commit could potentially break
> it. Remember above I said 2800 cherry-picks? That's a lot of land  
> mines to
> be swept. I really think BinCompat is a luxury we can no longer  
> afford to
> offer, unless maint releases really do just consist of a few  
> critical fixes
> here and there.

+1 Yes, minimize backpatches to only what's absolutely essential.

> One item of trivia that I think would make maint slightly easier would
> be to have just a single perldelta file that covers all releases in  
> the
> same branch, and that just prepends new info to the file, e.g.
> perl510delta.pod might contain:

+1

> Finally my stance on continuing as maint pumpking is that I'm happy to
> relinquish the role if someone else wants it, and that I'm not  
> prepared to
> continue with it unless its agreed that maint will be something very
> minimal (e.g. one or two cherry-picks per week).  [ Or unless some
> commercial entity regards maint in its current form as important  
> enough
> for them to fund me at my usual consultancy rate for a day or two  
> per week
> on a long-term basis.]

This is similar to how the PostgreSQL community manages maintenance  
versions: They maintain about five years' worth (more than Perl needs  
to maintain, IMHO), but are happy to maintain further back if a  
commercial entity is willing to pay for it (and indeed, part of the  
reason they do go back five years is because Red Hat pays Tom Lane to  
do so).

Thanks for this post, Dave. I'm generally in agreement with Jesse's  
and Jan's followups, too. This, together with the dev releases and  
RGS's talking about 5.12 this year, I'm optimistic about the future  
maintenance and development of Perl. Yay!

Best,

David

Thread Previous | Thread Next


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About