Fwd: Re: A Semi-Public Version Control Repository for Your CPAN Modules
-- Forwarded Message -- Subject: Re: A Semi-Public Version Control Repository for Your CPAN Modules Date: Thursday 06 July 2006 21:12 From: Damian Conway [EMAIL PROTECTED] To: Shlomi Fish [EMAIL PROTECTED] Hi Shlomi, Sorry for the delay in responding...I'm on my summer speaking tour at the moment and this is the first free hour I've had in two weeks. I appreciate you suggestion, and I'm watching Alias's experiment with considerable interest. You asked if there was a reason not to do this, and my reason is that I simply do not (yet) feel comfortable with this approach to distributed development. Nor am I convinced that it would be a win for me. Opening up the module to other committers doesn't eliminate the work, it just reduces it from development (which I enjoy) to supervision (which I loathe). And it doesn't address the real problem: it's not that I don't have enough time to maintain most of my modules...it's that I don't have *any* time to do so. Changing how that maintenance is done won't magically make that time available. All the best, Damian --- - Shlomi Fish [EMAIL PROTECTED] Homepage:http://www.shlomifish.org/ 95% of the programmers consider 95% of the code they did not write, in the bottom 5%.
Re: A Semi-Public Version Control Repository for Your CPAN Modules
On Tue, 27 Jun 2006 00:42:58 +0300 Shlomi Fish [EMAIL PROTECTED] wrote: 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. 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. You can have co-maintainers in CPAN today that allows for multiple people to inject real versions into CPAN. But you have to be setup by the maintainer as a co-maintainer. But like with all FOSS projects, I think it should be up to the current maintainer ( or the CPAN gods if the maintainer disappears ) to grant that. Limiting commits to just people with PAUSE logins would probably not cause too many problems... but the chance for abuse is still higher than I would like if the decision were up to me. As for your ideas on vendor tags, in-house CPAN sources, etc. I think can all be handled adequately today with CPAN::Mini and injecting your own modules. Obviously, you'd have to host these yourself and point your cpan shell at them, but it should work with todays tools. - Frank Wiles [EMAIL PROTECTED] http://www.wiles.org -
Re: CPAN6 (was: A Semi-Public Version Control Repository for Your CPAN Modules)
Sam Vilain wrote: If you are in Europe in August, you might like to come to YAPC and see the announcement of cpan6, this concern is included in the design requirements and making small changes to other's code will be natural and safe. * Randy W. Sims ([EMAIL PROTECTED]) [060626 06:12]: Has there been any public discussion of cpan6? I've only seen vague references and wishful posting. Will the design requirements be open to public review and comment before it's implemented? Sam and I work on the CPAN6 idea for a few months now. It goes much further than simply security and multi-developer extensions to Pause. You can use it to create, distribute, and merge CPAN-like archives; on a meta-archiving level. Especially this requires new terminology, which we now try to freeze in the YAPC-paper and other design documents. Public discussion on this moment would eat all our time. Of course, we hope it will grow into a community project after the YAPC. -- Regards, MarkOv Mark Overmeer MScMARKOV Solutions [EMAIL PROTECTED] [EMAIL PROTECTED] http://Mark.Overmeer.net http://solutions.overmeer.net
Re: CPAN6 (was: A Semi-Public Version Control Repository for Your CPAN Modules)
On 6/26/06, Randy W. Sims [EMAIL PROTECTED] wrote: Has there been any public discussion of cpan6? I've only seen vague references and wishful posting. Will the design requirements be open to public review and comment before it's implemented? Of course not - but in the usual Perl way, if you don't like it, you can build your own cpan6! And release it to, errr, CPAN. Sorry, slightly tongue in cheek. But as with most Perl 6 projects, I have to ask: Why do we have to wait for Perl 6 before we get a better CPAN? Or is this getting too meta and should I wait until your yapc talk instead... Leon
Re: A Semi-Public Version Control Repository for Your CPAN Modules
On Monday 26 June 2006 08:54, Sam Vilain wrote: Shlomi Fish wrote: Now, Adam Kennedy recently made an interesting step of making commit access to a Subversion repository with the source code for most of his modules to anyone with a valid PAUSE login: http://use.perl.org/~Alias/journal/29327 My suggestion is for you to do something similar. What do you think? Is there any reason for you not to do so? Shlomi, 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. 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. If you are in Europe in August, you might like to come to YAPC and see the announcement of cpan6, this concern is included in the design requirements and making small changes to other's code will be natural and safe. http://www.birmingham2006.com/cgi-bin/yapc.pl?act=talk-itemtalkid=51 Sam. 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). 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. Regards, Shlomi Fish - Shlomi Fish [EMAIL PROTECTED] Homepage:http://www.shlomifish.org/ 95% of the programmers consider 95% of the code they did not write, in the bottom 5%.
Re: A Semi-Public Version Control Repository for Your CPAN Modules
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
Re: A Semi-Public Version Control Repository for Your CPAN Modules
Shlomi Fish wrote: Now, Adam Kennedy recently made an interesting step of making commit access to a Subversion repository with the source code for most of his modules to anyone with a valid PAUSE login: http://use.perl.org/~Alias/journal/29327 My suggestion is for you to do something similar. What do you think? Is there any reason for you not to do so? Shlomi, 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. If you are in Europe in August, you might like to come to YAPC and see the announcement of cpan6, this concern is included in the design requirements and making small changes to other's code will be natural and safe. http://www.birmingham2006.com/cgi-bin/yapc.pl?act=talk-itemtalkid=51 Sam.
A Semi-Public Version Control Repository for Your CPAN Modules
Hi Dr. Conway! I'm CCing this message to module-authors@perl.org, to hear what people think and to encourage other authors to consider it. You have quite a few distributions on the CPAN: http://search.cpan.org/~dconway/ Now, the problem is that many of them (naturally) have bugs and several have pending patches on the Request Tracker. I myself have a patch for a small annoyance in NEXT (which is part of core), and a fellow Israel.PMer said he encountered a bug in Toolkit, and recently a discussion about Boston.pm talked about Parse::RecDescent's memory scalability problems. Now, Adam Kennedy recently made an interesting step of making commit access to a Subversion repository with the source code for most of his modules to anyone with a valid PAUSE login: http://use.perl.org/~Alias/journal/29327 My suggestion is for you to do something similar. What do you think? Is there any reason for you not to do so? -- As for the disqualifier disqualifying based on his own fault[1]: I'm not aware of any outstanding bugs in any of my CPAN modules except for SVN::Pusher. I also can usually commmit patches that get sent to me during the next weekend or sooner. (With some constraints due to my new full-time job and the fact I'm organising the August Penguin 5 community FOSS conference in Israel). Nevertheless most of my CPAN modules are available in this Subversion repository: http://svn.berlios.de/svnroot/repos/web-cpan/ (Most of the others are available in other public Subversion repositories). I'll gladly give Subversion access through the Berlios system if people will register an account on Berlios, and send me one patch. Following Audrey Tang's lead, I will make them committers so they can commit there themselves. Naturally, Alias may agree that I move my modules to his repository instead, which will open it for contributions by any PAUSE author. I'll gladly do that, at least for some of my modules. Regards, Shlomi Fish [1] - It really sounds better in Hebrew: http://en.wikiquote.org/wiki/Hebraic_proverbs#.D7.94 - Shlomi Fish [EMAIL PROTECTED] Homepage:http://www.shlomifish.org/ 95% of the programmers consider 95% of the code they did not write, in the bottom 5%.
