Thomas Cort wrote: > On 10/4/06, Luca Longinotti <[EMAIL PROTECTED]> wrote: > The number of opened bugs has always been higher than the number of > closed bugs in the bug stats listed in every 2006 GWN. How is this > 'going forward'? It seems to me like we are falling behind.
That's not an indicator you can really trust imo... A lot of those are "WTF??? segfault? eh?" and/or waiting on user input because they're irreproducible by the devs involved, but I agree, there are a lot of open ones because lately it seems that people tend to just go MIA, return sometimes, do 1-2 commits, then away again... This has to stop and such people have to be retired, but devrel already does that. And orphaned/broken ebuilds do get punted from the tree... TreeCleaners! >> Who decides what goes away and what now? Which criteria is used here? > > Duplicate packages (we don't need more than a few mp3 players), > unpopular packages with only a few users, unmaintained packages, and > broken packages. We've all seen how we don't need more than a few mp3 players when trying to remove XMMS, which is _broken_, _old_ and _dead_. :) One of Gentoo's strenghts is the "it's all about choice" paradigm, don't ever remove that, ever. ;) If there are people willing to maintain them, or if they are not broken and perfectly work, don't kill stuff just because you think it's duplicate/useless/unpopular. > We would provide a set of packages for most things a > user would want to do and then sunrise/someone else provides ebuilds > for the rest. I was thinking something similar to what Ubuntu does, > they provide the basics to do most things and then they have universe > and multiverse repos for extra stuff. Yes, but we're a meta-distro, we do not know what the user wants to do, he just does... I myself run desktops and www-servers, mail-servers, others run embedded-apps, game-servers etc... So the whole breaking stuff up idea that's cursing atm through the blogs just doesn't cut it, and would imo in the end only increase maintainance because packages are spread out and you have to jump through loops to get them like you want. >> > - Formal approval process (or at least strict criteria) for adding >> > new packages >> >> Err what? > > I believe that we have too many packages for us to maintain. We have > over 11,000 packages (over 24,000 ebuilds) and only about 175 active > developers. I don't think its maintainable and I don't think adding > more packages will make it any better. TreeCleaners, to an extent Security etc. _do_ remove what is dead, what has reached points of unmaintainability and brokenness that cannot be anymore supported. The rest still is there because it works (so why remove it?), or because it has someone that keeps it alive (so why remove it?). If there's something to do here, it's kicking out old, broken stuff etc. faster and improving QA (as Kevin already pointed out), definitely not making it so difficult to add new stuff that no one will, that only produces stagnation of the tree in the end. >> > - Make every dev a member of at least 1 arch team >> >> Which doesn't mean he will ever keyword stuff stable, other than his >> own, which he already can... > > Every developer should have access to at least 1 Gentoo system. They > should also be able to determine if something is stable or not. It > would cut down on the number of keyword/stable bugs if developers did > a lot of their own keywording. Cool... But that's exactly what the arch-teams were created "against"... From what I always understood arch-teams are there to have a second set of eyes for stabling and testing stuff, even if the maintainer himself can do that. Then he can stable his own stuff (just ask the arch-team permission), or not... And the arch-team may or not give permission, depends on the package in question. That's a relatively good approach that ensures a measure of peer-review at least on the "important" packages. >> > - Double the number of developers with aggressive recruiting >> >> That's something that goes on since... > > Even when someone is found it is hard for them to find mentors. We > need to improve this. I had found someone who wanted to join the sound > team and I was unable to locate a mentor for him (I wasn't a dev for 6 > months then, so I couldn't do it myself). I e-mailed [EMAIL PROTECTED] and > only one person offered. The person who offered fell through because > he didn't have enough free time. Ok, so I don't see how "aggressive recruiting" would improve that... Improving recruiters/mentors capacity would have to be done first, so even if we did some "aggressive recruiting" (which I'm not sure would bring quality... probably quantity "hey cool Gentoo wants new devs, let's join cause I like Linux! w0h000!!11!), we wouldn't have the resources to sustain it. >> > - No competing projects >> >> Kills innovation... > > What happened to working together? Should we work together instead of > competing against each other? Sure, working together is cool, but it doesn't always work, it never always worked. That's maybe sad, but it's true. If you have a group of people with totally opposite ideas than another, but both are, in the end, good ideas, you cannot just tell one group "hey you cannot, do what the others want!"... Let projects compete _if they must_, and let's see how it goes. I thought it implicit that there should be a "let's discuss it and work together" stage first, but if that fails, competing projects should and must imo still be allowed. >> > - Drop all arches and Gentoo/Alt projects except Linux on amd64, >> > ppc32/64, sparc, and x86 >> >> Uhhh is this real? How would this help at all? > > We've got tons of keywording/stable bugs. There aren't enough > developers to do all the proper testing on all of the architectures > supported by Gentoo. Many of the arches are dead or soon to be dead > (m68k, alpha, mips, etc). I know we've got tons of stale keywording bugs, I myself often get upset that I have to wait 6 months on keywords for some package, but otoh I see that just killing off the arch totally isn't probably the real solution... As I already said, a relaxing of the current keywording policy for maintainers is what's needed... If in a month no one from archX keyworded dev-lol/asd stable, I as a maintainer could just drop their stable keyword and revert to unstable, or if it's some major version bump that requires testing for unstable even, just drop support for that arch entirely. Users will then notice and maybe even help if the package they were using suddenly has no more keyword for their arch, or if no one cares... well then, no harm done in dropping that particular keyword... this would in the end produce a kind of "self-dekeywording" of the tree, and make it much cleaner. >> > - Reduce the number of projects by eliminating the dead, weak, >> > understaffed, and unnecessary projects >> >> Again, who's the judge of that? If there is a project with at least one >> person active, it means for him it's not unnecessary... What means weak >> project? What's unnecessary? Sure, kill the dead ones with no activity >> and no active members, that's easy and I agree with that, but the other, >> little ones, who's the one to say "you're understaffed and useless, go >> die!"? :S > > We come up with a list of potential cuts and then the council decides Hmmm still don't see a definition of unnecessary, weak or understaffed. Dead, sure, kill them on the spot. Unnecessary? Who are you, other devs or the council to just tell someone that's working on a project as a volounteer "hey, we think your work is useless, drop it, now!", and understaffed/weak is too subjective, especially since workload anyway changes over time. -- Best regards, Luca Longinotti aka CHTEKK LongiTEKK Networks Admin: [EMAIL PROTECTED] Gentoo Dev: [EMAIL PROTECTED] SysCP Dev: [EMAIL PROTECTED] TILUG Supporter: [EMAIL PROTECTED]
signature.asc
Description: OpenPGP digital signature
