On Tue, 2007-04-10 at 23:11 +0200, Alexandre Buisse wrote: > Sorry about that, I should have taken the time to look it up. Since I > didn't hear about it after Stuart leaved, I assumed no one was working > on it anymore.
Stuart's work had nothing to do with the implementation of stage4. His work was *utilizing* the stage4 target, not implementing it. I don't know about the status of the Seeds project itself, but Release Engineering has been working towards producing similarly-designed stage4 tarballs for some time. It is actually one of the motivators to moving to the desktop/server sub-profiles on the release profiles. > > Will this actually resolve any of the recent problems? > > Yes, as I tried to explain in the proposal. OK. I missed the solutions, then. > > Will this stop flame wars? > > Probably not, but it can help reduce the volume, hopefully. Indirectly, > of course, but I believe it would help a lot to reduce the tensions. Why bother restructuring, then? Why not just dump the gentoo-dev mailing list entirely and have everyone use the individual project lists that already exist for intra-project communications and have no official facility for inter-project or global issues. This sounds like what you're proposing to me, but I may be mistaken. > > Will this cause people be nicer to each other? > > Definitely, yes. Because everyone will work on a smaller scale. This is entirely speculation. The projects will still have to interact to be able to produce a cohesive product (the tree) so I don't see how artificially sectioning people off into their own little worlds will do anything to change the current situation other than possibly make some groups even more closed and xenophobic than they already are today. > > Will this give us more qualified developers? > > Will depend on how each team will do its recruitment. And of course, to > get official status, some kind of council would ensure some minimal > qualifications (along the current guidelines would be my guess). If these projects are still required to follow the same guidelines and still have a centralized Council to guide them, what is changing? > > Will this increase the quality of the tree? > > Hard to tell. Having people leave the project out of disgust certainly > doesn't improve it. Neither does avoiding a direct question. > > Restructuring the project isn't going to solve these problems. > > Not all of them, of course. And I never pretended it would. But I > believe that it would definitely help. How? Please be very verbose in your responses. Vague speculation and guessing isn't necessary. If you're unable to qualify your statements, please don't make them. If we're talking about restructuring the entire project yet again in an attempt to rectify the current social problems Gentoo is facing, I want to know *exactly* why I should consider it and *exactly* what changes you think will occur, including reasoning for thinking such things. > > At best, > > it will mask them during the time that we've wasted restructuring only > > to find that we are back with the same set of problems, though now > > without any form of centralized management to have even the glimmer of > > hope of being able to resolve them. > > I don't see how not having a centralized management would make it > impossible to solve problems. Or are people really that stupid that they > can't manage to get together and reach a decision, in some way or > another (I gave some ideas in the last part of the email as well). Just > giving all your power of decision to a big boss is a very crude and > unefficient way of solving problems. I had a feeling this was going to move in this direction. We have shown, quite well, actually, that there needs to be some form of leadership that is active in the global issues of the distribution. Nobody has ever said *anything* about giving over all decision-making ability to some "boss" group. Your description doesn't match the current state of things and is only used as a way of trying to convince people on an emotional level to agree with you where your statements aren't based on fact. > > It will take us to a complete mess > > of incompatible overlays and trees. > > If we do it carelessly, certainly. But free software has solved much more > complex problems in the past. No offense, but what does that have to do with my statement? Remember that as much as we like to tout Gentoo as a meta-distribution it is *also* a distribution of its own. It needs some kind of cohesion to keep it functioning. One of the things that keeps Gentoo cohesive, even with the current overlays, is that in almost all cases, the overlays for some project, such as Java, are run by the Java team. This means they won't have conflicting things around, since they manage both sides. If suddenly I were to go around creating a ton of Java ebuilds in an overlay, the Java team's overlay would still be the "official" overlay for the team, unless the team decided to adopt mine. How is your proposal any different? Why does *Gentoo* need to encourage competition within its own ranks when we've already shown that the competition can come from outside just as easily, if not more easily? Why not simply keep the "one project per area" that we have currently? Yes, I am aware that we *could* have competing projects doing the same work currently, but what real gain do we have from multiple people doing the same thing? Realize that I'm not talking about competing *alternatives* to each other, like portage/pkgcore/paludis, I'm talking competing teams doing essentially the same work, like having two Java teams. > > It also places the projects in a > > hierarchy that doesn't match the actual power structure. > > Power structure? I'm afraid I don't understand what you mean here. What I meant to say is what is the point in projects being a "sub" or in any way associated with another project if they're not under the same management tree of any kind. This is something that applies currently, too. Why is, for example, games a sub-project of desktop, when the desktop guys don't have any say in what games does? I think a flat project space for these independent projects is best, even with our current structure. At the same time, there *are* some projects that are directly related. A good example of this is Release Engineering and the Installer projects. While the Installer *is* a sub-project of Release Engineering, it is run by the project itself. However, the project *does* get some direction from Release Engineering. The top-level project requests features and other such things, and the sub-project provides them. Now, the project provides them under their own management, in a way entirely of their own choosing, but they still "answer" to Release Engineering in a vague sense. > > If the parent project doesn't govern the sub-project, then why is it a > > sub-project, at all? > > To ease coordination and make obvious relationships clearer, I guess. I'm not sure I see the point. Where do you draw the lines? > Can also help overlay management with hints like "you've pulled the > audio overlay, you probably also want the multimedia one" and stuff like > that. But it isn't really important, and the name "subproject" is > probably misleading. Agreed. I just don't see any need to associate the individual projects if they're not under the same management structure. Sure, people might want to associate projects due to their similarity, but I don't see how associating them politically has anything to do with them being associated technically. A good example here is GNOME/KDE. While both of them are very similar, they really have no need to have any association with each other to get their job done. Just because they're both desktop environments doesn't mean they need political ties. > > What exactly are all of us supposed to actually *do* while we're waiting > > for the SCM conversion and for the package managers to get the support > > necessary and all of the changes are made to the tree? > > Keep working on the current version? I don't know, I would classify that > as an implementation detail to be sorted if we actually decide to go > forward. That seems like an awfully big "detail" to completely gloss over. You're talking about completely changing the way that technical contribution, political structure, and social structure are all done within Gentoo. I think something so disruptive is quite a bit more than an "implementation detail" especially considering it is the subject of your proposal. > > Do we simply > > stop developing the distribution for days? Weeks? Months? > > I'm sure we can find a better solution than that. But do we want to > discuss such tiny details before the big plan itself? We'll just have to disagree that it is a tiny detail, since I see it as probably the most important aspect of your proposal. It's all fine and dandy to speculate on how we could be different, but if there's no way to *get* there, the whole discussion is moot. > > I think that the clique-like nature of many projects is part of the > > problem. We already have too much of a "us versus them" mentality. > > I'm not sure what you mean. Which projects are you speaking about? It > sounds like a silly accusation to me, but perhaps I'm unaware of some > other case. There have been numerous instances of this happening. For quite some time, there was a "Release Engineering versus Hardened" battle. It started before my time, and I have no clue why it existed, but it did. Luckily, both teams have long since worked through such problems and now happily cooperate, but it wasn't always that way. > > How will moving to having lots of independent projects with no central > > authority make Gentoo better? > > I have said this in the proposal. If you don't agree on specific points, > please provide arguments to back up your position. The specific point I'm arguing, then, is your assumption that making these changes will make anything better. I don't think you've shown enough proof that anything will improve by making the changes you've suggested. Because of this, I cannot point out specific instances where I do not agree, since I don't think there's anything to argue against. > > Will it make the distribution better for our users? > > Because gentoo won't be dead in a couple months? Because people will > think again that it's a fun project and want to be part of it? Are you really using rhetoric as an argument? What evidence do you have that Gentoo will be dead in a few months? If you don't have any, you can't exactly use that as a pro-change argument, now can you? Now, had you said something like "We won't be losing developers at a net rate of $x per month" or something else based in fact, I could at least attempt to argue for/against it. However, by arguing solely using conjecture without any facts to back it up, I cannot possibly argue the point. > > Reading back over your proposal with my questions in mind leaves me with > > exactly one last question. > > > > What, exactly, is your proposal supposed to actually accomplish? > > What I *want* to do is to make gentoo fun again. And I believe that > decentralising and giving more autonomy to people will achieve exactly > that, for reasons explained in the proposal. So what you're saying is that your proposal will make things "fun" again by taking what should be global problems, and forcing lots of individual groups to reinvent the wheel and tackle the same problems individually? Where are all of the unofficial projects going to get infrastructure from? Mirror space? Who is going to what is considered "Gentoo" and what isn't? How is this going to improve our image as a cohesive and competitive community-based distribution to our current and potential users? How are we going to ensure that we can even provide a single working product? You haven't answered any of my questions, as far as I can tell. You've simply deflected them or avoided them entirely. Rather than continue with this and turn it into a yet another long thread, that should, by the way, belong somewhere other than a development-related list since this is purely a political change in an attempt to resolve social problems, I'll wait until you've got something much more complete before rendering any further comments or questions. -- Chris Gianelloni Release Engineering Strategic Lead Alpha/AMD64/x86 Architecture Teams Games Developer/Council Member/Foundation Trustee Gentoo Foundation
signature.asc
Description: This is a digitally signed message part
