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-item&talkid=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
Re: CPAN6
Leon Brocard wrote: > 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. > > 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? > We don't, we're building it using Moose :-). You're waiting on good old fashioned hubris. > Or is this getting too meta and should I wait until your yapc talk > instead... Leon > Yes, come to the talk, it's 98% "meta" free and no added "Schema". Sam.
