Hi Simone! I'm very glad that you're seconded svn-contrib idea! On Wed, Sep 13, 2006 at 09:49:07PM +0200, Simone Rota wrote:
Hi,
I discussed this proposal privately or on irc with different people, I'll try to formalize it here.
I think it would be nice to offer access to a dedicated svn repository on crux.nu to 3rd party contributors (the current 'contrib')
The main motivations behind this proposal are the following:
- Versioning and history also for contrib - Promote teamwork - Make the contributors acually feel part of a project, much like the old CLC. - Less complicated setup for us: no need to sync many remote repos, check for dups, etc. - Potential improvement of quality in ports. - Contributors can concentrate on the ports, rather than on the platform (webspace, etc)
Yay! Halliluiah! OMG! Yes!! :-)
As a general note, I'm proposing to simply act as a service provider, and let the community auto-regulate itself. Nonetheless there should be a contrib maintainer, possibly outside crux-devel, responsible for basic quality testing, evaluating access requests and pass them to us, etc.
Assuming current contrib members are interested in such a service (we may as well do a preliminary survey on the crux ML) what do you think about that?
I'm not a contrib member because it's encumbrance me to maintain any web service. But I have few ports I'd like to put into contrib.
Related topics:
These are somehow related to the introduction of a crux.nu hosted contrib and general repo setup:
- We're currently evaluating other version control apps such as git and mercurial to see if they would fit best our setup, particularly regarding access control and repository separation, also considering that some reorganization of the repo layout could be needed if we decide to include the new contrib. If we agree on a svn replacement, there's the possibility of initially deploy git/hg/other only for the common contrib and migrate core/opt later on when we start working on CRUX 2.3
What problems are you (the developers) seeing with current svn setup? Except that GIT may *theoretically* solve multiarch issue? Or may not solve. I don't know, yet. I'm surely know that it's hard to do with svn in proper way. This issue need much deeper investigation -> playing with git merge, pull, push..... I suppose that even pure GIT without modifications (or script on top of it) can't manage the noarch -> arch scheme I've explained. Though, There is a "dirty" way exists. And it is _working right now_, with svn. We can create one "noarch" branch, and do arch-XYZ branches as working copies without committing. svn co svn://.../noarch noarch svn co scn://.../noarch arch-XYZ # note: arch-XYZ is just WC of noarch # Put some arch-dependant stuff (you can't commit it) cd ~/arch-XYZ && edit core/glibc/Pkgfile # Edit version= string in noarch branch cd ~/noarch && vim core/glibc/Pkgfile && svn ci -m "..." # update arch-XYZ working copy cd ~/arch-XYZ && svn up Viola! Our changes to arch-XYZ do not disappeared, in the same time version= updated. There is small risk that will be conflict, but if Pkgfile format will be in merge'able[1] form these collisions will are rare cases. This scheme works smoothly, except that you can't "clone"/checkout arch-XYZ ""branch"" in proper way, because arch-XYZ is working copy, and will not ever committed.
- Introduction of project specific repositories: gnome, mythtv, kde, etc. has been suggested.
Cool.
- Maybe we can take the chance of solving the long time due task of organizing the repository in a multi-arch friendly way and eventually put together tools & guidelines.
Please add comments and ideas by replying to this thread and/or live on #crux-devel at freenode.
Regards, Simone
Thank you! -- Anton (irc: bd2) [1]: Merge'able Pkgfile format is: version= release= source=( 100%-nonarch-dependable-entries # arch-XYZ can add/remove entries here ) build() { ... ./configure \ --no-arch-dependable-options \ # arch-XYZ add/remove options here \ --disable-nls ... } Thus, there must be one line per may-be-arch-dependent entry. This is because diff and patch are line-oriented.