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

Re: The plan for ext/ and dual-life modules

Thread Previous | Thread Next
Mark Mielke
August 29, 2009 17:48
Re: The plan for ext/ and dual-life modules
Message ID:
On 08/29/2009 08:04 PM, Yuval Kogman wrote:
> 2009/8/30 demerphq<>:
>> That doesnt make me feel all warm and fuzzy frankly. Submodules to me
>> still seem to be too unstable for us.
> Not really, the implementation is very simple. Submodules aren't
> unstable in any way, they just have a problem of expectation
> management.
> The problem is that people usually expect to find something like SVN
> externals, which will let you update more easily, whereas submodules
> require a commit in the repository that includes them in order to be
> updated. In our case this is very appropriate.

Don't SVN externals require a commit to update? Or are you talking about 
externals based on LATEST or something unreproducible? :-)

> They let us treat dual lifed modules as separate subprojects (which
> they are): instead of creating "update Foo to CPAN version" patches
> periodically, that becomes an "update Foo to commit 0123decafbad from
> Foo.git"
> The point is to allow dual lifed modules' maintainers who want to use
> git to a more reliable way of sending updates downstream and receiving
> patches from downstream, with the added side effects that the job for
> a perl.git committer is slightly easier.

This sounds good to me - but I think people need some more settle time 
with GIT before they can accept such changes.

I think the idea of allowing Perl core developers to select the version 
of external modules using a built-in facility such as submodules would 
work great. It might give me the kick needed to update my one tiny core 
module (Text::Soundex) to resolve the minor conflicts between core and 
CPAN today. :-)


Mark Mielke<>

Thread Previous | Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About