gravityboy (gravityboy) wrote,

  • Location:
  • Mood:


So, thanks to Ari I'm all moved in to my new place with Nicole. It's a complete mess and but it's going to be fun being there. I don't have internet at home right now (posting this from work) so I'll be going in to Debian hibernation mode for the most part during this time. Speakeasy is scheduled to come and hook things up on the 13th, which would be a nice post-birthday event. I'll be working on some Debian stuff in the meantime which doesn't require internet access though.

On other matters, reading Scott's post made me sad, though not surprised, much like it felt reading Matthew's post. It's sad to see people go, although they're still in the Debian family more or less. I can only wish them the best and hope that I get to meet them sooner than later.

Scott's post, as well as discussions with Mako, have got me thinking about setting up a committee in parallel to the technical committee: a distribution steering committee. The tech committee would be around to perform the same function it already does, but the steering committee would be the ones to make decisions that don't involve so much in the way of conflict. Questions like default MTA and desktop environment (which are more matters of preference than clear superiority) could be handled by the steering committee. The rationale for separating it from the tech committee would be to have the tech committee act as a check to balance the power of the steering committee. There could be a limited amount of overlap between the two, but not enough to allow a majority in either committee to serve in both. In order for this to work, the steering committee would have to have the ability to override maintainer decisions on matters that affect the entire distribution. If a maintainer had a serious issue with this, they could take it to the tech committee, who would have the final say. Any developer could do work on things mandated by the steering committee, including 0 day NMU's with such features, thereby allowing people to work across packages they don't own easily.

The key to the steering committee would be that it would set active goals for the release. The release team is able to currently set release goals, but they don't do so with any strong authority right now. People who wanted to do something like make upstart the default in Debian, would bring the case before the committee (who would also potentially set their own goals rather than wait around for people), get it approved, and then start working. They wouldn't own the packages they alter, but this would give them the ability to get the necessary work done. It would require a culture and a group of people who were actively interested in making things happen across the entire distro, much like Ubuntu has. I'd love to get some feedback on this to see if people think it's a good idea to pursue creating it. It would require changes to the constitution, but it might give us a mechanism to drive the project forward without resorting to a benevolent dictatorship of the DPL.
  • Post a new comment


    default userpic
    When you submit the form an invisible reCAPTCHA check will be performed.
    You must follow the Privacy Policy and Google Terms of use.