Front page | perl.perl5.porters |
Postings from April 2010
On Tue, Apr 06, 2010 at 07:13:27PM +0000, Ævar Arnfjörð Bjarmason wrote: > On Tue, Apr 6, 2010 at 16:37, Aristotle Pagaltzis <pagaltzis@gmx.de> wrote: > > * Ævar Arnfjörð Bjarmason <avarab@gmail.com> [2010-04-06 16:45]: > >> That would be great, or just not release the slim core, people > >> can get it from Git :) > > > > Eventually ??? maybe. > > > > I thought of that, but avoided mentioning it because I don???t > > think now is a good time to think about it. If the whole idea > > happens and pans out, it???ll be easier to talk about it then. > > From where we are now it is probably too radical a change to > > consider objectively. If it makes sense, it???ll come up in good > > time anyway. > > Yup, speaking of which, what are the things that need to be worked on > to make slim-core happen? That would be a useful resource for > contributing. I'm not sure of all of them, but I can think of one thing to get started with: Attempt to remove each directory from cpan/ (and dist/ and lib/) and the MANIFEST, re-Configure, and see what breaks. If nothing breaks, it could go. If the build breaks, and it's a module you've never heard of, and are surprised to even find in the core, figure out how important it is to the build processes it is, and whether the user of it can be refactored to avoid it. > Meanwhile I set up a bikeshedding page at > http://www.perlfoundation.org/perl5/index.cgi?batteries Is there a plan for the policy on whether modules are ever removed from the "batteries" version? For example, someone commented that DBIx::Class feels like a potential module to include. If this project had kicked off 8 years ago, then likely back then it would have been Class::DBI. So, what would happen to a Class::DBI when DBIx::Class was added later on? Keep both? Phased transition? Does Strawberry Perl have a plan for this? Does Task::Kensho? What does ActiveState do with ActivePerl? > >> But even if we improve our support for shipping a fat core by > >> just dropping in CPAN tarballs, does that really change the > >> main standing objection not doing so? Namely that any problems > >> in the respective CPAN distributions are ultimately our > >> problems and major issues with them will hold back releases. > > > > The idea is to decouple the release cycles of (and the people > > involved in) the slim package vs the batteries-included package, > > so that the core can iterate faster and the batteries-included > > package can still contain lots of useful stuff. They might > > ultimately become two not formally separate groups of people > > under the umbrella of p5p, I dunno. There are many ways it might > > play out productively and I don???t want to stake the proposal on > > any particular version of that future. > > Sounds good and managable, especially with frequent core releases. And I'd love to see someone or some group prototype this. Branch http://github.com/mirrors/perl and get cracking. Nicholas ClarkThread Previous | Thread Next