[arch-dev-public] discussions to death, rules - no innovations?
In the last few weeks I've seen so many threads about rules and votings we want to give ourself(e.g repo destinctions and repo dividing lines, pkg signoff, iso naming, package movements, license issues, cvs move,...). Wasn't it the big advantage to trust the ArchLinux developers that made it fast growing and bleading edge with an acceptable level of instability? I still like to decide myself what and when to move packages into the repos or when to remove them. Now I have to ask and wait for other devs to signoff packages even for minor bugfixes. And that for two architectures. Didn't we elect Mr. T to become the release manager to let him decide what to do? Now with all the discussions to death and often no actions following - see orphans and cleanup - I loose some of the Arch feeling. All these coming rules seem to slow us down more and more without finding new skilled manpower. I'm sure we all only want the best for ArchLinux but is that the right way? Some rules are always ok. But I have the feeling we are on the way to become somewhat of an overcontrolled and superduper planned Debian. Don't you feel the same? Andy
Wednesday 24 October 2007, Andreas Radke wrote: | In the last few weeks I've seen so many threads about rules and | votings we want to give ourself(e.g repo destinctions and repo | dividing lines, pkg signoff, iso naming, package movements, | license issues, cvs move,...). | | Wasn't it the big advantage to trust the ArchLinux developers that | made it fast growing and bleading edge with an acceptable level of | instability? | | I still like to decide myself what and when to move packages into | the repos or when to remove them. Now I have to ask and wait for | other devs to signoff packages even for minor bugfixes. And that | for two architectures. | | Didn't we elect Mr. T to become the release manager to let him | decide what to do? | | Now with all the discussions to death and often no actions | following - see orphans and cleanup - I loose some of the Arch | feeling. All these coming rules seem to slow us down more and more | without finding new skilled manpower. | | I'm sure we all only want the best for ArchLinux but is that | the right way? Some rules are always ok. But I have the feeling we | are on the way to become somewhat of an overcontrolled and | superduper planned Debian. | | Don't you feel the same? | | Andy not ... yet :) growing induces levels of complexity. a principle in biology.... or have you seen recently a 2 m big bacteria walking around and discussing things with us? if you want to grow, get more users, then you need to ensure some processes to work. you wanted to have stable branches from what i read on the other thread (sorry, if i misunderstood... didnt get the whole discussion). one implemented thing is that two devs have to sign a pkg that is core. this works ... it spamms the ml a little, but it works. it slows down release, thats true, but with this additional line of complexity, it ensures not a single dev breaking the core. ... well... still 2 can break it :) hi hi... but that is less probable to happen :) besides this, we discussed lots, thats true. i stopped also reading the "kill cvs" thread, because i expressed my opinion in the so named "Damiristic" way. the last status report summarises - as it should - the state of all this ongoing things. one email to summarise everything - i do not know that other repos have such plain organisation/documentation of processes *fg*. however, it lacks things, that i usually specify in my SRs: deadlines on when something will be decided. i know from the calcutta-project where i'm leading the public relations / fundrasing that deadlines are not easy to set in a all-volontary project. nobody wants to stress others on decisions. we all do it for fun, right? --- however, they should be done... and are done, but sometimes too slow or even get forgotten... or fall out becase of too-low priority. (e.g. i didn't find yet the time to write the patch for including the automatic emailing of news to the mls - i know, however it is under the priority limit i'm dealing now in my free time... it will come "soon" :) however, i would welcome for group-decisions and discussions a deadline and schedule aware organisation. we discuss, but we need to set * the date how long we have to discuss, * who votes when and * till when it is decided. i think this slowdown you feel a little bit... it is not not arch. it is not not KISS. it is just one of the strains of growing, while still being KISS :) - D -- .·´¯`·.¸.·´¯`·.¸¸.·´¯`·.¸.·´¯`·.¸.·´¯`·.¸.·´¯`·.¸¸.·´ ° ° ° ° ° ° ><((((º> ° ° ° ° ° <º)))>< <º)))><
On 10/23/07, Damir Perisa <damir.perisa@solnet.ch> wrote:
however, it lacks things, that i usually specify in my SRs: deadlines on when something will be decided.
I was on the fence about this. The reason is that I/we already have so many normal deadlines doing other things, one or two more might be "too much", The intent, of the "short term" tasks, was to address them as soon as possible, and the long term ones would be more lax. In a way, the intent was to provide an unofficial and nebulous set of deadlines. The problem is, most of us are not action oriented. And this is a big problem.
Wednesday 24 October 2007, Aaron Griffin wrote: | On 10/23/07, Damir Perisa <damir.perisa@solnet.ch> wrote: | > however, it lacks things, that i usually specify in my SRs: | > deadlines on when something will be decided. | | I was on the fence about this. The reason is that I/we already | have so many normal deadlines doing other things, one or two more | might be "too much", true. i am sure you are capable of ballancing this right. not an easy task :) | The intent, of the "short term" tasks, was to address them as soon | as possible, and the long term ones would be more lax. In a way, | the intent was to provide an unofficial and nebulous set of | deadlines. the problem with this kind of deadlines is, that they are not documented and fall out of mind easily. it's not needed to specify a date and time for the exact second to be held as valid but to just write a rough date/time that is kept somewhere and that people see. people like symbols for milestones. if not, (especially) the (low priority, longterm) issue creeps around on the mailinglist and comes to the surface every 3 months or so without being resolved (switching from CVS to something else was suggested years ago.. yet again everything is discussed again from tabula rasa - i'm simplifying here, i know). another thing is: as soon as possible is tricky for | The problem is, most of us are not action oriented. And this is a | big problem. not (immediate) action oriented people. you cannot point to asap, but you can point to a date. the date functions as a symbol, a landmark that separates the not-decided state with the decided one. if somebody feels its too short, it is always possible to say, lets prolong it for 3 days... but every 3 days moving the date has to be agreed on or decided (question: are we capable of deciding now? no? ok, in 3 days maybe - if in 3 days nothing happened, it will be decided - if lots change, there is enough to decide now). to take an example: [extra] mutation to [mantle]+[crust]. the discussion took place, there are for days no new comments, but there is no decision. you asked the question in the SR, but no date was set. often it helps to say: on 28. october we will have this decided. if not in plenum, i (you) will decide it. it anchors the whole issue to a date and anchors (associates) it also in our brains with all the discussion, that behind this date, this is either an archived concept somewhere in the archives, or it is realised. it is not any more laying around for people to fall over it, if they walk around uncarefully. we let our toys laying around like small children :) - D -- .·´¯`·.¸.·´¯`·.¸¸.·´¯`·.¸.·´¯`·.¸.·´¯`·.¸.·´¯`·.¸¸.·´ ° ° ° ° ° ° ><((((º> ° ° ° ° ° <º)))>< <º)))><
I'll chime in, and then attempt not to get engaged in the "reply to every reply" syndrome chastised by the open source projects book. Andreas Radke wrote:
In the last few weeks I've seen so many threads about rules and votings we want to give ourself(e.g repo destinctions and repo dividing lines, pkg signoff, iso naming, package movements, license issues, cvs move,...).
Wasn't it the big advantage to trust the ArchLinux developers that made it fast growing and bleading edge with an acceptable level of instability?
It depends on what kind of instability. Arch introduces inherent instability because it uses the most cutting-edge things and delivers them quickly. This is good instability, because it's the kind that inherently comes from living on the cutting-edge. I agree, that's part of our distro identity. Organizational limitations and lack of peer review lead to bad instability. Instability that is infused into otherwise more stable software by our assembling it poorly. I think the bad instability is the kind we're trying to stamp out, without ignoring the benefits of the good kind. As a result, we're trying to find a system that slows us down just enough to still get most of the good instability and eliminate most of the bad instability.
I still like to decide myself what and when to move packages into the repos or when to remove them. Now I have to ask and wait for other devs to signoff packages even for minor bugfixes. And that for two architectures.
Didn't we elect Mr. T to become the release manager to let him decide what to do?
We're all part of a group building a group project. What I do affects you and what you do affects me. It's reasonable for at least two developers to get some weigh-in when an important package is modified. Many times it will be perfunctory, but sometimes it will be important and will save tons of hours of user support and headaches. To take the specific example: I think sign-offs in core are a good idea, though I think the current mechanism for them is bad. Once we have 2 or more people registered as maintainers for each package in core, the sign-offs can be two of those maintainers, and the whole development staff doesn't have to be distracted by every sign-off. The point is: we needed to take a step to see if sign-offs had benefits. It seems like they did. We will continue to optimize them so they slow us down as little as possible while giving us as great stability benefits as possible.
Now with all the discussions to death and often no actions following - see orphans and cleanup - I loose some of the Arch feeling. All these coming rules seem to slow us down more and more without finding new skilled manpower.
I'm sure we all only want the best for ArchLinux but is that the right way? Some rules are always ok. But I have the feeling we are on the way to become somewhat of an overcontrolled and superduper planned Debian.
Don't you feel the same?
I don't. Have you ever seen the voting formula for Debian elections? We're far from that, thankfully. Recently, we're having more discussions about important issues than we have before, writing more code, involving more people, making more things happen than were happening before Aaron took the helm. Certainly the shift from the invisible hand of Judd to Aaron's more active management style is a stark contrast.. but things are happening, and most of it is about inspecting our current state with a critical eye and trying to solve the problems that have been plaguing us for a long time, streamline our own processes and systems, and make each hour we spend on Arch more efficient and result in a better product. Open source projects live and die by consensus. Not by dictate, not by votes. When enough of us agree, something will get done. The funny thing about consensus is you can't force it to happen.. but when it does happen, it's inspiring, and that's what causes someone to take action and do good work. And that's happening more often than it was before. We still do trust the Arch developers, but to make the most of the single distro that we all maintain, we have to communicate more and work together more effectively. It's not that one man acting alone is "wrong" it's just that he's not going to produce as good a product as one man acting as part of an organized and thoughtful group. - P
On Wed, Oct 24, 2007 at 12:33:49AM +0200, Andreas Radke wrote:
In the last few weeks I've seen so many threads about rules and votings we want to give ourself(e.g repo destinctions and repo dividing lines, pkg signoff, iso naming, package movements, license issues, cvs move,...).
Wasn't it the big advantage to trust the ArchLinux developers that made it fast growing and bleading edge with an acceptable level of instability?
I still like to decide myself what and when to move packages into the repos or when to remove them. Now I have to ask and wait for other devs to signoff packages even for minor bugfixes. And that for two architectures.
Didn't we elect Mr. T to become the release manager to let him decide what to do?
Now with all the discussions to death and often no actions following - see orphans and cleanup - I loose some of the Arch feeling. All these coming rules seem to slow us down more and more without finding new skilled manpower.
I'm sure we all only want the best for ArchLinux but is that the right way? Some rules are always ok. But I have the feeling we are on the way to become somewhat of an overcontrolled and superduper planned Debian.
Don't you feel the same?
It's funny you have all that to say, and yet at the same time you wonder in another thread why frugalware is able to get so much stuff done. I read you mail as "I like doing whatever the hell I want, when I want, without asking/telling anyone. And I think that's the best development model". Well, even if it wasn't what you meant to say, that's certainly what we've been doing for the past six months, and you said you liked it that way. Now about frugalware. While I haven't really read up on it a whole lot, I've looked a bit. And ironically enough, the EXACT reason they get SO much done is because they have PROCESS. Yes, that's right, they have a solid development model and a process for getting things done, and surprise! stuff gets done! So I don't understand how on one hand you envy their productivity and on the other you refuse to acknowlege that the way we're currently doing things just doesn't work. Look, the point I'm trying to get across here is that on one hand, I agree with you. Yeah, we bikeshed a heck of a lot more than we used to. But that's not the main issue. The big issue here is that our current way of doing things is the very reason we are so unproductive, and end up having these ridiculous discussions! And THAT is why Aaron is working his ass off to change it! By introducing small things like signing off packages, he's introducing a simple but effective process, bit by bit, that will ENABLE us to become more productive in the longrun. And you know, not to seem like an ass or anything (too late huh?), but if you really think you can do better with your "model", well, stop whining about it and fork already. I mean after all, if it's your distro you won't have anyone to complain to about stuff not getting done except yourself. Disheartened, -S
Wednesday 24 October 2007, Simo Leone wrote: | And THAT is why Aaron is working his ass off to change it! By | introducing small things like signing off packages, he's | introducing a simple but effective process, bit by bit, that will | ENABLE us to become more productive in the longrun. productive + successfull in the long run - D -- .·´¯`·.¸.·´¯`·.¸¸.·´¯`·.¸.·´¯`·.¸.·´¯`·.¸.·´¯`·.¸¸.·´ ° ° ° ° ° ° ><((((º> ° ° ° ° ° <º)))>< <º)))><
participants (5)
-
Aaron Griffin
-
Andreas Radke
-
Damir Perisa
-
Paul Mattal
-
Simo Leone