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 system - it's what keeps things together when everything else is falling apart - and those who undermine it are exceedingly dangerous to the organisation as a whole. 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. > Gentoo should be a fun environment. The previous paragraph should be taken as > a last resort. Gentoo should be a fun environment. I don't see how turning it into a popularity contest brings back the fun. And I don't see how it benefits our users. > __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. How many of the changes that are covered by the 50 or so GLEPs that exist today have been held up because of the GLEP process? How many of them would have been delivered today under your proposals? I don't think that your argument will stand up to that analysis. I do agree that the GLEP process isn't working. Would we miss it? > __Problem: Voting__ > > Gentoo has over 200 developers. People are generally against the voting idea, > but I'm not sure why. I've explained my personal reasons above. > The Apache Foundation has over 1300 developers; they must be doing something > right. I don't see how the size of a workforce is a measurement of success, unless you're a middle manager in a firm who needs an empire underneath you to justify the existance of your own job. In fact, I'd go as far as saying that it's our growth that has become our problem. Too often we've taken on people because we were grateful for the extra pair of hands, and haven't taken the time to see whether - technically and socially - they were right for Gentoo. But I don't feel that we're in any sort of crisis at the moment. We're continuing to deliver packages to our users, who are continuing to use what we produce. We're going through a patch where there are more disputes than some people are comfortable with; but as long as all involved continue to respect each other and to learn from each other, the individual issues will get resolved. It's the breakdown in respect between people that's the real issue that needs addressing. Too many of us only know each other from looking at pixels on a screen. I think it's time we got off our collective rears, and did our best to get all of us face to face at the same time. 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 -- 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
