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

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

Thread Previous | Thread Next
Rafael Garcia-Suarez
August 29, 2009 09:46
Re: The plan for ext/ and dual-life modules
Message ID:
2009/8/29 Yuval Kogman <>:
> IMHO the logical next step is to use submodules[1] for the directories
> in ext/, allowing the maintainers to keep separate repositories for
> each core module in the main git server.

I tend to prefer git-subtree, but it's only because I've heard bad
things about submodules.

Alternatively dual-life module maintainers can be granted commit. I've
created a branch dual/Safe for the very purpose of dual-maintaining

> The reason I bring this up now is that it might be helpful to already
> make use of this process for completing the various layout
> changes/fixups, allowing authors to treat the two divergent trees as
> mergeable histories without too much fuss.
> In the long term this would make the process of bringing a core module
> up to date fairly simple:
> all prep work would happen in the module's repository by its
> maintainer (either in the master branch or in a specialized "core"
> branch for integration).
> the actual update operation for perl.git is a matter of bringing that
> module's tree up to date (e.g. using git pull) running git commit in
> the parent directory (creating a new commit in perl.git).
> The biggest problem I see is that submodules are somewhat reliant on
> stable repository URIs, so I suppose all core modules would need
> git:// URIs.

So we'd need to host clones for each dual-life module ? (That's not a
problem but I just want to make it clearer)

>>  That would makes it incredibly easy for anyone to see which code we
>>  "control", and which code and documentation we get from upstream, and so
>>  should send patches and bug reports upstream, instead of attempting to fix
>>  in place.
> If someone does a checkout of perl.git and commits to a submodule's
> directory, this would become even easier, the patch is ready to be
> sent as-is to the maintainer, who integrates it and then sends a
> request to a perl.git committer to update it in the perl.git tree.
> [1] or alternatively
>, but I think
> submodules are more appropriate

"You don't mean odds and ends, you mean des curieux et des bouts",
corrected the manager.
-- Terry Pratchett, Hogfather

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