Front page | perl.perl5.porters |
Postings from August 2009
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://perl5.git.perl.org/Core-Module.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 http://github.com/apenwarr/git-subtree/tree/master, but I think submodules are more appropriateThread Previous | Thread Next