[PROPOSAL] - Provide svn access on crux.nu for contrib
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) 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? 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 - Introduction of project specific repositories: gnome, mythtv, kde, etc. has been suggested. - 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 -- Simone Rota Bergamo, Italy - http://www.varlock.com
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.
Hi, On Thu, Sep 14, 2006 at 00:50:02 +0400, Anton wrote:
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: [...]
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. It depends on what you consider the multiarch issue. No VCS solves the issues IMHO, since they don't understand the ownership of ports (subdirectories). Especially the distributed VCS' only support tree-wide merges easily (yeah, cherry picking is there, but it's a pain if you don't want to merge a particular change but rather all changes for a particular
The major disadvantage is the weak merge support; this is less important for ports, although it would help branching new versions earlier / less painfully. For our tools though, a distributed VCS would be nice. In addition, at least mercurial does not depend on webdav, which in both svn's and git's case makes us currently depending on apache for the web setup. That said, subversion also has advantages over the two mentioned, so it's a pretty open question. directory), which means that you'd merge all ports if you just want to get the changes in "your" ports. Same for diff, which is again tree wide. In my experience, the change tracking part is a lot more important than the merging itself, since after an initial port to the new architecture, the changes will usually be rather small. At the same time, understanding what the main maintainer changed seems important (even if the change could have been merged automatically). If it's hard to see the changes relevant to you, maintaining an arch branch gets tiresome. Also, a tree-wide merge implies an opt-out situation, i.e. you don't pull in ports because there's a maintainer on your arch but because they exist in $OTHER_ARCH, with the option to drop them in your tree after you merged. BTW, you can use svk against an svn repository, should work equally well as any other distributed vcs.
[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.
The goals for multi-arch support distilled from the previous discussions are: - no changes to the Pkgfile format - no fundamental changes to pkgmk (one thing that most certainly has to be changed to avoid confusions is the name of the binary package, which should contain the build arch) - no changes to ports(8), nor the hierarchy in /usr/ports - no ports should be on $ARCH which aren't maintained and tested - doesn't require a single master tree, i.e. can have "master ports" in more than one arch Of course, for a personal arch port those requirements may be less interesting, it's more for an overall solution with a crux.nu hosted repository. The proposed solution is to use an simple tool to just track ports from master repositories which you sync to your local disk. This has the following properties: - no changes required to any tools or our ports layout - no vcs is enforced: PPC could use cvs, x86 svn, arm git etc, but all can track each others ports. - real maintainer view: - easy to see which of your ports changed - easy to see what changed in your ports - multi-repository, allowing to distribute the maintenance of ports amongst the "serious" architectures - stupid: no automated merges, templates or hidden functionality one has to wrap his (her?) head around, and reducing the sources of errors. It could obviously be extended to support automated merging as well, e.g. using a lightweight local VCS per port, although to me it seemed that compared to the testing of a new version of a port on a particular architecture, merging the Pkgfile changes manually is a minor thing (at least time wise). This approach is loosely based on mppm, the tool Simone used for ucrux, and pretty much the only real experience we have (except mine with some wrapper around svn for sparc, which suffered from the tracking issues mentioned further up). It's certainly an interesting subject, however there's more to it than just the Pkgfile merging if the goal is to create a system which can provide a CRUX port that feels authentical while making it fun to be on the arch maintainer team. HTH, Johannes -- Johannes Winkelmann mailto:jw@smts.ch Zurich, Switzerland http://jw.smts.ch
Hey simone, On Wed, Sep 13, 2006 at 21:49:07 +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') Sounds like a good idea.
The main motivations behind this proposal are the following: [...] As a general note, I'm proposing to simply act as a service provider, and let the community auto-regulate itself. We have to come to some agreement to which degree we want to control this (i.e. play police). Contrib has been working quite well in this regard, however it still required an occasional check for hidden duplicates (i.e. by using slightly different names).
Related topics:
These are somehow related to the introduction of a crux.nu hosted contrib and general repo setup: [...] - Introduction of project specific repositories: gnome, mythtv, kde, etc. has been suggested. I'd like to see that too, however we'll have to make sure it doesn't become a nightmare due to too many repositories (also because of inter-repository dependencies).
- 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. Sounds good, although I don't think the actual hierarchy has a major influence here... but we can discuss this further once we get to it.
Thanks for your initiative, Regards Johannes -- Johannes Winkelmann mailto:jw@smts.ch Zurich, Switzerland http://jw.smts.ch
Simone Rota [2006-09-13 21:49]:
I think it would be nice to offer access to a dedicated svn repository on crux.nu to 3rd party contributors (the current 'contrib')
[details snipped]
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 like the idea.
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
Okay.
- Introduction of project specific repositories: gnome, mythtv, kde, etc. has been suggested.
Sounds good. Regards, Tilman -- A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing on usenet and in e-mail?
On Wed, Sep 13, 2006 at 09:49:07PM +0200, Simone Rota wrote:
I think it would be nice to offer access to a dedicated svn repository on crux.nu to 3rd party contributors (the current 'contrib') Sounds good to me. I like your proposal.
Regards Simon
Hi again, On Wed, Sep 13, 2006 at 21:49:07 +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. [...] - Potential improvement of quality in ports.
Considering these goals, I'm not sure if we should keep the conditions to join as low as they are now. I'm in particular thinking that the way contributors appear in public will reflect back on the whole project (that holds of course true for all of us, not only the contrib guys!). IMHO we should therefore require a solid knowledge on CRUX, and an okay reputation both amongst users and devs. Also, the current contrib rules are somewhat lengthy, and contain some historic stuff ("CLC maintainer"); it might be a good idea do rewrite them with the new situation in mind, and make it easier to grasp at the same time. Comments? Regards, Johannes -- Johannes Winkelmann mailto:jw@smts.ch Zurich, Switzerland http://jw.smts.ch
Johannes Winkelmann [2006-09-15 08:40]:
On Wed, Sep 13, 2006 at 21:49:07 +0200, Simone Rota wrote:
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.
[...]
- Potential improvement of quality in ports.
Considering these goals, I'm not sure if we should keep the conditions to join as low as they are now.
Agreed. I assumed that was the plan anyway when Simone said that the new system will be "similar to the old CLC".
I'm in particular thinking that the way contributors appear in public will reflect back on the whole project (that holds of course true for all of us, not only the contrib guys!). IMHO we should therefore require a solid knowledge on CRUX, and an okay reputation both amongst users and devs.
:) Makes sense to me. Regards, Tilman -- A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing on usenet and in e-mail?
On Fri, 2006-09-15 at 08:40 +0200, Johannes Winkelmann wrote:
Hi again,
On Wed, Sep 13, 2006 at 21:49:07 +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. [...] - Potential improvement of quality in ports.
Considering these goals, I'm not sure if we should keep the conditions to join as low as they are now.
I'm in particular thinking that the way contributors appear in public will reflect back on the whole project (that holds of course true for all of us, not only the contrib guys!). IMHO we should therefore require a solid knowledge on CRUX, and an okay reputation both amongst users and devs.
Also, the current contrib rules are somewhat lengthy, and contain some historic stuff ("CLC maintainer"); it might be a good idea do rewrite them with the new situation in mind, and make it easier to grasp at the same time.
Comments?
Agreed, but the "new contrib" sounds very much like most of the current opt. Perhaps this could lead to a structure more like the old one, except Per's role has been taken over by the people known as "core maintainers" core: what pretty much everybody needs (default package selection for new installs) opt: other high-focus ports (apache, gtk, alsa, mdadm, python, libvorbis, curl, ...) contrib: less-used ports which don't have a lot of dependent packages (sshfs-fuse, iftop, jedit, yapo, pypanel, ...) personal: things that the owner used at least once, could possibly still work :) - can have external dependencies in core, opt, and contrib.
Hi, On Fri, Sep 15, 2006 at 11:53:06 +0200, Mark Rosenstand wrote: [...]
Agreed, but the "new contrib" sounds very much like most of the current opt. I disagree. 'contrib' stands for ports contributed from non-developers (or developers not wearing their developer hat), whereas opt are non-core ports maintained by the official developers. The development methology doesn't have any impact on that (even more as there's no user visible change, it's already exported as rsync and httpup from crux.nu).
That's an important differentiation, and the names reflects that nicely. HTH, Johannes -- Johannes Winkelmann mailto:jw@smts.ch Zurich, Switzerland http://jw.smts.ch
On Fri, 2006-09-15 at 12:03 +0200, Johannes Winkelmann wrote:
Hi,
On Fri, Sep 15, 2006 at 11:53:06 +0200, Mark Rosenstand wrote: [...]
Agreed, but the "new contrib" sounds very much like most of the current opt. I disagree. 'contrib' stands for ports contributed from non-developers (or developers not wearing their developer hat), whereas opt are non-core ports maintained by the official developers. The development methology doesn't have any impact on that (even more as there's no user visible change, it's already exported as rsync and httpup from crux.nu).
That's an important differentiation, and the names reflects that nicely.
Yes, and what I'm saying is that with the new contrib, the difference between "developers" (the non-core kind) and "contributors" is close to non-existant, with the exception that the former get to wear a funny character in front of their IRC name. (On the other hand, they must really like it, since unlike most other project channels, they wear it all the time.) So, higher quality requirements for contrib, and higher user count requirements for opt, so that it isn't just a dump for personal pet projects of The Chosen Few.
Mark Rosenstand [2006-09-15 15:33]:
On Fri, 2006-09-15 at 12:03 +0200, Johannes Winkelmann wrote:
On Fri, Sep 15, 2006 at 11:53:06 +0200, Mark Rosenstand wrote: [...]
Agreed, but the "new contrib" sounds very much like most of the current opt. I disagree. 'contrib' stands for ports contributed from non-developers (or developers not wearing their developer hat), whereas opt are non-core ports maintained by the official developers. The development methology doesn't have any impact on that (even more as there's no user visible change, it's already exported as rsync and httpup from crux.nu).
That's an important differentiation, and the names reflects that nicely.
non-existant, with the exception that the former get to wear a funny character in front of their IRC name. (On the other hand, they must really like it, since unlike most other project channels, they wear it all the time.)
Hint: you're helping noone by making comments like this. Regards, Tilman -- A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing on usenet and in e-mail?
On Fri, 2006-09-15 at 15:39 +0200, Tilman Sauerbeck wrote:
Mark Rosenstand [2006-09-15 15:33]:
non-existant, with the exception that the former get to wear a funny character in front of their IRC name. (On the other hand, they must really like it, since unlike most other project channels, they wear it all the time.)
Hint: you're helping noone by making comments like this.
Sorry, I'm just a bit annoyed by the thought that this could likely be one of the reasons some "developers" want to keep the seperation. Clearly a dedicated "IRC police" team would prevent this - for me, it's hard to see the association between repo commit rights and ability to judge when someone is abusing an IRC channel. But obviously I'm ignoring the e-penis factor.
On Fri, Sep 15, 2006 at 03:53:02PM +0200, Mark Rosenstand wrote:
On Fri, 2006-09-15 at 15:39 +0200, Tilman Sauerbeck wrote:
Mark Rosenstand [2006-09-15 15:33]:
non-existant, with the exception that the former get to wear a funny character in front of their IRC name. (On the other hand, they must really like it, since unlike most other project channels, they wear it all the time.)
Hint: you're helping noone by making comments like this.
Sorry, I'm just a bit annoyed by the thought that this could likely be one of the reasons some "developers" want to keep the seperation.
Clearly a dedicated "IRC police" team would prevent this - for me, it's hard to see the association between repo commit rights and ability to judge when someone is abusing an IRC channel. But obviously I'm ignoring the e-penis factor.
Mark, I'd suggest that you calm down a little bit. Finally you have to accept that you are not in the position to decide anything regarding CRUX beside not using it anymore. If you are not able to simply accept a clear statement like the one from Johannes, it would be better for all of us if you forbear posting to this list in the future. Jürgen -- Juergen Daubert | mailto:jue@jue.li Korb, Germany | http://jue.li/crux
On Fri, Sep 15, 2006 at 16:29:14 +0200, Juergen Daubert wrote: [...]
Mark,
I'd suggest that you calm down a little bit. Finally you have to accept that you are not in the position to decide anything regarding CRUX beside not using it anymore. If you are not able to simply accept a clear statement like the one from Johannes, it would be better for all of us if you forbear posting to this list in the future.
+1 Johannes -- Johannes Winkelmann mailto:jw@smts.ch Zurich, Switzerland http://jw.smts.ch
On Fri, Sep 15, 2006 at 15:33:15 +0200, Mark Rosenstand wrote: [...]
Yes, and what I'm saying is that with the new contrib, the difference between "developers" (the non-core kind) and "contributors" is close to non-existant, with the exception that the former get to wear a funny character in front of their IRC name. (On the other hand, they must really like it, since unlike most other project channels, they wear it all the time.) There's actually no direct relationship between the two; the IRC op is for IRC regulars (at some point) from the crux team, some sort of dedicated IRC crew.
The main difference is that we only choose people for opt (and core) which have the right attitude. HTH, Johannes -- Johannes Winkelmann mailto:jw@smts.ch Zurich, Switzerland http://jw.smts.ch
On Fri, Sep 15, 2006 at 08:40:28AM +0200, Johannes Winkelmann wrote:
Hi again,
On Wed, Sep 13, 2006 at 21:49:07 +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. [...] - Potential improvement of quality in ports.
Considering these goals, I'm not sure if we should keep the conditions to join as low as they are now.
I'm in particular thinking that the way contributors appear in public will reflect back on the whole project (that holds of course true for all of us, not only the contrib guys!). IMHO we should therefore require a solid knowledge on CRUX, and an okay reputation both amongst users and devs.
Also, the current contrib rules are somewhat lengthy, and contain some historic stuff ("CLC maintainer"); it might be a good idea do rewrite them with the new situation in mind, and make it easier to grasp at the same time.
Comments?
Agreed on both, thanks for the proposal. Regards Jürgen -- Juergen Daubert | mailto:jue@jue.li Korb, Germany | http://jue.li/crux
participants (7)
-
Anton -
Johannes Winkelmann -
Juergen Daubert -
Mark Rosenstand -
Simon Gloßner -
Simone Rota -
Tilman Sauerbeck