I’ve just spend some precious time on going through the DPL debate log MJ Ray provided. Thanks for that.

A couple of things I want to mention / suggest:

  • SCC is a bad name in my opinion. Let’s name them “ports”? And by dropping certain “requirements” it will be maybe easier to get Debian GNU/kNeetBSD or GNU/kFreeBSD (or kl*, whichever has enough Developers) integrated.
  • Noone says that the ports may not release etch, too. They are just not considered to be essential for the release of etch. I can well imagine ports to release at the same time (providing an own security infrastructure, which will autobuild packages when released for etch or if possible in sync with the core etch architectures) if they can keep up with building.
  • Infrastructure: apparently ssh needed a special patch to scale with our release demands. We still have some tight spots in our infrastructure. You should not forget other archs when talking about infrastructure, too. Some of the arch requirements for etch are infrastructure requirements. They are just harder to solve for these architectures; maybe separating them from the release as suggested is the most practicable way of solving them.
  • Scale/infrastructure problems: we have some problems here that are usually overlooked. For example, I do not read debian-devel any more, and just delete whole threads from debian-private, too. (and reading all this would bring my productivity down a lot!)
    Maybe this is or will be the next big infrastructure problem - the “community” getting to big to be a real community. I fear that more and more developers start to get alienated due to the sheer amount of mails and data.
    The Debian Weekly News and the Planet Debian Blogs is what keeps me up-to-date with the community, currently. Already sometimes my RSS feeds are getting to much to read…
    I think that the “rise” of planet.debian.org is partly due to it providing a more handleable amount of information by avoiding long threads to evolve - and by keeping the write permissions to “insiders”, which partly is against our social contract, I guess.
    I believe that sooner or later, planet.debian.org will also grow to big to be read by as many people. We need to find a way to get this more manageable. I don’t know the solution for this, either. I have just some vague ideas.
    Currently, the NM process only captures developers. Others may in fact not need to become Developers, anyway. The role I’m thinking of is some kind of moderator - getting the right people to read the right mails. This can take several forms - forwarding mails into appropriate mailing lists, tagging them into groups (and providing a web page, where I can select the groups I’m interested in) or also making some DWN-like “daily news” (which might allow me to respond in-time to a posting to debian-devel, for example).
    On the other hand, while being able to filter with moderation points etc. (like on slashdot), or maybe just removing all posts marked as flame or funny, I hate web forums, and know of no nice way to do this with mail
  • on a similar case, we may happend to have our bug tracking overrun, once we release sarge and maybe obtain more users. I expect bug duplicates to be reported more often in the future (so we’ll probably need “moderators” to process incoming bugs), and with the new stable version we’ll have the old problem back of bugs being already fixed in testing/unstable but still being present in stable. I don’t think our current system is capable of handling that, although patches have been written some time ago I think. (And no, I do not want bugzilla. Bugzilla is very unfriendly to the casual user, and I have on more than one occassion not submitted the fix for a problem or not reported a bug because I either could not remember my password or hadn’t yet registered. Debbugs uses a not very different approach actually, when I’m trying to be fair: We require people to find and use the “reportbug” tool, or read a lot at the web pages on how to write an appropriate mail…)
    Another problem with bugtracking is the lack of synchronization with upstream bug trackers. I wrote a script to help with that some time ago (“debugzillasync”) and got some positive feedback on it, but it can’t save you that much work - you still need to forward bugs to upstream and add the appropriate “forwarded” information back to bugzilla and -sync. Its more useful to re-check old bugs that might have been fixed upstream.

Well, enough “brainstorming” for me today… or better tonight, 04:26 in the morning now. Maybe I’ll be able to read through the voting platforms the next days and write some more comments down.