[gentoo-dev] Gentoo: State of the Union
Having a live tree requires people to be perfect. People are not perfect and requiring it is ridiculous. I love having commits in my local tree within the hour, but having a stable and unstable branch makes a lot of sense. Does it? How does having a stable and unstable branch differ from having stable and unstable keywords? Agreed. That doesn't make sense. Subversion has what is known as pre-commit hooks. Using those it's very easy to: * prevent (most or some) committers from designating ebuilds as stable * allow committers to designate ebuilds as stable under a certain path only * strictly limit a commiters access to a part of the tree Slightly harder, but could be done too: * deny commits if it breaks ebuild dependencies If you want central control of what's happening in the repository, Subversion seems like the way to go. SVN requires at least 2x the tree size for storage on the local machine, This is a feature, not a bug. It allows you to keep operations local, fx. do a diff without being online with the repository. checkouts take something akin to an order of magnitude longer than CVS. In the past Subversion performance was sub-par. I haven't systematically tested performance, but I would expect it to be much better now. Performance is gradually improved, see fx. r18867, r18944 and r19420: http://svn.collab.net/viewvc/svn?view=revrevision=18867 http://svn.collab.net/viewvc/svn?view=revrevision=18944 http://svn.collab.net/viewvc/svn?view=revrevision=19420 GIT might perform better, since Linus specifically emphasized non-O(n^2) performance in the design. But being a decentralized tool, I'm not sure how well it fits the needs here. The former is annoying, but liveable, but the latter is a deal-breaker. I don't think so. You really rarely do a complete checkout. - No changeset/merge tracking Solutions exist, including svnmerge and svk. Official solution actively worked on at the moment, check out the svn dev list. A benefit of Subversion that I personally like is that FSFS repositories are extremely easy to rsync. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Gentoo: State of the Union
Quoting Molle Bestefich [EMAIL PROTECTED]: Does it? How does having a stable and unstable branch differ from having stable and unstable keywords? Agreed. That doesn't make sense. It does if you have a separate stable tree per-arch. With the current tree design, it's too easy to break an arch that you've no intention of affecting. However, if you have a separate tree per-arch, that tree can be tested and approved for release as a single unit. From a SCM point of view, arches are a subset of the full Gentoo tree. They would fit very well into a branching model - and Subversion's support for branching would make it a breeze for us to support without overloading the arch teams. If you want central control of what's happening in the repository, Subversion seems like the way to go. Better to fix the design of the repository, so that it can't be broken in the first place, than to try putting band-aids in place to cover the gaps. I don't think so. You really rarely do a complete checkout. I'd be interested to see some stats from our CVS logs to back that up. Best regards, Stu -- Stuart Herbert [EMAIL PROTECTED] Gentoo Developer http://www.gentoo.org/ http://blog.stuartherbert.com/ GnuGP key id# F9AFC57C available from http://pgp.mit.edu Key fingerprint = 31FB 50D4 1F88 E227 F319 C549 0C2F 80BA F9AF C57C -- This message was sent using IMP, the Internet Messaging Program. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Gentoo: State of the Union
On Thu, 2006-05-04 at 11:44 +0100, Stuart Herbert wrote: From a SCM point of view, arches are a subset of the full Gentoo tree. They would fit very well into a branching model - and Subversion's support for branching would make it a breeze for us to support without overloading the arch teams. Are you kidding me? What about people that commit for multiple arches? They're now going to have to do the same commit over $x number of trees? How exactly will that not overload the arch teams? The more I hear about all of these great features of qall of these alternative SCM's, the more I think that somebody just has a hard-on for getting rid of CVS and plans on doing it, no matter the cost to efficiency and other developers. No, I'm pointing to anyone in particular. It just seems that everyone wants to blame CVS for our problems, when our problems are almost entirely cultural. Seriously, if I were forced to commit to multiple trees, or branches, or whatever, I'd simply leave the project since it would be such an enormous waste of time. I'm sure lots of others feel the same. Our version control system is supposed to be a tool to help us get our work done, not a hindrance. -- Chris Gianelloni Release Engineering - Strategic Lead x86 Architecture Team Games - Developer Gentoo Linux signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Gentoo: State of the Union
On 5/4/06, Chris Gianelloni [EMAIL PROTECTED] wrote: On Thu, 2006-05-04 at 11:44 +0100, Stuart Herbert wrote: From a SCM point of view, arches are a subset of the full Gentoo tree. They would fit very well into a branching model - and Subversion's support for branching would make it a breeze for us to support without overloading the arch teams. Are you kidding me? What about people that commit for multiple arches? They're now going to have to do the same commit over $x number of trees? How exactly will that not overload the arch teams? Talking about an SVN perspective ... provided the trees live in a single repository (which would make a lot of sense), it would be very straightforward to provide a tool to copy a particular ebuild its files from an unstable tree simultaneously to the other trees. The difficulties with such a tool would be taking over the right files/ contents (something which is solveable), and what to do about signing (where a distribtued system like Git probably makes much more sense anyway). Given such a tool, you could promote a version of a package to any number of per-arch trees at the same time. The more I hear about all of these great features of qall of these alternative SCM's, the more I think that somebody just has a hard-on for getting rid of CVS and plans on doing it, no matter the cost to efficiency and other developers. What we're talking about here is a step in the development cycle commonly called 'integration', where something's taken from the development bucket, put into the 'release' bucket, and tested to ensure that it plays nice with everything else already in the 'release' bucket. It should be listed in RUP, CMM, or whatever development methodology you use locally in your day job. Adopting this approach would be far more painful with CVS than with (say) subversion. Branch management in subversion is infinitely easier than with CVS. Best regards, Stu -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Gentoo: State of the Union
On Thu, 04 May 2006 11:44:18 +0100 Stuart Herbert [EMAIL PROTECTED] wrote: However, if you have a separate tree per-arch, that tree can be tested and approved for release as a single unit. How big would this tree be? Would it be every package? How will this make the arch teams' life easier and/or the users' experience better? I still fail to see how this will work any differently than what we have today. Today we have ~arch, someone tests the package for stability on an arch system, and marks it stable. The tester is effectively integrating the package into a stable system. Maybe you could explain how the procedure might go with branches for getting a package from just put into the tree to ~arch to arch and what happens with version bumps. ~tcort pgp4rW3LFoaWO.pgp Description: PGP signature
Re: [gentoo-dev] Gentoo: State of the Union
On Thursday 04 May 2006 14:17, Stuart Herbert wrote: Talking about an SVN perspective ... provided the trees live in a single repository (which would make a lot of sense), it would be very straightforward to provide a tool to copy a particular ebuild its files from an unstable tree simultaneously to the other trees. The difficulties with such a tool would be taking over the right files/ contents (something which is solveable), and what to do about signing (where a distribtued system like Git probably makes much more sense anyway). The files content problem should be solved anyway. That way one could even make selfcontained ebuild packages including source. A way of distributing that would be more appropriate for external ebuilds. Paul -- Paul de Vrieze Gentoo Developer Mail: [EMAIL PROTECTED] Homepage: http://www.devrieze.net pgpImatmLNLKQ.pgp Description: PGP signature
Re: [gentoo-dev] Gentoo: State of the Union + suggestion for global dev conference (at bottom, if you want to skip)
On Sunday 30 April 2006 03:55, Lance Albertson wrote: Here's an idea I had tonight. Since we're going to be doing the Google SoC this summer, perhaps a great project would be having someone work on this migration (or at least do an unbiased test implementation). I'd be willing to provide an infra server for testing/development. I don't see much problem at least trying to work out all the details. I don't think infra will go with any change unless there is a clear, detailed migration plan with proper back-out plans also. The tree is the most important part of our distribution and I'm not going to let such a migration go by without proper planning and testing. After the test implementation is done and has been fully tested, perhaps the council could make the final decision if infra is happy with the implementation/migration details. I think that is a good idea. It's a perfect google SoC project as it has a clear boundary. Limited prerequisite knowledge is required, and it is something we would really benefit from. Paul ps. Perhaps the SoC project could include fixing up the migration tools (for example including the hypothesis that all ebuilds for a package descend from eachother) and other coding necessary to make things work perfectly. -- Paul de Vrieze Gentoo Developer Mail: [EMAIL PROTECTED] Homepage: http://www.devrieze.net pgpWMiUJy2oP0.pgp Description: PGP signature
Re: [gentoo-dev] Gentoo: State of the Union + suggestion for global dev conference (at bottom, if you want to skip)
On Wed, 2006-05-03 at 11:43 +0200, Paul de Vrieze wrote: On Sunday 30 April 2006 03:55, Lance Albertson wrote: Here's an idea I had tonight. Since we're going to be doing the Google SoC this summer, perhaps a great project would be having someone work on this migration (or at least do an unbiased test implementation). I'd be willing to provide an infra server for testing/development. I don't see much problem at least trying to work out all the details. I don't think infra will go with any change unless there is a clear, detailed migration plan with proper back-out plans also. The tree is the most important part of our distribution and I'm not going to let such a migration go by without proper planning and testing. After the test implementation is done and has been fully tested, perhaps the council could make the final decision if infra is happy with the implementation/migration details. I think that is a good idea. It's a perfect google SoC project as it has a clear boundary. Limited prerequisite knowledge is required, and it is something we would really benefit from. Paul ps. Perhaps the SoC project could include fixing up the migration tools (for example including the hypothesis that all ebuilds for a package descend from eachother) and other coding necessary to make things work perfectly. Hiya, If one of you drop us a line of what you want included on the ideas page, or pop into #gentoo-soc on irc.freenode.net we'll get it up there. :) Keep in mind, student applications close on the 8th of May, so the sooner the better. Christel -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Gentoo: State of the Union
On Friday 28 April 2006 21:20, Grant Goodyear wrote: Ryan Phillips wrote: [Fri Apr 28 2006, 01:57:30PM CDT] I disagree. The developers should make *all* the decisions. Originally, Gentoo was effectively a meritocracy. It's now, in some respects, a republic. If you want a democracy, feel free to draft a new metastructure proposal (feel free to name it something less awkward), and drum up support to get it voted upon. Bypass the council. The council should be there only for when we get sued, and manage the money we make. For what it's worth, the Council does neither of those things. That's what the Gentoo Foundation is for. Does anyone agree that having a council is too political? I strongly believe it stifles gentoo. Do you have some specific examples of how you've seen the Council stifle Gentoo, or is it mainly just a general impression? I generally agree with you. I've not seen the council stifle anything (except that it perhaps could have encouraged more). Any stifling is more because the large amount of inertia caused by the big amount of developers. As for abolishing the quiz, I'm strongly opposed to that. The quiz is a hurdle that is there for a reason. Partly it shows determination. It also filters out those people who don't know when they don't know something. We have developer documentation for a reason. The quiz ensures that everyone knows that we have it. Paul -- Paul de Vrieze Gentoo Developer Mail: [EMAIL PROTECTED] Homepage: http://www.devrieze.net pgppBZT3o6Cal.pgp Description: PGP signature
Re: [gentoo-dev] Gentoo: State of the Union
On Saturday 29 April 2006 19:52, Donnie Berkholz wrote: Jan Kundrát wrote: Ryan Phillips wrote: Stable and unstable keywords are a hack on top of a version control system. We wouldn't have them if gentoo used an SCM that supports true branches. There would be no need. Umm, I'm not an ebuild dev, but how would users mix stable and unstable packages in such a case? They would probably have to check out two trees. But the two trees combined would likely be the same size as the single tree now, since a lot of packages have at least two ebuilds available, one ~arch and one stable. The real showstopper in my mind is that having a single ~arch and a single stable tree means you can't selectively stable things on different architectures at different times. Agreed, the main advantage of a proper vcs would be that the ancestry between different ebuild versions would be visible. This would make it even possible to merge back working changes from a testing version to a stable version without gambling that it will work. Paul -- Paul de Vrieze Gentoo Developer Mail: [EMAIL PROTECTED] Homepage: http://www.devrieze.net pgp4tFTO5NwuU.pgp Description: PGP signature
Re: [gentoo-dev] Gentoo: State of the Union
On 30/04/06, Henrik Brix Andersen [EMAIL PROTECTED] wrote: On Sun, Apr 30, 2006 at 12:50:45AM -0700, Donnie Berkholz wrote: While we're posting useful links, here's another one from the cairo project on switching from CVS to some distributed SCM: All this talk about switching to a more powerful SCM I can understand - but what would the purpose of switching the portage tree to a distributed SCM be? The main purpose that comes to mind is to help the groups working in overlays (layman -L shows 28 current overlays; there may be more). It should enable easier merging of trees, local tree management, sharing experimental changes between devs without commiting to the main tree, while still retaining the possibility of easily pushing changes back to the main gentoo tree. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Gentoo: State of the Union
On Mon, 2006-05-01 at 13:23 +0100, Chris Bainbridge wrote: The main purpose that comes to mind is to help the groups working in overlays (layman -L shows 28 current overlays; there may be more). It should enable easier merging of trees, local tree management, sharing experimental changes between devs without commiting to the main tree, while still retaining the possibility of easily pushing changes back to the main gentoo tree. Hrm. Don't we get that benefit only if the overlays switch over to using the same distributed VCS that the main tree moves to? Best regards, Stu -- Stuart Herbert [EMAIL PROTECTED] Gentoo Developer http://www.gentoo.org/ http://blog.stuartherbert.com/ GnuGP key id# F9AFC57C available from http://pgp.mit.edu Key fingerprint = 31FB 50D4 1F88 E227 F319 C549 0C2F 80BA F9AF C57C -- signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Gentoo: State of the Union
Stuart Herbert wrote: Hrm. Don't we get that benefit only if the overlays switch over to using the same distributed VCS that the main tree moves to? The short answer is yes. The long answer is that it's much easier to interconvert histories between most DVCS's than to convert back and forth between file-based history systems like CVS. One could plausibly and sanely export any commits from their mercurial overlay into e.g. git (or whatever ends up happening), suitable for merging into the official tree. Thanks, Donnie -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Gentoo: State of the Union
Alexandre Buisse wrote: The opensolaris project has done a similar thing[1]. While we're posting useful links, here's another one from the cairo project on switching from CVS to some distributed SCM: http://lists.freedesktop.org/archives/cairo/2006-February/006255.html Thanks, Donnie -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Gentoo: State of the Union
Alexandre Buisse wrote: [1] http://mail.opensolaris.org/pipermail/tools-discuss/2006-April/000366.html [2] http://www.opensolaris.org/os/community/tools/scm/bzr-eval/ [3] http://www.opensolaris.org/os/community/tools/scm/dcm_evaluation_mercurial/ [4] http://www.opensolaris.org/os/community/tools/scm/git-eval.txt Those figures are slightly old, some of the issues are probably addressed both on mercurial and git. I'd say that both are nice and are probably a good solution. if there is space and cpu I'd like to have someone playing with them and send benchmark results. Mercurial should use a bit less disk and git should be a little faster and with better merge/conflict resolution features. lu -- Luca Barbato Gentoo/linux Gentoo/PPC http://dev.gentoo.org/~lu_zero -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Gentoo: State of the Union
Luca Barbato wrote: Alexandre Buisse wrote: [1] http://mail.opensolaris.org/pipermail/tools-discuss/2006-April/000366.html [2] http://www.opensolaris.org/os/community/tools/scm/bzr-eval/ [3] http://www.opensolaris.org/os/community/tools/scm/dcm_evaluation_mercurial/ [4] http://www.opensolaris.org/os/community/tools/scm/git-eval.txt Those figures are slightly old, some of the issues are probably addressed both on mercurial and git. I'd say that both are nice and are probably a good solution. if there is space and cpu I'd like to have someone playing with them and send benchmark results. I am currently working on this, I have a page under proj/en/infrastructure where I am describing my efforts but I need a bit more time to make it pretty ;) Currently cvs2svn is almost done, and git cvsimport is chugging along. Not really a fan of bzr for us but we use it for pkgcore, so I'll fire that up as well. I haven't looked at mercurial but it is on the list ;) -Alec Warner Mercurial should use a bit less disk and git should be a little faster and with better merge/conflict resolution features. lu -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Gentoo: State of the Union
On Sun, Apr 30, 2006 at 12:50:45AM -0700, Donnie Berkholz wrote: While we're posting useful links, here's another one from the cairo project on switching from CVS to some distributed SCM: All this talk about switching to a more powerful SCM I can understand - but what would the purpose of switching the portage tree to a distributed SCM be? Regards, Brix -- Henrik Brix Andersen [EMAIL PROTECTED] Gentoo Metadistribution | Mobile computing herd pgpa08H1Uq7kt.pgp Description: PGP signature
Re: [gentoo-dev] Gentoo: State of the Union
Ryan Phillips wrote: Stable and unstable keywords are a hack on top of a version control system. We wouldn't have them if gentoo used an SCM that supports true branches. There would be no need. Umm, I'm not an ebuild dev, but how would users mix stable and unstable packages in such a case? Cheers, -jkt -- cd /local/pub more beer /dev/mouth signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Gentoo: State of the Union
On Friday 28 April 2006 20:14, Ryan Phillips wrote: __Problem: Live Tree__ Having a live tree requires people to be perfect. People are not perfect and requiring it is ridiculous. I love having commits in my local tree within the hour, but having a stable and unstable branch makes a lot of sense. CVS doesn't do branching nor tags very well... __Problem: CVS__ CVS is one of the worst application ever created. The portage tree needs to move to subversion. A lot of the problems within the project would be solved by using a better SCM system. The previous problems regarding the Live Tree and Developer Growth would be solved, IMHO, by just switching. Branches Work. Tags Work. Reverts work. Moves work. I don't see any reason not to use it. It just plain works. Projects (gentoo/bsd, embedded, hardened) could choose to keep their own branches of the portage tree and merge with trunk as needed. Projects could stick to traditional solutions like profiles if they so wished. Some will probably ask who will merge between branches. We can do that easily ourselves. If I think a package is good to go, then svn merge -r1123:1124 to the branch. I'm very much in favor of moving to a new SCM, and I see how it could solve many problems. But I don't understand how it could remove the need for a live tree. Could you explain the new usage pattern you're suggesting here? If there's no live tree (or live branch), then every commit has to be merged from the 'incoming' branch or trunk where it is originally committed to the 'outgoing' branch which is directly used by users, even for ~arch chages. Is that really what you mean? And this becomes a lot worse if you want to replace (at least some) KEYWORDS with branches, and have to merge each change many times. Meanwhile, if no-one is using trunk (or the 'incoming' branch) directly (because it's not live), what is the benefit of leaving commits there for a few hours? It won't help you find most problems. Apart from having no live tree, though, I understand and like the model of having: - 'Incoming' (sandbox) branches where non-dev affiliates, and new devs, commit things which are then reviewed by a full dev/mentor and merged into trunk. - Branches replacing today's various overlays for devs (or projects, etc) and anyone else we might welcome on g.o infrastructure (given per-branch commit permissions). - Short-lived branches to replace things that are today package.masked. - Branches to replace various non-arch keywords and projects, like hardened stuff, some server/ultrastable tree proposals, ... -- Dan Armak Gentoo Linux developer (KDE) Public GPG key: http://dev.gentoo.org/~danarmak/danarmak-gpg-public.key Fingerprint: DD70 DBF9 E3D4 6CB9 2FDD 0069 508D 9143 8D5F 8951 pgp7hV8KLhwgg.pgp Description: PGP signature
Re: [gentoo-dev] Gentoo: State of the Union
On Friday 28 April 2006 23:42, Ryan Phillips wrote: svn + Atomic Commits + Merging/tagging/brancing is a simple copy operation http://svnbook.red-bean.com/en/1.1/ch04.html + lots of benefits http://svnbook.red-bean.com/nightly/en/svn.intro.features.html there is more I'm sure people can come up with - 2x Drive space - No changeset/merge tracking If we have a lot of active branches and a lot of merging between them, changeset tracking could be a major plus. I've never used git but I've heard that it, and other distributed development-style SCMs, have changeset/merge tracking features that are really helpful. Could someone who's used them comment on this? -- Dan Armak Gentoo Linux developer (KDE) Public GPG key: http://dev.gentoo.org/~danarmak/danarmak-gpg-public.key Fingerprint: DD70 DBF9 E3D4 6CB9 2FDD 0069 508D 9143 8D5F 8951 pgpKK0WsRkHbd.pgp Description: PGP signature
Re: [gentoo-dev] Gentoo: State of the Union
On Sat, Apr 29, 2006 at 03:02:46PM +0300, Dan Armak wrote: On Friday 28 April 2006 23:42, Ryan Phillips wrote: svn + Atomic Commits + Merging/tagging/brancing is a simple copy operation http://svnbook.red-bean.com/en/1.1/ch04.html + lots of benefits http://svnbook.red-bean.com/nightly/en/svn.intro.features.html there is more I'm sure people can come up with - 2x Drive space - No changeset/merge tracking If we have a lot of active branches and a lot of merging between them, changeset tracking could be a major plus. I've never used git but I've heard that it, and other distributed development-style SCMs, have changeset/merge tracking features that are really helpful. Could someone who's used them comment on this? Yes, Git tracks merges unless the merge is trivial (aka fast-forward). When you merge branch 'a' into branch 'b' and 'b' is a strict subset of 'a' we call that a fast-forward, since there is no merge anywhere: o---o---o b \ x---x---x a If you merge 'a' into 'b' (git checkout b ; git pull . a) the result is: o---o---o---x---x---x a = b However in the following case, a proper merge is required: o---o---o---#---# b \ x---x---x a 'b' is not a strict subset of 'a' because the commits marked with # do not exist in 'a', so the thing ends up being: o---o---o---#---#---@ b \ / x---x---x a The commit marked with @ is a special comit called a 'merge'. I hope that clarifies the merge tracking part. However I don't know what do you mean with 'changeset tracking'. Cheers, Ferdy -- Fernando J. Pereda Garcimartín Gentoo Developer (Alpha,net-mail,mutt,git) 20BB BDC3 761A 4781 E6ED ED0B 0A48 5B0C 60BD 28D4 pgpeQGlULeJE4.pgp Description: PGP signature
Re: [gentoo-dev] Gentoo: State of the Union
On Saturday 29 April 2006 15:21, Fernando J. Pereda wrote: The commit marked with @ is a special comit called a 'merge'. I hope that clarifies the merge tracking part. You just described what merging is. Svn can do that too with svn merge. But, if I merge changesets from branch A to B selectively, skipping some along the way, can I later ask git to: - list the changesets remaining in A that I haven't merged to B yet? - list the branches, from a given list, which have/haven't merged a given changeset? Those are things svn can't do. However I don't know what do you mean with 'changeset tracking'. I didn't mean that 'changeset tracking' is different from 'merge tracking'. -- Dan Armak Gentoo Linux developer (KDE) Public GPG key: http://dev.gentoo.org/~danarmak/danarmak-gpg-public.key Fingerprint: DD70 DBF9 E3D4 6CB9 2FDD 0069 508D 9143 8D5F 8951 pgprs6FwXYu3W.pgp Description: PGP signature
Re: [gentoo-dev] Gentoo: State of the Union
On Sat, Apr 29, 2006 at 03:54:17PM +0300, Dan Armak wrote: On Saturday 29 April 2006 15:21, Fernando J. Pereda wrote: The commit marked with @ is a special comit called a 'merge'. I hope that clarifies the merge tracking part. You just described what merging is. Svn can do that too with svn merge. But, if I merge changesets from branch A to B selectively, skipping some along the way, can I later ask git to: - list the changesets remaining in A that I haven't merged to B yet? Yes, unless you used cherry-pick. You have to do *real* merges to be able to do that. - list the branches, from a given list, which have/haven't merged a given changeset? It depends on how you merged the changesets, if you did it sanely, yes, should be easy. If you used cherry-pick here and there I don't think so. I didn't mean that 'changeset tracking' is different from 'merge tracking'. Ok. - ferdy -- Fernando J. Pereda Garcimartín Gentoo Developer (Alpha,net-mail,mutt,git) 20BB BDC3 761A 4781 E6ED ED0B 0A48 5B0C 60BD 28D4 pgp5JAHZLyaXe.pgp Description: PGP signature
Re: [gentoo-dev] Gentoo: State of the Union
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 What is interesting is that Source Mage Linux has already voted on a proposal similar to mine[2]. I truly think that making some changes in the gentoo way would benefit us and make gentoo a truly better distribution. Ryan Gentoo Developer [1] http://article.gmane.org/gmane.linux.gentoo.devel/37599 [2] http://lists.ibiblio.org/pipermail/sm-discuss/2006-April/014069.html I would really like to hear more on [2], get something like it going, then we could all vote on the scm of choice this thread has succumb to. Although switching away from cvs is one of the many topics of this mail (and if you want a foundation for some of the others), it is not the only one. I would like to hear more on changing how we vote (unless you all really like how voting is done now, be it problem resolution or technical innovation), more on developer growth (we should be an open inviting community) and why you think stricter test make for better developers, why you think harder tests would cut down more on the quick in and out people. I don't just mean to hear the hells nos also the hells yeahs, especially those that are just reading and then thinking it. Daniel -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2.1 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFEU20L/aM9DdBw91cRAkPxAKCNB10kVHzVF+okuTc7Pc1Ysuza5QCcCdZ8 cYBVs1j9tBce2wTlCF7x7Tg= =WWf3 -END PGP SIGNATURE- -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Gentoo: State of the Union
On Fri, Apr 28, 2006 at 05:01:20PM -0500, Daniel Goller wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Thomas Cort wrote: On Fri, 28 Apr 2006 21:42:57 +0200 Bryan Østergaard [EMAIL PROTECTED] wrote: So.. What can we do to improve things? I think that there should be some sort of organized way of connecting potential mentors and potential recruits. There is a very enthusiastic user who has been contributing great work to my overlay, but I cannot find anyone to mentor him (I've e-mailed [EMAIL PROTECTED] as well as [EMAIL PROTECTED] without much success). Maybe we should create a list of developers who are willing to mentor new devs? It would make finding a mentor much easier. ~tcort wait till you have your required months at gentoo, then you mentor him, if you truly like his work, tell him you have to wait before you can mentor him, iirc 6 months from joining? Yup, 6 months as an ebuild developer is required before you can mentor new ebuild developers. In this case you might consider asking for a mentor on the gentoo-dev mailinglist seeing as [EMAIL PROTECTED] and [EMAIL PROTECTED] have't been able to find a mentor. Regards, Bryan Østergaard -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Gentoo: State of the Union
On Sat, Apr 29, 2006 at 08:41:31AM -0500, Daniel Goller wrote: inviting community) and why you think stricter test make for better developers, why you think harder tests would cut down more on the quick in and out people. Empirical evidence agrees. Our current quiz practices have done a good job keeping out a lot of the incompetence that used to slip through before we took that approach. Stricter tests make for more knowledgable developers and folks with a lack of commitment to Gentoo are usually not willing to tackle the learning curve. As for whether or not we're inviting or not, anybody can contribute. They don't need to be @gentoo.org to do so. What we really need is to focus more on those outside contributions. -- Jon Portnoy avenj/irc.freenode.net -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Gentoo: State of the Union
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jon Portnoy wrote: On Sat, Apr 29, 2006 at 08:41:31AM -0500, Daniel Goller wrote: inviting community) and why you think stricter test make for better developers, why you think harder tests would cut down more on the quick in and out people. Empirical evidence agrees. Our current quiz practices have done a good job keeping out a lot of the incompetence that used to slip through before we took that approach. Stricter tests make for more knowledgable developers and folks with a lack of commitment to Gentoo are usually not willing to tackle the learning curve. As for whether or not we're inviting or not, anybody can contribute. They don't need to be @gentoo.org to do so. What we really need is to focus more on those outside contributions. so that is where this is all coming from, who said that we should hand out @gentoo.org ? i never said that, they don't need it, and everyone gets to feel all special about the @gentoo.org the way they are used to, a committing contributor does not require a @gentoo.org and unless you give them a general aptitude and attitude test, you do not know a thing about the person who answered a few technical questions (more) Daniel -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2.1 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFEU3pZ/aM9DdBw91cRArKPAKCCr/9TYUc+VTqldUueqXN5RRCUWgCfbSH8 5QfB8r0xd2qAr018yFICd9o= =aMhC -END PGP SIGNATURE- -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Gentoo: State of the Union
On Fri, Apr 28, 2006 at 08:05:06PM -0500, Daniel Goller wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Simon Stelling wrote: Hi Ryan, Ryan Phillips wrote: I believe the way Gentoo is doing things is broken. There I have said it. The entire project has reached a level of being too political and trying to solve certain problems in the wrong way. I think it actually works quite well. Yes, there is space for improvement, like always, but the situation is at least not bad. how do you call it then if the entities in place make a decision, after some long winded strange tribunal, and when they made a decision, people ask hey where is my vote?, i am not after devrel, what i am saying is, noone appreciates their work it seems, so why couldn't they leave the decision making to a developer vote, with the saved time, they could go on and do something they enjoy/have fun with (those of you in devrel who enjoy your devrel work (wrt to conflict resolution) i am glad you do, i just don't think many at devrel enjoy hearing they are wrong no matter how they decide) the people affected by the vote could accept a developer vote much easier than a devrel decision __Problem: Developer Growth__ I find that developer growth as being a problem. Adding a developer to gentoo should be as easy as 1. has the user contributed numerous (~5+) patches that helps the project move forward. If yes, then commit access should be given. Adding a developer is usually quite a chore. There are numerous reasons why this is a problem: having a live tree, taking a test, and not defining within policy when a person could possibly get commit access. I can only speak for me here, but the quiz wasn't a barrier at all to me. Instead, it was an interesting way to make sure that I get familiar with all the stuff I have to. I found it a much better way to answer questions about a topic where you have to find the answers than just reading through tons of docs, not knowing whether something is important to you or completely unrelated. and we also have lost developers that projects were eager to get on the team, from what i recall over the developer questioning why an official quiz must be answered by finding things in unofficial docs in dev spaces no, that is not hard, but the question was valid, and with the whole process allowing all of gentoo to make this possible or not, a developer should be put in place by the leads of that project, at the project leads discretion, they know the people they plan on hiring much better than we know most people in our AT program, ATs have been turned into devs after a very short time, the quiz is a silly hurdle if it gages your ability to google, not your ability to write ebuilds You're probably able to answer the quiz questions correctly by googling (that's on of the goals as we don't want every new developer reading through all the portage code..) but you're not going to become a developer that way. After having the quiz answers approved by your mentor you'll have to talk to your recruiter who'll gauge whether or not to add you as a new developer. As part of that we're asking additional questions (usually both technical and organisational questions). I sometimes think of this as a very condensed form of super mentoring as it also very much helps prepare new developers getting their commit access. I often ask new people that I recruit if they think I'm being too hard on them (after approving them as new devs). So far they've all said it was very good and that they learned some important things that way. This is of course a very informal survey but I think it shows that new developers (in general) don't think the process is too hard. Besides that, I think the tree is far too worthy to give it away after 5 patches. Just because I fixed a bunch of compiling errors, that doesn't mean I know how to fix ebuilds. Just because I wrote a few ebuilds, that doesn't mean I understand how eclasses work, which ones to use where and what profile.bashrc is good for. we are too possessive, if you give out access to a non-live tree, and you see the commits were not fit for merging, and the person in question does not learn from advise given, the person does not have to keep commit access, but it would be nice to be more inviting than to keep our high and mighty attitude, we are not so different from our users, many of which are far better than we are, we just passed some strange test you can pass by cut paste or paraphrasing from the right docs, you can do that w/o even knowing what you talk about You're wrong, see above :) I've seen ebuilds from people who have written quite a bunch of ebuilds and were really interested in understanding how they work, but the work they produced just was awful and hurt my eyes. I don't mean that the mean way, I don't expect anything else, and I was just the
Re: [gentoo-dev] Gentoo: State of the Union
On Sat, Apr 29, 2006 at 09:38:17AM -0500, Daniel Goller wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jon Portnoy wrote: On Sat, Apr 29, 2006 at 08:41:31AM -0500, Daniel Goller wrote: inviting community) and why you think stricter test make for better developers, why you think harder tests would cut down more on the quick in and out people. Empirical evidence agrees. Our current quiz practices have done a good job keeping out a lot of the incompetence that used to slip through before we took that approach. Stricter tests make for more knowledgable developers and folks with a lack of commitment to Gentoo are usually not willing to tackle the learning curve. As for whether or not we're inviting or not, anybody can contribute. They don't need to be @gentoo.org to do so. What we really need is to focus more on those outside contributions. so that is where this is all coming from, who said that we should hand out @gentoo.org ? i never said that, they don't need it, and everyone gets to feel all special about the @gentoo.org the way they are used to, a committing contributor does not require a @gentoo.org That's called a figure of speech -- I was not literally referring to the email address but rather Gentoo developer status. Sorry for being unclear. My point was more that commit access is not a prerequisite to contribute. and unless you give them a general aptitude and attitude test, you do not know a thing about the person who answered a few technical questions (more) Sure you do. You know whether they know what they're doing in the tree. -- Jon Portnoy avenj/irc.freenode.net -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Gentoo: State of the Union
Jan Kundrát wrote: Ryan Phillips wrote: Stable and unstable keywords are a hack on top of a version control system. We wouldn't have them if gentoo used an SCM that supports true branches. There would be no need. Umm, I'm not an ebuild dev, but how would users mix stable and unstable packages in such a case? They would probably have to check out two trees. But the two trees combined would likely be the same size as the single tree now, since a lot of packages have at least two ebuilds available, one ~arch and one stable. The real showstopper in my mind is that having a single ~arch and a single stable tree means you can't selectively stable things on different architectures at different times. Thanks, Donnie -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Gentoo: State of the Union + suggestion for global dev conference (at bottom, if you want to skip)
Hi Ryan, I hope you find these comments useful. On Fri, 2006-04-28 at 10:14 -0700, Ryan Phillips wrote: __Problem: Developer Growth__ Why do people have to take a test? There are certain skills we need a developer to demonstrate before we can give them commit access. There is currently no opportunity for a would-be-developer to demonstrate all of those skills before they get commit access. This is where working in overlays has helped some groups. It gives would-be-devs an opportunity to learn and develop the skills they would need to become Gentoo developers. But I don't see overlays as a replacement for our tests ... they're only a training ground to help get people ready to take the tests. The magic thing about Gentoo is that everything finds its own level. That's our secret formula. If an area of working with Linux is important enough to enough people, Gentoo becomes strong in that area, and its weaknesses reflect where something simply isn't important enough for people to make an effort. It's a beautiful thing when it works. It's also the thing that puts a lot of people off. Many people fear uncertainty. They need to exist within a plan or some sort of structure in order to be able to function. Our approach is uncertainty in motion. Your only guarantee is what rsync delivered this morning. The master plan is simply to deliver what $UPSTREAM invents, as close to what $UPSTREAM intended as possible. That's a different world to what most people know, and it's a message we do a piss poor job of communicating to anyone and everyone. __Problem: Live Tree__ Having a live tree requires people to be perfect. People are not perfect and requiring it is ridiculous. I love having commits in my local tree within the hour, but having a stable and unstable branch makes a lot of sense. We have one live tree that is trying to be all things to all people. It's a development tree (package.mask), it's a testing tree (~arch), it's a production tree (one tree per arch). The tree isn't robust or resilient - one mistake intended for the development tree can break the other two trees. Splitting up the tree into two - development/testing arch trees - would be the sensible thing to do. The counter argument here is that the arch trees would wither and die, because all the fun would be happening in the other trees. I don't buy that for an instant. Simply make the arch trees the default on the install media, and 80% of the userbase will never even notice that the other tree even exists. __Problem: CVS__ CVS is one of the worst application ever created. Hear, hear. I'd like to see a move to Subversion made a priority for 2006. If there are problems with Subversion's performance with our tree, engage with its authors to obtain improvements. But get it done. __Problem: QA Policies__ http://article.gmane.org/gmane.linux.gentoo.devel/37544 It seems that the QA Policies are a product of a Live Tree, and going partially non-live would solve the problems listed. I can see the point, but I don't agree. Those behind that proposal mean well, but I personally feel that their focus isn't where it will do the most good. The proposals that Mark has posted on -dev are for a reactive, enforcement-first team that's focused on applying coding standards across all our packages. A proactive, education-led team that's focused on finding out what's actually hurting our users will deliver more benefit to Gentoo in a shorter period of time. Give a man a fish, and you feed him for a day. Teach him how to fish, and you feed him for a lifetime. It's not hokum. Conflict resolution should not be a subproject. It should *not* exist at all. Rules need to be in place to avoid conflict. Having some sort of voting structure for all the developers (this doesn't mean requiring everyone to vote) and not just the council or devrel makes a lot of sense for most things. If I don't like how someone is acting within the project there should be a vote and then see if that person is kicked out. No trial, no anything besides a vote. And if I lose I have to deal with it. Either stay with the project, or find something else. This solution just works. Man is a political animal, and this sort of voting structure I find too simplistic and too naive. How does it cope with the malicious dev who takes every opportunity to slander another one behind their back? If you tell someone something often enough, people accept it as the truth - even if it's a lie. And people are lazy. They'll take information from someone they trust, and not take the trouble to learn whether or not that information is true. That's why advertising works :) In any organisation, you have to have key people who understand what the organisation is about, and who police it to get rid of those people who from the inside are subverting and attacking the organisation's culture. An organisation's culture is it's immune
Re: [gentoo-dev] Gentoo: State of the Union + suggestion for global dev conference (at bottom, if you want to skip)
On Sat, Apr 29, 2006 at 10:33:11PM +0100, Stuart Herbert wrote: __Problem: Developer Growth__ Why do people have to take a test? There are certain skills we need a developer to demonstrate before we can give them commit access. There is currently no opportunity for a would-be-developer to demonstrate all of those skills before they get commit access. That and the test is standardized: the range of questions it asks people should know the answer to. That's why we have recruiters and don't give out access to anybody... But I don't see overlays as a replacement for our tests ... they're only a training ground to help get people ready to take the tests. +1 The magic thing about Gentoo is that everything finds its own level. That's our secret formula. If an area of working with Linux is important enough to enough people, Gentoo becomes strong in that area, and its weaknesses reflect where something simply isn't important enough for people to make an effort. It's a beautiful thing when it works. That's the beauty of community-based distros -- with a commercial distro you can just wave cash and most of the time, things get done. We can't do that but sooner or later somebody who has the necessary skills to fix the problems starts shouting and problems do get fixed. It's also the thing that puts a lot of people off. Many people fear uncertainty. They need to exist within a plan or some sort of structure in order to be able to function. Our approach is uncertainty in motion. Your only guarantee is what rsync delivered this morning. Yeah, and this is the problem we need to solve to get more corporate adoption. The master plan is simply to deliver what $UPSTREAM invents, as close to what $UPSTREAM intended as possible. That's a different world to what most people know, and it's a message we do a piss poor job of communicating to anyone and everyone. Yeah, I think Gentoo's only real PR to users is Here you go, try it. Those that do soon find out a lot of things just work which is exactly what people want. Splitting up the tree into two - development/testing arch trees - would be the sensible thing to do. The counter argument here is that the arch trees would wither and die, because all the fun would be happening in the other trees. I don't buy that for an instant. Simply make the arch trees the default on the install media, and 80% of the userbase will never even notice that the other tree even exists. I don't think this will work. Your major problem is going to be merging changes from users working on the arch trees to the dev trees and vice- versa... users would (unknowingly) work on the arch trees (possibly on some pretty serious changes) and then be told none of them apply any longer. The advantage of one tree is that development is streamlined and is always going in one direction - forward. With large branching this is still doable. But it needs time and more importantly people and also the motivation to do the job. And that usually means $$$. Those behind that proposal mean well, but I personally feel that their focus isn't where it will do the most good. The proposals that Mark has posted on -dev are for a reactive, enforcement-first team that's focused on applying coding standards across all our packages. A proactive, education-led team that's focused on finding out what's actually hurting our users will deliver more benefit to Gentoo in a shorter period of time. Give a man a fish, and you feed him for a day. Teach him how to fish, and you feed him for a lifetime. It's not hokum. I think that's the underlying idea -- if developers aren't up to scratch the QA team would notice this pretty quickly and teach the man how to fish the proper way. Man is a political animal, and this sort of voting structure I find too simplistic and too naive. How does it cope with the malicious dev who takes every opportunity to slander another one behind their back? If you tell someone something often enough, people accept it as the truth - even if it's a lie. And people are lazy. They'll take information from someone they trust, and not take the trouble to learn whether or not that information is true. That's why advertising works :) +1 In any walk of life, it's a sad but true fact that most of the staff in most organisations do not get what the organisation is, and what its culture is, to the extent that they can be trusted to preserve it without assistance. Every one of us has a unique perspective on the world, and no two of us have an identical perspective. In one aspect that's what makes Gentoo work. Somebody comes along with a product/idea and somebody else comes along with can I make it flexible enough to also do X, Y and Z? [Look at catalyst, for example] Gentoo should be a fun environment. I don't see how turning it into a popularity contest brings back the fun. +1. Things generally do need a management structure. I think
Re: [gentoo-dev] Gentoo: State of the Union
Alexandre Buisse wrote: The opensolaris project has done a similar thing[1]. The three finalists were bazaar[2], mercurial[3] and git[4], and the winner was eventually mercurial. This is also the recommended choice from the EuroBSDcon slides, so definitely something to consider. Indeed, although EuroBSDcon didn't even analyze git, just mentioned it in passing. It also seems that we have a fair lack of expertise relating to it, but there has been no shortage of contributions about subversion and git, at least. The problem I had with the opensolaris testing is that they didn't seem to do any direct comparisons between the SCMs -- they were all isolated and based on a requirements doc. This makes it difficult to easily figure out how they balance out. There have been a fair number of changes since the version of git analyzed in the opensolaris testing (1.2.2). Thanks, Donnie -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Gentoo: State of the Union + suggestion for global dev conference (at bottom, if you want to skip)
Stuart Herbert wrote: __Problem: CVS__ CVS is one of the worst application ever created. Hear, hear. I'd like to see a move to Subversion made a priority for 2006. If there are problems with Subversion's performance with our tree, engage with its authors to obtain improvements. But get it done. /me puts on his admin hat Its going to be a bitch to switch to anything and it would be great to have some quantitative (unbiased) proof that such a move will add enough benefit for developers and Gentoo to be worth it. Truthfully, I don't know much about the other VC's out there (git, subversion, etc). But from what I do know, I would say that subversion has the best bet to be our preferred replacement. /me puts on his dev hat From what I've heard, subversion offers the best features and flexibility of the other VC's out there. Granted git has some nice features too, but I'd have to evaluate what we really need. /me puts on his neutral hat Subversion would be the best bet now because of viewcvs (now viewvc) support for it. Changing version control software is going to take a *bunch* of work. Things I can think of off the top of my head that will need work will be: * repoman support * portage regen tools on the master mirror * developer documentation * developer training (amazing concept!) * massive testing of all issues Here's an idea I had tonight. Since we're going to be doing the Google SoC this summer, perhaps a great project would be having someone work on this migration (or at least do an unbiased test implementation). I'd be willing to provide an infra server for testing/development. I don't see much problem at least trying to work out all the details. I don't think infra will go with any change unless there is a clear, detailed migration plan with proper back-out plans also. The tree is the most important part of our distribution and I'm not going to let such a migration go by without proper planning and testing. After the test implementation is done and has been fully tested, perhaps the council could make the final decision if infra is happy with the implementation/migration details. I'm sure there are going to be unseen issues we won't know about until we try a migration. It would be neat if I could provide a developer restricted rsync module on the test box so that they can actually try using their systems on there. Anyways, I'd just thought I'd give my input since its going to need to go through us eventually :). If people like the idea of having a SoC project for this, let me know and I'll have user-rel add that to the list. Cheers- -- Lance Albertson [EMAIL PROTECTED] Gentoo Infrastructure | Operations Manager --- GPG Public Key: http://www.ramereth.net/lance.asc Key fingerprint: 0423 92F3 544A 1282 5AB1 4D07 416F A15D 27F4 B742 ramereth/irc.freenode.net signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Gentoo: State of the Union + suggestion for global dev conference (at bottom, if you want to skip)
On Sat, Apr 29, 2006 at 08:55:52PM -0500, Lance Albertson wrote: Stuart Herbert wrote: __Problem: CVS__ CVS is one of the worst application ever created. Hear, hear. I'd like to see a move to Subversion made a priority for 2006. If there are problems with Subversion's performance with our tree, engage with its authors to obtain improvements. But get it done. Here's an idea I had tonight. Since we're going to be doing the Google SoC this summer, perhaps a great project would be having someone work on this migration (or at least do an unbiased test implementation). I'd be willing to provide an infra server for testing/development. I don't see much problem at least trying to work out all the details. I don't think infra will go with any change unless there is a clear, detailed migration plan with proper back-out plans also. The tree is the most important part of our distribution and I'm not going to let such a migration go by without proper planning and testing. After the test implementation is done and has been fully tested, perhaps the council could make the final decision if infra is happy with the implementation/migration details. It looks like if/when implemented, GLEP 44 (Manifest2) will significantly reduce the number of small files in the tree. Whoever ends up doing the initial benchmarking and testing should probably keep this in mind. -- Renat Lumpau all things web-apps C6A838DA 04AF B5EE 17CB 1000 DDA5 D3FC 1338 ADC2 C6A8 38DA America - land of the free* *Void where prohibited, restrictions apply. Cash value 1/100c. pgpEJg1nREPxX.pgp Description: PGP signature
Re: [gentoo-dev] Gentoo: State of the Union
On Sat, Apr 29, 2006 at 05:00:10PM -0700, Donnie Berkholz wrote: Alexandre Buisse wrote: The opensolaris project has done a similar thing[1]. The three finalists were bazaar[2], mercurial[3] and git[4], and the winner was eventually mercurial. This is also the recommended choice from the EuroBSDcon slides, so definitely something to consider. Indeed, although EuroBSDcon didn't even analyze git, just mentioned it in passing. It also seems that we have a fair lack of expertise relating to it, but there has been no shortage of contributions about subversion and git, at least. I think we have a pretty good bit of expertise with using git here :) I use it from everything from storing config files, my mbox archive, papers and articles, and yes, Linux kernel development. And I've been playing around with the tools that Keith Packard used to convert the X project, as well as having the advantage of talking at length with him all about the issues that they had in converting over. git is the most under-sold tool out there today. It is by far, the most powerful and flexible source code control tool ever made, and I've used just about every one out there before. It's not something that I say lightly. That being said, is it right for us? Who knows, as no one has really said what they want to do with a different SCM. The problem I had with the opensolaris testing is that they didn't seem to do any direct comparisons between the SCMs -- they were all isolated and based on a requirements doc. This makes it difficult to easily figure out how they balance out. I agree, but who really cares about opensolaris anyway :) thanks, greg k-h -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Gentoo: State of the Union + suggestion for global dev conference (at bottom, if you want to skip)
Stuart Herbert wrote: I'm offering to lead the effort to establish a global Gentoo developer conference, and to do whatever it takes to get everything we need to make this happen. Now who's up for this? :) Best regards, Stu That sounds like a great idea. -Ryan -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] Gentoo: State of the Union
This is a follow up to Mark's (halcy0n's) thread regarding QA Policies and seemant's letter on herds, teams, and projects. I believe the way Gentoo is doing things is broken. There I have said it. The entire project has reached a level of being too political and trying to solve certain problems in the wrong way. Some of these problems are intermixed. Please consider them starting points for discussion. __Problem: Developer Growth__ I find that developer growth as being a problem. Adding a developer to gentoo should be as easy as 1. has the user contributed numerous (~5+) patches that helps the project move forward. If yes, then commit access should be given. Adding a developer is usually quite a chore. There are numerous reasons why this is a problem: having a live tree, taking a test, and not defining within policy when a person could possibly get commit access. All these reasons leave the project stagnant and lacking developers. Why do people have to take a test? Is it to make sure they won't break the tree? If it is, then the solution of a test is wrong. We do want to make sure our developers understand gentoo, but I argue that the bugtracker is all we need. As long as a person is adding value to gentoo and they have proven themselves, then they *should* have commit access. Perhaps its because of a live tree... __Problem: Live Tree__ Having a live tree requires people to be perfect. People are not perfect and requiring it is ridiculous. I love having commits in my local tree within the hour, but having a stable and unstable branch makes a lot of sense. CVS doesn't do branching nor tags very well... __Problem: CVS__ CVS is one of the worst application ever created. The portage tree needs to move to subversion. A lot of the problems within the project would be solved by using a better SCM system. The previous problems regarding the Live Tree and Developer Growth would be solved, IMHO, by just switching. Branches Work. Tags Work. Reverts work. Moves work. I don't see any reason not to use it. It just plain works. Projects (gentoo/bsd, embedded, hardened) could choose to keep their own branches of the portage tree and merge with trunk as needed. Projects could stick to traditional solutions like profiles if they so wished. Some will probably ask who will merge between branches. We can do that easily ourselves. If I think a package is good to go, then svn merge -r1123:1124 to the branch. Huge projects like Apache, GCC, and KDE already use SVN. __Problem: QA Policies__ http://article.gmane.org/gmane.linux.gentoo.devel/37544 It seems that the QA Policies are a product of a Live Tree, and going partially non-live would solve the problems listed. Everyone here is on the same team. There will be some breakages in the tree and those can be dealt with. Like Seemant [1] said, herds are just groups of like *packages*. The QA Policy is wrong when it says cross-team assistance; we are all on the *same* team. The tree should naturally work. If it doesn't then that is a bug for all of us. Conflict resolution should not be a subproject. It should *not* exist at all. Rules need to be in place to avoid conflict. Having some sort of voting structure for all the developers (this doesn't mean requiring everyone to vote) and not just the council or devrel makes a lot of sense for most things. If I don't like how someone is acting within the project there should be a vote and then see if that person is kicked out. No trial, no anything besides a vote. And if I lose I have to deal with it. Either stay with the project, or find something else. This solution just works. Gentoo should be a fun environment. The previous paragraph should be taken as a last resort. __Problem: GLEPs__ I dislike GLEPs. Usually they sit on the website for a long long time not doing anything. My vote (+1) is get rid of gleps and do everything by email and a vote by the developers. AFAIK, the board votes on the GLEPs. Bad Idea. It stifles things from getting done, and there is no ownership of who is going to implement the idea. A new idea proposal should be mailed to a mailinglist (-innovation?) with details of timeline to completion, impact, and who is doing the implementation. If it sounds like a good one, then there is a vote and things proceed. I like progress. __Problem: Voting__ Gentoo has over 200 developers. People are generally against the voting idea, but I'm not sure why. I think voting should work like this: if 30 developers (or someother specified number) vote yes to an idea then that idea passes. It doesn't require everyone to vote, be at home, be on the computer, and not be on vacation. The Apache Foundation already has a decent page regarding this: http://www.apache.org/foundation/voting.html The Apache Foundation has over 1300 developers; they must be doing something right. If someone misses a vote, too bad. You weren't there and progress has been made. I
Re: [gentoo-dev] Gentoo: State of the Union
Ryan Phillips wrote: This is a follow up to Mark's (halcy0n's) thread regarding QA Policies and seemant's letter on herds, teams, and projects. I believe the way Gentoo is doing things is broken. There I have said it. The entire project has reached a level of being too political and trying to solve certain problems in the wrong way. Some of these problems are intermixed. Please consider them starting points for discussion. __Problem: Developer Growth__ I find that developer growth as being a problem. Adding a developer to gentoo should be as easy as 1. has the user contributed numerous (~5+) patches that helps the project move forward. If yes, then commit access should be given. Adding a developer is usually quite a chore. There are numerous reasons why this is a problem: having a live tree, taking a test, and not defining within policy when a person could possibly get commit access. All these reasons leave the project stagnant and lacking developers. Why do people have to take a test? Is it to make sure they won't break the tree? If it is, then the solution of a test is wrong. We do want to make sure our developers understand gentoo, but I argue that the bugtracker is all we need. As long as a person is adding value to gentoo and they have proven themselves, then they *should* have commit access. Perhaps its because of a live tree... I am relatively new, I lurked for quite some time on IRC ( a yearish ) before finally becoming a dev, and the quiz was not particularly difficult, and the questions I didn't know, I asked my Mentor about. I think Mentors in general don't do a very good job ( not complaining about mine, mind, just in general ). I think in some cases, people are afraid to ask questions. We have the madly successful AT project, and a new Herd Tester project is in the works. I find both of these to be very good ideas and have aided in developer growth. As for your suggestion, with a Live Tree you cannot give random users who contribute 5 patches commit access. Commiting comes with it an inherit responsibility. The following is an example only: I can go in right now and commit something that destroys anyone's box not running SElinux, just bump portage and then watch anyone that uses the new version destroy their machine. Part of this involves having a reputation based system. IMHO this is part of our own tree security. I have worked hard in the community to become a developer, and throwing that all away to ruin some boxes is silly. Sure once my changes are found they can be revert and a new portage thrown into the tree, but how many boxes were ruined first? What if my commit was unintentional? __Problem: Live Tree__ Having a live tree requires people to be perfect. People are not perfect and requiring it is ridiculous. I love having commits in my local tree within the hour, but having a stable and unstable branch makes a lot of sense. CVS doesn't do branching nor tags very well... More details on how Branches and Tags solve the Live Tree problem would be good. __Problem: CVS__ CVS is one of the worst application ever created. The portage tree needs to move to subversion. A lot of the problems within the project would be solved by using a better SCM system. The previous problems regarding the Live Tree and Developer Growth would be solved, IMHO, by just switching. Branches Work. Tags Work. Reverts work. Moves work. I don't see any reason not to use it. It just plain works. Projects (gentoo/bsd, embedded, hardened) could choose to keep their own branches of the portage tree and merge with trunk as needed. Projects could stick to traditional solutions like profiles if they so wished. Some will probably ask who will merge between branches. We can do that easily ourselves. If I think a package is good to go, then svn merge -r1123:1124 to the branch. Huge projects like Apache, GCC, and KDE already use SVN. We have people looking into this. Once more testing is done it will probably be proposed in an official capacity, for now I think a test svn with the whole tree plus tools porting from cvs to svn is the priority. __Problem: QA Policies__ http://article.gmane.org/gmane.linux.gentoo.devel/37544 It seems that the QA Policies are a product of a Live Tree, and going partially non-live would solve the problems listed. Everyone here is on the same team. There will be some breakages in the tree and those can be dealt with. Like Seemant [1] said, herds are just groups of like *packages*. The QA Policy is wrong when it says cross-team assistance; we are all on the *same* team. The tree should naturally work. If it doesn't then that is a bug for all of us. Conflict resolution should not be a subproject. It should *not* exist at all. Rules need to be in place to avoid conflict. Having some sort of voting structure for all the developers (this doesn't mean
Re: [gentoo-dev] Gentoo: State of the Union
On Fri, Apr 28, 2006 at 10:14:53AM -0700, Ryan Phillips wrote: I find that developer growth as being a problem. Adding a developer to gentoo should be as easy as 1. has the user contributed numerous (~5+) patches that helps the project move forward. If yes, then commit access should be given. Adding a developer is usually quite a chore. There are numerous reasons why this is a problem: having a live tree, taking a test, and not defining within policy when a person could possibly get commit access. All these reasons leave the project stagnant and lacking developers. Maybe certain projects are (and maybe there are a lot of undermaintained packages) but overall I would say we are not really lacking developers; what areas would you say we're lacking devs in exactly? The recruitment process should be tightened further to ensure we have a solid, educated dev base. This isn't about shutting people out, it's about ensuring that anyone with commit access is well-versed in how we do things. Why do people have to take a test? Is it to make sure they won't break the tree? If it is, then the solution of a test is wrong. We do want to make sure our developers understand gentoo, but I argue that the bugtracker is all we need. As long as a person is adding value to gentoo and they have proven themselves, then they *should* have commit access. Many people with useful contributions can commit garbage due to not quite knowing what they're doing. The quiz process is an attempt to address that. We used to recruit the way you suggest and it worked for years; we've since outgrown that. Testing recruits provides further education. Admittedly the quiz as it stands is archaic and needs reworking. I believe the recruiters team is working on addressing that. Everyone here is on the same team. There will be some breakages in the tree and those can be dealt with. Like Seemant [1] said, herds are just groups of like *packages*. The QA Policy is wrong when it says cross-team assistance; we are all on the *same* team. The tree should naturally work. If it doesn't then that is a bug for all of us. OK, well, realistically we are composed of projects working on various areas of Gentoo that must work together with one another to form a whole. Gentoo is not and should not be one big amorphous blob. Conflict resolution should not be a subproject. It should *not* exist at all. Rules need to be in place to avoid conflict. Having some sort of voting structure for all the developers (this doesn't mean requiring everyone to vote) and not just the council or devrel makes a lot of sense for most things. If I don't like how someone is acting within the project there should be a vote and then see if that person is kicked out. No trial, no anything besides a vote. And if I lose I have to deal with it. Either stay with the project, or find something else. This solution just works. Why should conflict resolution be a popularity contest? Gentoo should be a fun environment. The previous paragraph should be taken as a last resort. __Problem: GLEPs__ I dislike GLEPs. Usually they sit on the website for a long long time not doing anything. My vote (+1) is get rid of gleps and do everything by email and a vote by the developers. AFAIK, the board votes on the GLEPs. Bad Idea. It stifles things from getting done, and there is no ownership of who is going to implement the idea. A new idea proposal should be mailed to a mailinglist (-innovation?) with details of timeline to completion, impact, and who is doing the implementation. If it sounds like a good one, then there is a vote and things proceed. I like progress. Well, I think we all like progress. The council votes on GLEPs; I don't see how extending voting to include _all of Gentoo_ would speed things up or contribute to progress... this is why we elect representatives. Overall I think this would be a regression. -- Jon Portnoy avenj/irc.freenode.net -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Gentoo: State of the Union
Jon Portnoy [EMAIL PROTECTED] said: On Fri, Apr 28, 2006 at 10:14:53AM -0700, Ryan Phillips wrote: I find that developer growth as being a problem. Adding a developer to gentoo should be as easy as 1. has the user contributed numerous (~5+) patches that helps the project move forward. If yes, then commit access should be given. Adding a developer is usually quite a chore. There are numerous reasons why this is a problem: having a live tree, taking a test, and not defining within policy when a person could possibly get commit access. All these reasons leave the project stagnant and lacking developers. Maybe certain projects are (and maybe there are a lot of undermaintained packages) but overall I would say we are not really lacking developers; what areas would you say we're lacking devs in exactly? The recruitment process should be tightened further to ensure we have a solid, educated dev base. This isn't about shutting people out, it's about ensuring that anyone with commit access is well-versed in how we do things. I believe we have a problem enticing new devlopers to join. It shouldn't be difficult in learning how to commit changes to a tree. What is well versed? Understanding the ways on how to break the tree? If that is the case, then we are doing something wrong. Why do people have to take a test? Is it to make sure they won't break the tree? If it is, then the solution of a test is wrong. We do want to make sure our developers understand gentoo, but I argue that the bugtracker is all we need. As long as a person is adding value to gentoo and they have proven themselves, then they *should* have commit access. Many people with useful contributions can commit garbage due to not quite knowing what they're doing. The quiz process is an attempt to address that. We used to recruit the way you suggest and it worked for years; we've since outgrown that. Testing recruits provides further education. Admittedly the quiz as it stands is archaic and needs reworking. I believe the recruiters team is working on addressing that. I am arguing that we don't need testing of potential developers. It is bad for the community. It is saying that we don't have any faith with our recruiting process. If we only only worried about tree breakage, then this is the wrong solution. Everyone here is on the same team. There will be some breakages in the tree and those can be dealt with. Like Seemant [1] said, herds are just groups of like *packages*. The QA Policy is wrong when it says cross-team assistance; we are all on the *same* team. The tree should naturally work. If it doesn't then that is a bug for all of us. OK, well, realistically we are composed of projects working on various areas of Gentoo that must work together with one another to form a whole. Gentoo is not and should not be one big amorphous blob. I agree. The mentality should be one project, even if the herds are split into more project. I do not like when people say that someone has stepped on their toes when committing a change to another herd.. Typically people are trying to help. If there is a breakage then it is a problem for Gentoo, not just a herd. Having a live tree just adds to this problem. Conflict resolution should not be a subproject. It should *not* exist at all. Rules need to be in place to avoid conflict. Having some sort of voting structure for all the developers (this doesn't mean requiring everyone to vote) and not just the council or devrel makes a lot of sense for most things. If I don't like how someone is acting within the project there should be a vote and then see if that person is kicked out. No trial, no anything besides a vote. And if I lose I have to deal with it. Either stay with the project, or find something else. This solution just works. Why should conflict resolution be a popularity contest? It isn't. It is how a job works. If someone isn't getting along with the team, they are fired. Same principle. Gentoo should be a fun environment. The previous paragraph should be taken as a last resort. __Problem: GLEPs__ I dislike GLEPs. Usually they sit on the website for a long long time not doing anything. My vote (+1) is get rid of gleps and do everything by email and a vote by the developers. AFAIK, the board votes on the GLEPs. Bad Idea. It stifles things from getting done, and there is no ownership of who is going to implement the idea. A new idea proposal should be mailed to a mailinglist (-innovation?) with details of timeline to completion, impact, and who is doing the implementation. If it sounds like a good one, then there is a vote and things proceed. I like progress. Well, I think we all like progress. The council votes on GLEPs; I don't see how extending voting to include _all of Gentoo_
Re: [gentoo-dev] Gentoo: State of the Union
On Friday 28 April 2006 11:22 am, Ryan Phillips wrote: I believe we have a problem enticing new devlopers to join. It shouldn't be difficult in learning how to commit changes to a tree. There's much more involved than more people think, if you'd like I can send you an entire long list of what's supposed to happen. What is well versed? Understanding the ways on how to break the tree? If that is the case, then we are doing something wrong. Well versed is knowing there's more to the process than just commiting. There's working with upstream, adding patches, continual maintaining, etc. I am arguing that we don't need testing of potential developers. It is bad for the community. It is saying that we don't have any faith with our recruiting process. If we only only worried about tree breakage, then this is the wrong solution. Sure, then you get this: Hey can I join? OK *adds user* -- 2 weeks later -- Anyone heard from user? No And heaven forbid they actually took on package maintaining before they left. -- Chris White Gentoo Developer aka: ChrisWhite cpw ChrisWhite|Work WhiteChocolate VanillaWhite Whitey WhiteLight WhiteCheese WhiteSugar WhiteButter WhiteWall WhiteLemon WhiteApple WhiteBlanket WhiteEnergy WhiteWhite pgpbeCyYZYYeh.pgp Description: PGP signature
Re: [gentoo-dev] Gentoo: State of the Union
Alec Warner [EMAIL PROTECTED] said: Ryan Phillips wrote: This is a follow up to Mark's (halcy0n's) thread regarding QA Policies and seemant's letter on herds, teams, and projects. I believe the way Gentoo is doing things is broken. There I have said it. The entire project has reached a level of being too political and trying to solve certain problems in the wrong way. Some of these problems are intermixed. Please consider them starting points for discussion. __Problem: Developer Growth__ I find that developer growth as being a problem. Adding a developer to gentoo should be as easy as 1. has the user contributed numerous (~5+) patches that helps the project move forward. If yes, then commit access should be given. Adding a developer is usually quite a chore. There are numerous reasons why this is a problem: having a live tree, taking a test, and not defining within policy when a person could possibly get commit access. All these reasons leave the project stagnant and lacking developers. Why do people have to take a test? Is it to make sure they won't break the tree? If it is, then the solution of a test is wrong. We do want to make sure our developers understand gentoo, but I argue that the bugtracker is all we need. As long as a person is adding value to gentoo and they have proven themselves, then they *should* have commit access. Perhaps its because of a live tree... I am relatively new, I lurked for quite some time on IRC ( a yearish ) before finally becoming a dev, and the quiz was not particularly difficult, and the questions I didn't know, I asked my Mentor about. I think Mentors in general don't do a very good job ( not complaining about mine, mind, just in general ). I think in some cases, people are afraid to ask questions. We have the madly successful AT project, and a new Herd Tester project is in the works. I find both of these to be very good ideas and have aided in developer growth. As for your suggestion, with a Live Tree you cannot give random users who contribute 5 patches commit access. Commiting comes with it an inherit responsibility. The following is an example only: Ok, so maybe not 5 patches commit access.. How about an active contributor for 6 months. I am throwing out ideas. I can go in right now and commit something that destroys anyone's box not running SElinux, just bump portage and then watch anyone that uses the new version destroy their machine. Part of this involves having a reputation based system. IMHO this is part of our own tree security. I have worked hard in the community to become a developer, and throwing that all away to ruin some boxes is silly. Sure once my changes are found they can be revert and a new portage thrown into the tree, but how many boxes were ruined first? What if my commit was unintentional? So this is a problem with having a live tree. __Problem: Live Tree__ Having a live tree requires people to be perfect. People are not perfect and requiring it is ridiculous. I love having commits in my local tree within the hour, but having a stable and unstable branch makes a lot of sense. CVS doesn't do branching nor tags very well... More details on how Branches and Tags solve the Live Tree problem would be good. We could have a trunk/ and stable/ branch. The stable branch gets exported to the rsync mirrors. Trunk/ is where we do the changes, then merge to stable/ the changes we want. Should be pretty simple. __Problem: QA Policies__ http://article.gmane.org/gmane.linux.gentoo.devel/37544 It seems that the QA Policies are a product of a Live Tree, and going partially non-live would solve the problems listed. Everyone here is on the same team. There will be some breakages in the tree and those can be dealt with. Like Seemant [1] said, herds are just groups of like *packages*. The QA Policy is wrong when it says cross-team assistance; we are all on the *same* team. The tree should naturally work. If it doesn't then that is a bug for all of us. Conflict resolution should not be a subproject. It should *not* exist at all. Rules need to be in place to avoid conflict. Having some sort of voting structure for all the developers (this doesn't mean requiring everyone to vote) and not just the council or devrel makes a lot of sense for most things. If I don't like how someone is acting within the project there should be a vote and then see if that person is kicked out. No trial, no anything besides a vote. And if I lose I have to deal with it. Either stay with the project, or find something else. This solution just works. How many people are going to actively vote? What keeps Me n' my Posse' from just voting out random people we hate; assuming my Posse' is large enough to do so? Thats fine. I replied to
Re: [gentoo-dev] Gentoo: State of the Union
Ryan Phillips wrote: The council should not vote on gleps are provide policy. They should be there to handle the money and world-wide problems. The developers should drive innovation; not the council. As in all democracies things get done slowly. We don't need a democracy within Gentoo, just a clear way of creating progress. Just because we have some elections in our process don't make Gentoo a democracy. Since we don't have a leader to make the important decisions, we need some other form of authority to do the job. A council is the best solution to the decisional problem. Obviously it has nothing to do with innovation. As always, this is the realm of developers. In the rest, I basically agree with avenj. No point in repeating what Jon already said... signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Gentoo: State of the Union
Chris White [EMAIL PROTECTED] said: Sure, then you get this: Hey can I join? OK *adds user* -- 2 weeks later -- Anyone heard from user? No The solution is to have them been an active contributor for say 6 months. -ryan pgpR35ZcUmZet.pgp Description: PGP signature
Re: [gentoo-dev] Gentoo: State of the Union
Ryan Phillips wrote: [Fri Apr 28 2006, 12:14:53PM CDT] __Problem: Developer Growth__ I've seen suggestions before that one of the things limiting Gentoo's growth right now is the hurdles involved in becoming a dev. I don't really think the dev quiz is all that onerous, but I'm willing to listen to arguments there. __Problem: Live Tree__ Having a live tree requires people to be perfect. People are not perfect and requiring it is ridiculous. I love having commits in my local tree within the hour, but having a stable and unstable branch makes a lot of sense. Does it? How does having a stable and unstable branch differ from having stable and unstable keywords? On older idea was peer review. Any dev could commit to the not-yet-ready-for-primetime branch, but those commits would have to be peer-reviewed before being added to the user tree. It's a great idea, except (a) nobody wants to do the reviewing job and (b) it would be a full time job. CVS doesn't do branching nor tags very well... __Problem: CVS__ CVS is one of the worst application ever created. The portage tree needs to move to subversion. A lot of the problems within the project would be solved by using a better SCM system. The previous problems regarding the Live Tree and Developer Growth would be solved, IMHO, by just switching. Branches Work. Tags Work. Reverts work. Moves work. I don't see any reason not to use it. It just plain works. Have you tried using SVN for the portage tree? I don't know if anybody has recently, but in the past when people tried there were two significant problems: SVN requires at least 2x the tree size for storage on the local machine, and checkouts take something akin to an order of magnitude longer than CVS. The former is annoying, but liveable, but the latter is a deal-breaker. __Problem: QA Policies__ http://article.gmane.org/gmane.linux.gentoo.devel/37544 It seems that the QA Policies are a product of a Live Tree, and going partially non-live would solve the problems listed. QA does help with fixing broken packages, but in my view their most important mandate is to help devs fix bad habits in writing ebuilds. Repoman and lists of best-practices help in this regard, but the QA team tends to be much better at explaining why something is a bad idea. Conflict resolution should not be a subproject. It should *not* exist at all. Rules need to be in place to avoid conflict. Having some sort of voting structure for all the developers (this doesn't mean requiring everyone to vote) and not just the council or devrel makes a lot of sense for most things. If I don't like how someone is acting within the project there should be a vote and then see if that person is kicked out. No trial, no anything besides a vote. And if I lose I have to deal with it. Either stay with the project, or find something else. This solution just works. It's worth noting that with the exception of kicking people out of Gentoo, much of our practices do, in fact, work just this way, although without the formality of a vote. That's what happens when somebody posts to -dev with an idea, it gets kicked around, and some sort of consensus is either reached, or it isn't. In the latter case it's not ready for prime time, most likely. __Problem: GLEPs__ I dislike GLEPs. Usually they sit on the website for a long long time not doing anything. My vote (+1) is get rid of gleps and do everything by email and a vote by the developers. AFAIK, the board votes on the GLEPs. Bad Idea. It stifles things from getting done, and there is no ownership of who is going to implement the idea. A new idea proposal should be mailed to a mailinglist (-innovation?) with details of timeline to completion, impact, and who is doing the implementation. If it sounds like a good one, then there is a vote and things proceed. I like progress. It's not quite true that the Council votes on GLEPs, but that's not really germane to your overall point. Despite being the person who created GLEPs in the first place, I'm quite willing to admit that the concept doesn't seem to work as well as I had hoped. I'm not sure that your idea would work better, however, since the only real difference would be in the approval process. Presumably you would still expect to see the sort of iterative refinement of proposals/innovations on -dev that we have now, and I believe that part of the project works reasonably well. The problem, in my view, is that eventually the proposal is approved, and the folks involved are told, in essence, great idea, go to it, and then it stalls because implementation is _hard_, in general. As an aside, the large number of moribund GLEPs was always an intended outcome. They represent ideas that never got any traction, and thus went nowhere. By having them publicly available we help reduce the number of hey, what about this bad idea posts to -dev. __Problem: Voting__ Gentoo
Re: [gentoo-dev] Gentoo: State of the Union
Alin Nastac [EMAIL PROTECTED] said: Ryan Phillips wrote: The council should not vote on gleps are provide policy. They should be there to handle the money and world-wide problems. The developers should drive innovation; not the council. As in all democracies things get done slowly. We don't need a democracy within Gentoo, just a clear way of creating progress. Just because we have some elections in our process don't make Gentoo a democracy. Since we don't have a leader to make the important decisions, we need some other form of authority to do the job. A council is the best solution to the decisional problem. Obviously it has nothing to do with innovation. As always, this is the realm of developers. In the rest, I basically agree with avenj. No point in repeating what Jon already said... I disagree. The developers should make *all* the decisions. Bypass the council. The council should be there only for when we get sued, and manage the money we make. Does anyone agree that having a council is too political? I strongly believe it stifles gentoo. -Ryan pgplEy9kSx55S.pgp Description: PGP signature
Re: [gentoo-dev] Gentoo: State of the Union
On Friday 28 April 2006 11:50 am, Ryan Phillips wrote: The solution is to have them been an active contributor for say 6 months. Ok, but most active contributors are people that submit ebuilds to devs and know nothing about the structure/policy/whatever about ebuilds. If you're not a dev, you're probably not going to worry about revision bumps. If you're a dev without alternate arches, you're probably not going to know about how other arches can get screwed by improper pic handling. To conclude, active contributors are generally in a focused environment. The quiz is there to help show them the global way of handling things. -ryan -- Chris White Gentoo Developer aka: ChrisWhite cpw ChrisWhite|Work WhiteChocolate VanillaWhite Whitey WhiteLight WhiteCheese WhiteSugar WhiteButter WhiteWall WhiteLemon WhiteApple WhiteBlanket WhiteEnergy WhiteWhite pgpsEo0jFFxVO.pgp Description: PGP signature
Re: [gentoo-dev] Gentoo: State of the Union
Grant Goodyear wrote: [Fri Apr 28 2006, 01:55:01PM CDT] It's not quite true that the Council votes on GLEPs, but that's not really germane to your overall point. Oh, that was your point. Mea culpa. Okay, to address that point, the way that the current system works is that a GLEP is sent to the GLEP editors, and assuming that it is not obviously going to be DOA it's generally added to the website. At that point, if they haven't already, the GLEP authors initiate a discussion on -dev that is supposed to be iterative. The authors are supposed to revise their proposal to account for comments and ideas from the community. When the authors feel it is ready, they ask for the GLEP to be approved. At that point the GLEP is sent to either a project lead (if it falls under a specific project) or the Council if it crosses project boundaries for approval. I assume that the only part of the process you would really wish to change is who does the approving, and perhaps removing the initial send-it-to-the-editors step. In reality, though, the approval process is rarely the rate-limiting step. In almost all cases, a stalled or failed GLEP either never gets sent for approval, or is approved but never gets implemented. -g2boojum- -- Grant Goodyear Gentoo Developer [EMAIL PROTECTED] http://www.gentoo.org/~g2boojum GPG Fingerprint: D706 9802 1663 DEF5 81B0 9573 A6DC 7152 E0F6 5B76 pgpDLnBJpwh7K.pgp Description: PGP signature
Re: [gentoo-dev] Gentoo: State of the Union
Ryan Phillips wrote: Does anyone agree that having a council is too political? I strongly believe it stifles gentoo. I believe a non-representative democracy is stifling, and buries everybody in constant votes etc. Donnie -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Gentoo: State of the Union
On Fri, Apr 28, 2006 at 11:57:30AM -0700, Ryan Phillips wrote: Bypass the council. The council should be there only for when we get sued, and manage the money we make. Does anyone agree that having a council is too political? I strongly believe it stifles gentoo. You're confusing Council Foundation... Foundation handles moolah and the we get our asses sued scenario, not the Council. The Council helps push Gentoo forward. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Gentoo: State of the Union
Ryan Phillips wrote: [Fri Apr 28 2006, 01:57:30PM CDT] I disagree. The developers should make *all* the decisions. Originally, Gentoo was effectively a meritocracy. It's now, in some respects, a republic. If you want a democracy, feel free to draft a new metastructure proposal (feel free to name it something less awkward), and drum up support to get it voted upon. Bypass the council. The council should be there only for when we get sued, and manage the money we make. For what it's worth, the Council does neither of those things. That's what the Gentoo Foundation is for. Does anyone agree that having a council is too political? I strongly believe it stifles gentoo. Do you have some specific examples of how you've seen the Council stifle Gentoo, or is it mainly just a general impression? -g2boojum- -- Grant Goodyear Gentoo Developer [EMAIL PROTECTED] http://www.gentoo.org/~g2boojum GPG Fingerprint: D706 9802 1663 DEF5 81B0 9573 A6DC 7152 E0F6 5B76 pgpjHkscJlgrf.pgp Description: PGP signature
Re: [gentoo-dev] Gentoo: State of the Union
On Fri, Apr 28, 2006 at 01:55:01PM -0500, Grant Goodyear wrote: CVS doesn't do branching nor tags very well... __Problem: CVS__ CVS is one of the worst application ever created. The portage tree needs to move to subversion. A lot of the problems within the project would be solved by using a better SCM system. The previous problems regarding the Live Tree and Developer Growth would be solved, IMHO, by just switching. Branches Work. Tags Work. Reverts work. Moves work. I don't see any reason not to use it. It just plain works. Have you tried using SVN for the portage tree? I don't know if anybody has recently, but in the past when people tried there were two significant problems: SVN requires at least 2x the tree size for storage on the local machine, and checkouts take something akin to an order of magnitude longer than CVS. The former is annoying, but liveable, but the latter is a deal-breaker. Speaking of which, has anybody done any tests with svk? (http://svk.elixus.org) And: http://svk.elixus.org/?WhySVK -- it would be interesting to compare checkout performance on it as well. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Gentoo: State of the Union
On Fri, 28 Apr 2006 12:03:29 -0700 Chris White [EMAIL PROTECTED] wrote: Ok, but most active contributors are people that submit ebuilds to devs and know nothing about the structure/policy/whatever about ebuilds. If you're not a dev, you're probably not going to worry about revision bumps. If you're a dev without alternate arches, you're probably not going to know about how other arches can get screwed by improper pic handling. To conclude, active contributors are generally in a focused environment. The quiz is there to help show them the global way of handling things. That problem can be solved by giving new developers access to a 'sandbox' branch of the tree, and have a more experienced dev merge their changes into the live tree having checked them for sanity. Once they've proved themselves there, they can be given access to the main tree if appropriate. Of course, this relies upon using a VCS for the tree that handles branches and merging sanely, which should be doable with Subversion if the issues it had last time this was tested have been or can be resolved. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Gentoo: State of the Union
Tim Yamin wrote: On Fri, Apr 28, 2006 at 01:55:01PM -0500, Grant Goodyear wrote: CVS doesn't do branching nor tags very well... __Problem: CVS__ CVS is one of the worst application ever created. The portage tree needs to move to subversion. A lot of the problems within the project would be solved by using a better SCM system. The previous problems regarding the Live Tree and Developer Growth would be solved, IMHO, by just switching. Branches Work. Tags Work. Reverts work. Moves work. I don't see any reason not to use it. It just plain works. Have you tried using SVN for the portage tree? I don't know if anybody has recently, but in the past when people tried there were two significant problems: SVN requires at least 2x the tree size for storage on the local machine, and checkouts take something akin to an order of magnitude longer than CVS. The former is annoying, but liveable, but the latter is a deal-breaker. Speaking of which, has anybody done any tests with svk? (http://svk.elixus.org) And: http://svk.elixus.org/?WhySVK -- it would be interesting to compare checkout performance on it as well. Since it is derived from svn, I think it would be x times slower than svn. Besides, why would we need a decentralized SCM? signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Gentoo: State of the Union
On Fri, Apr 28, 2006 at 11:22:05AM -0700, Ryan Phillips wrote: Jon Portnoy [EMAIL PROTECTED] said: On Fri, Apr 28, 2006 at 10:14:53AM -0700, Ryan Phillips wrote: I find that developer growth as being a problem. Adding a developer to gentoo should be as easy as 1. has the user contributed numerous (~5+) patches that helps the project move forward. If yes, then commit access should be given. Adding a developer is usually quite a chore. There are numerous reasons why this is a problem: having a live tree, taking a test, and not defining within policy when a person could possibly get commit access. All these reasons leave the project stagnant and lacking developers. Maybe certain projects are (and maybe there are a lot of undermaintained packages) but overall I would say we are not really lacking developers; what areas would you say we're lacking devs in exactly? The recruitment process should be tightened further to ensure we have a solid, educated dev base. This isn't about shutting people out, it's about ensuring that anyone with commit access is well-versed in how we do things. I believe we have a problem enticing new devlopers to join. It shouldn't be difficult in learning how to commit changes to a tree. What is well versed? Understanding the ways on how to break the tree? If that is the case, then we are doing something wrong. I come from a different background being a recruiter and having done most, if not all, the work to clean up the current developer base so far. And from what I'm seeing we have to make it *harder* to become a gentoo developer if we want to keep any quality at all. It's not that we don't get lots of new developers but looking back at all the developers I've been retiring due to inactivity it's fairly clear that a huge part of them never did more than 5 commits or so.. And it takes a good deal more than 5 commits before you know all the intricacies of portage/gentoo and are able to do quality work on a consistent basis. I've mentored quite a few developers myself and I believe I did a fairly good job as a mentor but there's still quite some difference between first few commits and later commits from those devs as they gain experience. Personally, I don't want Gentoo to be characterised by revolving door developers and I'd expect users would be fairly unhappy with that as well. Why do people have to take a test? Is it to make sure they won't break the tree? If it is, then the solution of a test is wrong. We do want to make sure our developers understand gentoo, but I argue that the bugtracker is all we need. As long as a person is adding value to gentoo and they have proven themselves, then they *should* have commit access. Many people with useful contributions can commit garbage due to not quite knowing what they're doing. The quiz process is an attempt to address that. We used to recruit the way you suggest and it worked for years; we've since outgrown that. Testing recruits provides further education. Admittedly the quiz as it stands is archaic and needs reworking. I believe the recruiters team is working on addressing that. I am arguing that we don't need testing of potential developers. It is bad for the community. It is saying that we don't have any faith with our recruiting process. If we only only worried about tree breakage, then this is the wrong solution. The Arch Tester / Herd Tester projects solves many of the current problems but I very much believe we need something akin to the current tests. We *will* try to improve those tests but I'm going to fight making it easier to become a developer hard as that's a very bad direction from my point of view. Everyone here is on the same team. There will be some breakages in the tree and those can be dealt with. Like Seemant [1] said, herds are just groups of like *packages*. The QA Policy is wrong when it says cross-team assistance; we are all on the *same* team. The tree should naturally work. If it doesn't then that is a bug for all of us. OK, well, realistically we are composed of projects working on various areas of Gentoo that must work together with one another to form a whole. Gentoo is not and should not be one big amorphous blob. I agree. The mentality should be one project, even if the herds are split into more project. I do not like when people say that someone has stepped on their toes when committing a change to another herd.. Typically people are trying to help. If there is a breakage then it is a problem for Gentoo, not just a herd. Having a live tree just adds to this problem. Conflict resolution should not be a subproject. It should *not* exist at all. Rules need to be in place to avoid conflict. Having some sort of voting structure for all the developers
Re: [gentoo-dev] Gentoo: State of the Union
On Fri, Apr 28, 2006 at 08:35:40PM +0100, Stephen Bennett wrote: On Fri, 28 Apr 2006 12:03:29 -0700 Chris White [EMAIL PROTECTED] wrote: Ok, but most active contributors are people that submit ebuilds to devs and know nothing about the structure/policy/whatever about ebuilds. If you're not a dev, you're probably not going to worry about revision bumps. If you're a dev without alternate arches, you're probably not going to know about how other arches can get screwed by improper pic handling. To conclude, active contributors are generally in a focused environment. The quiz is there to help show them the global way of handling things. That problem can be solved by giving new developers access to a 'sandbox' branch of the tree, and have a more experienced dev merge their changes into the live tree having checked them for sanity. Once they've proved themselves there, they can be given access to the main tree if appropriate. Of course, this relies upon using a VCS for the tree that handles branches and merging sanely, which should be doable with Subversion if the issues it had last time this was tested have been or can be resolved. -- This solution also needs experienced developers with lots of free time on their hands.. And try as I might, I can't think of many people that fits that description. Regards, Bryan Østergaard -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Gentoo: State of the Union
Ryan Phillips wrote: The council should not vote on gleps are provide policy. They should be there to handle the money and world-wide problems. The developers should drive innovation; not the council. You apparently confuse the trustees and the council. And you apparently did miss the metastructure discussion of last year. Gentoo is made up of projects that do whatever they want inside their projects. That's where quick innovation should happen. The council is elected to take decisions on Gentoo-wide issues that affect multiple projects. GLEPs describe the wanted change, developers discuss on the idea and finally the council decides (usually it validates the consensus if there is one). You don't like them, but they make good references : http://www.gentoo.org/proj/en/glep/glep-0039.html That said, I agree we lack developers. We in fact don't lack devs, we lack active developers. So some cleanup action should be done. -- Koon -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Gentoo: State of the Union
Tim Yamin wrote: Speaking of which, has anybody done any tests with svk? (http://svk.elixus.org) And: http://svk.elixus.org/?WhySVK -- it would be interesting to compare checkout performance on it as well. I've been planning to do a more detailed comparison of all the popular SCM's out there for probably 6 months, but I just don't have the time right now. If someone wants to pick this up, please let us know. Recommended reading: http://www.keltia.net/EuroBSDCon/slides.pdf and www.keltia.net/EuroBSDCon/paper.pdf SCMs to test: monotone bazaar bzr mercurial cogito cvs svn darcs svk Thanks, Donnie -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Gentoo: State of the Union
On Fri, Apr 28, 2006 at 01:42:40PM -0700, Ryan Phillips wrote: cogito - Not practical * the lots of little files doesn't scale well with the size of the portage tree Sure, that's why they invented git repack. * In addition, git only allows checkins from the project parent. A deal breaker in my opinion That's not true at all. Not in any sane Git version. - ferdy -- Fernando J. Pereda Garcimartín Gentoo Developer (Alpha,net-mail,mutt,git) 20BB BDC3 761A 4781 E6ED ED0B 0A48 5B0C 60BD 28D4 pgpuShtf3rkjZ.pgp Description: PGP signature
Re: [gentoo-dev] Gentoo: State of the Union
Donnie Berkholz [EMAIL PROTECTED] said: Ryan Phillips wrote: git - terrible with lots of tiny little files Can you provide some evidence to support this? I posted in more detail on SCMs elsewhere today. Sure. git only allows commits from the project parent. Meaning that if there was a project laid out like: portage-tree/ some-package/ some-package-1.0.0.ebuild xorg/ xorg-1.ebuild If I am in the portage-tree/xorg directory, I would be unable to do a cg-commit. Git only commits from the parent project directory, so I would have to change back to the portage-tree and do a commit on the entire tree. We should not required that from an SCM. Subversion versions each directory. Tha is why one can change into portage-tree/some-package and do svn svn commit. This is different that git, where the entire tree is versioned as one. Make sense? Second issue with git, is that with lots of tiny little files things don't work so well. I tried converting our portage tree into a git tree, and it ran for around 2 days until I finally killed it. If we didn't want to preserve history, then maybe it would work out. But with the problem I outlined above I still don't see it as a contender. There are lots of times when one would want to do a commit in one directory. -ryan pgpMfm2NTwBbL.pgp Description: PGP signature
Re: [gentoo-dev] Gentoo: State of the Union
Fernando J. Pereda [EMAIL PROTECTED] said: On Fri, Apr 28, 2006 at 01:42:40PM -0700, Ryan Phillips wrote: cogito - Not practical * the lots of little files doesn't scale well with the size of the portage tree Sure, that's why they invented git repack. * In addition, git only allows checkins from the project parent. A deal breaker in my opinion That's not true at all. Not in any sane Git version. Ferdy: What I meant is, if you have a change within one directory pending a commit, and you have a commit pending in a current directory, both files will be picked up for the commit. I think that is bad. That means you can't have pending changes not ready for commit and commit something. yes. git-commit will allow the commit, it will walk the directories backwards, but it will find all the pending changes and want to commit them. I don't think that is beneficial. I'm open to comments though. -ryan pgpFFG53shvAt.pgp Description: PGP signature
Re: [gentoo-dev] Gentoo: State of the Union
Ryan: I think you are talking about very old versions of Git: On Fri, Apr 28, 2006 at 02:20:43PM -0700, Ryan Phillips wrote: What I meant is, if you have a change within one directory pending a commit, and you have a commit pending in a current directory, both files will be picked up for the commit. I think that is bad. That means you can't have pending changes not ready for commit and commit something. Of course you can have pending commits. You can even have uncommited changes in your index since git-commit uses a temporary index when doing this kind of checkins. yes. git-commit will allow the commit, it will walk the directories backwards, but it will find all the pending changes and want to commit them. It will if you don't use git-commit correctly :) I don't think that is beneficial. I'm open to comments though. 'git commit' semantics are a bit different from 'cvs commit' and 'svn commit' semantics. That's probably the reason you faced that problem :) Cheers, ferdy -- Fernando J. Pereda Garcimartín Gentoo Developer (Alpha,net-mail,mutt,git) 20BB BDC3 761A 4781 E6ED ED0B 0A48 5B0C 60BD 28D4 pgpZfPqD2Ec9B.pgp Description: PGP signature
Re: [gentoo-dev] Gentoo: State of the Union
On Fri, Apr 28, 2006 at 02:06:36PM -0700, Ryan Phillips wrote: Second issue with git, is that with lots of tiny little files things don't work so well. I tried converting our portage tree into a git tree, and it ran for around 2 days until I finally killed it. If we didn't want to preserve history, then maybe it would work out. But with the problem I outlined above I still don't see it as a contender. There are lots of times when one would want to do a commit in one directory. Ryan, What tool did you use for that? AFAIK parsecvs[1] has converted some very big and broken CVS repositories successfully. - ferdy [1] git://git.freedesktop.org/~keithp/parsecvs -- Fernando J. Pereda Garcimartín Gentoo Developer (Alpha,net-mail,mutt,git) 20BB BDC3 761A 4781 E6ED ED0B 0A48 5B0C 60BD 28D4 pgpEnrmtBVaXl.pgp Description: PGP signature
Re: [gentoo-dev] Gentoo: State of the Union
Fernando J. Pereda [EMAIL PROTECTED] said: Ryan: I think you are talking about very old versions of Git: On Fri, Apr 28, 2006 at 02:20:43PM -0700, Ryan Phillips wrote: What I meant is, if you have a change within one directory pending a commit, and you have a commit pending in a current directory, both files will be picked up for the commit. I think that is bad. That means you can't have pending changes not ready for commit and commit something. Of course you can have pending commits. You can even have uncommited changes in your index since git-commit uses a temporary index when doing this kind of checkins. yes. git-commit will allow the commit, it will walk the directories backwards, but it will find all the pending changes and want to commit them. It will if you don't use git-commit correctly :) I don't think that is beneficial. I'm open to comments though. 'git commit' semantics are a bit different from 'cvs commit' and 'svn commit' semantics. That's probably the reason you faced that problem :) the only option I saw was git-commit -o and you had to specify the files that you wanted to commit. I tried doing a git-commit paths/ and still everything wants to be committed. It isn't pretty. -Ryan pgpYAOsjE8CQ3.pgp Description: PGP signature
Re: [gentoo-dev] Gentoo: State of the Union
On Fri, 28 Apr 2006 21:42:57 +0200 Bryan Østergaard [EMAIL PROTECTED] wrote: So.. What can we do to improve things? I think that there should be some sort of organized way of connecting potential mentors and potential recruits. There is a very enthusiastic user who has been contributing great work to my overlay, but I cannot find anyone to mentor him (I've e-mailed [EMAIL PROTECTED] as well as [EMAIL PROTECTED] without much success). Maybe we should create a list of developers who are willing to mentor new devs? It would make finding a mentor much easier. ~tcort pgptBnvwxt1RL.pgp Description: PGP signature
Re: [gentoo-dev] Gentoo: State of the Union
Fernando J. Pereda [EMAIL PROTECTED] said: On Fri, Apr 28, 2006 at 02:06:36PM -0700, Ryan Phillips wrote: Second issue with git, is that with lots of tiny little files things don't work so well. I tried converting our portage tree into a git tree, and it ran for around 2 days until I finally killed it. If we didn't want to preserve history, then maybe it would work out. But with the problem I outlined above I still don't see it as a contender. There are lots of times when one would want to do a commit in one directory. Ryan, What tool did you use for that? AFAIK parsecvs[1] has converted some very big and broken CVS repositories successfully. - ferdy [1] git://git.freedesktop.org/~keithp/parsecvs I was using cvs2git. I sorta like git in certain aspects. If git would work better than CVS or anything other SCM I'm for it. Right now, _anything_ would be better than CVS. -ryan pgpDqAkxf42aD.pgp Description: PGP signature
Re: [gentoo-dev] Gentoo: State of the Union
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Thomas Cort wrote: On Fri, 28 Apr 2006 21:42:57 +0200 Bryan Østergaard [EMAIL PROTECTED] wrote: So.. What can we do to improve things? I think that there should be some sort of organized way of connecting potential mentors and potential recruits. There is a very enthusiastic user who has been contributing great work to my overlay, but I cannot find anyone to mentor him (I've e-mailed [EMAIL PROTECTED] as well as [EMAIL PROTECTED] without much success). Maybe we should create a list of developers who are willing to mentor new devs? It would make finding a mentor much easier. ~tcort wait till you have your required months at gentoo, then you mentor him, if you truly like his work, tell him you have to wait before you can mentor him, iirc 6 months from joining? he could wait till then, and maybe appreciate your working relationship even more, 6 months is a nice time to see if his performance is consitent too no dev has to refer anyone to someone else unless they are not long enough with the project, and then it is only a matter of time :) Daniel -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2.1 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFEUpCw/aM9DdBw91cRAkzvAJsFPdeCZzjH5niV9V0TOO2zQN5togCfd/gf dckrYu+XPRFbIJ0oZLGqhgM= =v6W5 -END PGP SIGNATURE- -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Gentoo: State of the Union
On Fri, Apr 28, 2006 at 02:56:26PM -0700, Ryan Phillips wrote: I sorta like git in certain aspects. If git would work better than CVS or anything other SCM I'm for it. Right now, _anything_ would be better than CVS. I don't really know if Git is suitable for our workflow though... I was just trying to clarify those issues you pointed out about Git. I locally manage a couple of overlays with it, but nothing compared to the portage tree. - ferdy -- Fernando J. Pereda Garcimartín Gentoo Developer (Alpha,net-mail,mutt,git) 20BB BDC3 761A 4781 E6ED ED0B 0A48 5B0C 60BD 28D4 pgpBDy9Dpn3Ta.pgp Description: PGP signature
Re: [gentoo-dev] Gentoo: State of the Union
Fernando J. Pereda [EMAIL PROTECTED] said: On Fri, Apr 28, 2006 at 02:49:18PM -0700, Ryan Phillips wrote: the only option I saw was git-commit -o and you had to specify the files that you wanted to commit. I tried doing a git-commit paths/ and still everything wants to be committed. It isn't pretty. Uh, no... thats certainly not true for git-1.3 series, and I belive the behavior has been consistent since early february this year when the new commit semantics where introduced. See this: --- 8 --- [ $ ~/testy/gitty ] git init-db defaulting to local storage area [ $ ~/testy/gitty(master) ] echo something a [ $ ~/testy/gitty(master) ] mkdir dir [ $ ~/testy/gitty(master) ] echo other thing dir/b [ $ ~/testy/gitty(master) ] git add . [ $ ~/testy/gitty(master) ] git commit -m initial import Committing initial tree 6dc01ab7eb7f19983ae76e72ccb63e3e60aa2dc3 [ $ ~/testy/gitty(master) ] git status nothing to commit [ $ ~/testy/gitty(master) ] echo add something here dir/b [ $ ~/testy/gitty(master) ] echo something there a [ $ ~/testy/gitty(master) ] git status # # Changed but not updated: # (use git-update-index to mark for commit) # # modified: a # modified: dir/b # nothing to commit [ $ ~/testy/gitty(master) ] git commit -m Only things in dir/? dir/ [ $ ~/testy/gitty(master) ] git status # # Changed but not updated: # (use git-update-index to mark for commit) # # modified: a # nothing to commit [ $ ~/testy/gitty(master) ] --- 8 --- It is the same even if you did 'git update-index a' before 'git commit -m ... dir/'. However that's something you won't do unless you know what you're doing :) I'm testing with 1.3.1. You are correct. The text the is printed by git is a bit confusing. If the portage tree can scale to it, then I'm for it. Thanks for the clarification. -ryan pgpUxk2oFOLaj.pgp Description: PGP signature
Re: [gentoo-dev] Gentoo: State of the Union
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Ryan Phillips wrote: Donnie Berkholz [EMAIL PROTECTED] said: Tim Yamin wrote: Speaking of which, has anybody done any tests with svk? (http://svk.elixus.org) And: http://svk.elixus.org/?WhySVK -- it would be interesting to compare checkout performance on it as well. I've been planning to do a more detailed comparison of all the popular SCM's out there for probably 6 months, but I just don't have the time right now. If someone wants to pick this up, please let us know. Recommended reading: http://www.keltia.net/EuroBSDCon/slides.pdf and www.keltia.net/EuroBSDCon/paper.pdf SCMs to test: cogito - Not practical * the lots of little files doesn't scale well with the size of the portage tree * In addition, git only allows checkins from the project parent. A deal breaker in my opinion cvs - Branching sucks - Merging is terrible - File deletes are bad - Atomic Commits svn + Atomic Commits + Merging/tagging/brancing is a simple copy operation http://svnbook.red-bean.com/en/1.1/ch04.html + lots of benefits http://svnbook.red-bean.com/nightly/en/svn.intro.features.html there is more I'm sure people can come up with - 2x Drive space Thanks Ryan, what we see is: the only - really is none at all localhost64 ffmpeg-0.4.9-p20060302-shared # du -csh /cvs/gentoo-x86/ 768M/cvs/gentoo-x86/ 768Mtotal localhost64 ffmpeg-0.4.9-p20060302-shared # du -csh /cvs/gentoo-x86/ - --apparent-size 224M/cvs/gentoo-x86/ 224Mtotal i waste more on the wrong block size with /cvs/gentoo-x86/ being on my 4K block size partition than the file size would add we could trick around to get all that smaller but let's be real for a moment, let's double the 768M, 1536M is nothing on today's machines, drive space is cheap, and if your disk is small, then you have no business running cvs or svn or anything with lot's of small files on 4k block size so looking at the list of SCMs, svn has only plus, and a theoretical - side that in 2006 is none --apparent-size print apparent sizes, rather than disk usage; although the apparent size is usually smaller, it may be larger due to holes in (`sparse') files, internal fragmentation, indirect blocks, and the like so put svn on a partition with small blocksizes/inode sizes and let's get on with the program Daniel darcs - haskell dependency - doesn't work on some architectures - IMHO, deal breaker svk - not a contender, it is subversion. if someone wanted to use svk with the subversion tree they could; it is transparent to any other. -ryan -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2.1 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFEUpTY/aM9DdBw91cRAvdFAKDUh9dNv025td6lm64YgKzZ6PwBbwCgvxL0 BIkORaLea2xiBzmbXpm6GSU= =lD3P -END PGP SIGNATURE- -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Gentoo: State of the Union
Grant Goodyear schrieb: Some questions that need to be answered: * Can the repo be converted while maintaining the history? * How long does a full checkout take? * How much disk space does a full checkout require? * Is there a viewcvs equivalent available? * Others that I can't think of right now? (Please feel free to add.) Right now portage and repoman have no support for using anything but cvs or rsync for the tree, e.g. repoman commit wouldn't work. Not hard to fix, but something to keep in mind. Marius -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Gentoo: State of the Union
Hi Ryan, Ryan Phillips wrote: I believe the way Gentoo is doing things is broken. There I have said it. The entire project has reached a level of being too political and trying to solve certain problems in the wrong way. I think it actually works quite well. Yes, there is space for improvement, like always, but the situation is at least not bad. __Problem: Developer Growth__ I find that developer growth as being a problem. Adding a developer to gentoo should be as easy as 1. has the user contributed numerous (~5+) patches that helps the project move forward. If yes, then commit access should be given. Adding a developer is usually quite a chore. There are numerous reasons why this is a problem: having a live tree, taking a test, and not defining within policy when a person could possibly get commit access. I can only speak for me here, but the quiz wasn't a barrier at all to me. Instead, it was an interesting way to make sure that I get familiar with all the stuff I have to. I found it a much better way to answer questions about a topic where you have to find the answers than just reading through tons of docs, not knowing whether something is important to you or completely unrelated. Besides that, I think the tree is far too worthy to give it away after 5 patches. Just because I fixed a bunch of compiling errors, that doesn't mean I know how to fix ebuilds. Just because I wrote a few ebuilds, that doesn't mean I understand how eclasses work, which ones to use where and what profile.bashrc is good for. I've seen ebuilds from people who have written quite a bunch of ebuilds and were really interested in understanding how they work, but the work they produced just was awful and hurt my eyes. I don't mean that the mean way, I don't expect anything else, and I was just the same. However, the mentoring process and the quiz have helped me a lot to understand not-so-obvious problems. All these reasons leave the project stagnant and lacking developers. I wouldn't say so. Just about two weeks or so ago, the recruiters had to defer new requests, because they couldn't deal with them in a timely fashion. You can now tell me that this makes it even worse, but I just see that as the proove of the fact that people are interested in helping us and ready to take the quiz and all the hassle involved with becoming a dev. Another good reason to keep the current process is the fact that a lot of people become dev and vanish a week after their mentoring period expired. These people would better contribute to the project in a more distant way IMHO, because it takes up a fair amount of time to clean up these accounts afterwards. If you don't beleave me, ask kloeri. ;) Perhaps its because of a live tree... That's surely a big factor. __Problem: Live Tree__ Having a live tree requires people to be perfect. People are not perfect and requiring it is ridiculous. I love having commits in my local tree within the hour, but having a stable and unstable branch makes a lot of sense. It doesn't require people to be perfect. It requires people to think before commiting. If it really required us to be perfect, we wouldn't exist in the first place, would we? Having a stable and unstable branch doesn't have many advantages over stable and unstable keywords IMHO, but requires a HUUUGE effort to keep them in sync. It would make things more complicated than necessary. You say we're lacking developers. Do you really want to spend [insert random big number here] of these much-needed developer hours to merging an old with a new tree? __Problem: CVS__ I would like to see us using svn instead of CVS too, but I think that's just a technical detail, not really fitting here. __Problem: QA Policies__ Everyone here is on the same team. There will be some breakages in the tree and those can be dealt with. Like Seemant [1] said, herds are just groups of like *packages*. The QA Policy is wrong when it says cross-team assistance; we are all on the *same* team. The tree should naturally work. If it doesn't then that is a bug for all of us. This sounds romantic. However, Gentoo to me isn't 300 people who are all my friends, all working on a common goal. Gentoo, to me, is a bunch of very nice people that share a goal with me, some big mailing lists with flames every now and then and a big mass of people whose work I use and appreciate but who I don't have a f*cking clue about. I don't know what they are like, they work on other things than I do. But that's not a problem at all. Conflict resolution should not be a subproject. It should *not* exist at all. You mean conflicts or conflict solution shouldn't exist at all? If the former, that's unrealistic. If the latter, why not? Rules need to be in place to avoid conflict. Having some sort of voting structure for all the developers (this doesn't mean requiring everyone to vote) and not just the council or
Re: [gentoo-dev] Gentoo: State of the Union
On Friday 28 April 2006 04:14 pm, Ryan Phillips wrote: I disagree. By committing something to the current tree it has the ability to effect a lot of people. What happens when we need to reverse a commit? It isn't that easy with CVS. cvs admin -or1.1 (delete revision 1.1) cvs admin -or1.1::1.2 (delete revision 1.1 - 1.2) -- Chris White Gentoo Developer aka: ChrisWhite cpw ChrisWhite|Work WhiteChocolate VanillaWhite Whitey WhiteLight WhiteCheese WhiteSugar WhiteButter WhiteWall WhiteLemon WhiteApple WhiteBlanket WhiteEnergy WhiteWhite pgphj3s2uEZ85.pgp Description: PGP signature
Re: [gentoo-dev] Gentoo: State of the Union
Chris White wrote: On Friday 28 April 2006 04:14 pm, Ryan Phillips wrote: I disagree. By committing something to the current tree it has the ability to effect a lot of people. What happens when we need to reverse a commit? It isn't that easy with CVS. cvs admin -or1.1 (delete revision 1.1) cvs admin -or1.1::1.2 (delete revision 1.1 - 1.2) If you have to use admin commands to fix a mistake, the system is broken. However in this particular case it is unnecessary, you just need to make use of the merging features. cvs update -j 1.2 -j 1.1 oldfile Thanks, Donnie -- gentoo-dev@gentoo.org mailing list
