Shlomi Fish wrote: >> Another option is to just upload the distribution with your changes >> using your own PAUSE ID to cpan. It will not get indexed, but succeeds >> in that users who don't know about or trust some external repository can >> still access your changes via the CPAN network. >> > > I really don't want to do that, because it's not a real solution. This > mailing > list, modules@perl.org and other forums are inundated with such requests for > gaining maintainership of authors who disappeared. Now Damian did not > disappear - he's still alive and kicking - he just doesn't have the time to > apply all patches or fix all bugs. >
I'm not sure why you say it is not "real" - would you care to elaborate the failings in this working solution that you see? I've come across authors who have thanked me for doing a release for them, and it means that the *users* of the modules don't have to wait for the upstream author to do a release if they want to get the modified version. Sometimes it's just the simplest and most effective way to publish the changes. > Once a FOSS project becomes popular and the author becomes busy, then having > only one person able to commit changes to such a project, scales less and > less. That's what version control and multiple commiters (or alternatively or > complementarily distributed version control) is for. > > I could release a module I have changed for with patch A, and then patch B, > and then patch C, etc. I've already done it with > http://www.shlomifish.org/open-source/bits-and-bobs/gringotts-patch/ which is > written in C. However, I'd rather take advantage of Audrey Tang's and Adam > Kennedy's lead and simply commit changes directly to their version control > system so they'll eventually be available upstream. > A lot of what you say is true, but we should be extremely careful not to enforce or specifically condone any particular style of development. Some prefer the wiki-style/open commit approach and hence use SVN as a robust filesystem for this, others prefer that changes are reviewed first and probably use a distributed system like bazaar, git, darcs, etc, for a cleaner concept of branches. Consider how this works with savannah.gnu.org. If you have a patch to a software package that implements a particular feature, you can just upload it to the system. It is then available for all users, not just the maintainer. Later, the maintainer can mark the patch as included in a release, and the patch gets marked done. Making it easy for these changes to be available to a given user is just a matter of installation tool sophistication. However, if you just commit on an SVN trunk, your trunk becomes a "ghetto" of features which may or may not work. Some relish in delight at the prospect of grokking these new ideas from people, and the success of pugs is testament to the energy of people like Audrey who actively engage in this process. But if the maintainer doesn't do that for all their modules all the time, the ghetto ends up needing much clean-up before release, possibly involving a painful process of branching and cherry picking, which is always painful with svn. I think the point is that it is not valid to imply that a module author is not fulfilling their moral duty because they do not embrace the wiki model and want to adopt your changes. There are plenty of options - set up your own VCS, upload to CPAN independently, post a patch to the module's users' mailing list, etc. The reason I recommended uploading to CPAN, is because as CPAN to VCS bridges emerge, your new version will fit in tidily as a separate branch. Assuming the author uses this bridge they can then just merge, then "commit" back via the bridge to CPAN. > Well cpan6 aside, I've thought about an idea for Park ( > http://www.shlomifish.org/park-lisp-fooware/park-lisp-informal-spec/ ) which > I have yet to put in writing in the slowly-progressing informal spec, but > it's doable for other languages too: > > What happens is that everyone can register a "vendor tag" in CPAN, which is > an > alphanumeric name. He can also make other people co-maintainers of this > vendor tag. Then new versions of modules of an existing author can be > released under a vendor tag that they belong to. And the user can specify to > install modules that belong to a certain vendor tag. > (e.g: "install --vendor=ShlomiFish Parse::RecDescent"). > This is actually required for Perl 6, to be able to specify a vendor. eg, `use Parse::RecDescent-(Any)-cpan:SHLOMI'. The vendor tag is just your PAUSE ID, or perhaps a cpan6 archive URL. It is expected that this functionality will eventually be retrofitted into Perl 5 via CPAN6.pm. > Naturally, it introduces some problems, and probably not a perfect solution > but worth thinking of. Note that I hope to see some of the non-Perl6-related > improvements to Perl6 back-ported to CPAN (or to CPAN 2.0 - ;-)). > > Another improvement I thought is a list of secondary sources, each one with > its own list of mirrors. This will allow: > > 1. For projects to set up secondary sources of modules, where they have more > control of (or alternatively are of a non-free license). > > 2. For organisations to set up CPAN-like sources of in-house > (so-called "proprietary") packages for the entire organisation, to be > installable and updatable from a central location. > Combining multiple archives, as you do with for instance APT, will also be a core feature. Sam.
