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

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

Thread Previous | Thread Next
Yuval Kogman
August 29, 2009 06:20
Re: The plan for ext/ and dual-life modules
Message ID:
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.

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.

>  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

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