On Tue, Mar 15, 2005 at 07:13:39PM +0100, Marc Haber wrote: > On Tue, 15 Mar 2005 11:17:25 -0500, David Nusinow > <[EMAIL PROTECTED]> wrote: > >On Tue, Mar 15, 2005 at 08:04:31AM +0100, Marc Haber wrote: > >> From what is public visible, the security team has lost at least one > >> of the active members to ubuntu with no replacement up to today. > > > >We didn't "lose" him to Ubuntu. The man got a job and is busy. It would have > >been the same with any other job that keeps one busy. There's no grand > >Canonical Conspiracy [tm] to keep him from working on Debian. > > If his job is keeping him from working on Debian, he should step down > from his post.
His position isn't preventing someone else from stepping up and joining the security team. It's not like some package that he's claiming as his own and letting no one else upload. > >> And > >> d-i's effort is practically wasted since we decided for d-i because we > >> needed to support more architectures. If we had thrown out the > >> doorstops years ago, we could simply have taken one of the readily > >> available installers without rolling our own. > > > >No one is actually dropping those arches. They still have every option to > >release a stable release using d-i. > > Do they? The announcement looks noticeably different. My interpretation of the announcement, and this also comes from talking with some of the people involved, is that this affords ports with the flexibility to do as they please without slowing down the rest of the project. For *years*, I've heard porters complain about ftpmaster and such. Well, now every port has the full ability to take matters in to their own hands. They still upload to unstable, just like always. Autobuilders for those arches still run, just like always. These arches still have a host or number of hosts with sufficient drive space to manage their port, just like always (although the url will be changed to something as of yet undetermined). The differences? Port packages don't go in to Debian mainline testing. However, this does not preclude them from setting up a separate testing if they like. The people involved with the Vancouver document know what they're doing, and they've said (more than once when I've heard) that the unstable snapshot method is better than setting up a separate testing, and I believe them. Also, RC bugs that are specific to a port have a non-RC severity, although bugs are bugs and should be fixed by the maintainer even if it's for a port. NMU's are still very fair game in these circumstances. And when the time comes to release, it's simply not the release managers' jobs to make sure the port releases alongside the rest of Debian. This does not preclude porters from making a stable release. In fact, all the talk I've heard assumes that they will (via the snapshot method). Their ability to work is no longer hampered by overloaded RM's/ftpmasters/whatever. I think that when a port makes a stable release it'll be thought of as an actual Debian release, especially when it sync's up with the mainline stable release. But ultimately, it's not going to be the RM's jobs anymore to make sure that these ports do release. Think of it as freedom (which it is) rather than exile (which it's most definitely not) and the whole thing sounds much better. - David Nusinow -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
