On Tue, Mar 15, 2005 at 06:45:48PM +0000, Henning Makholm wrote: > Scripsit David Nusinow <[EMAIL PROTECTED]> > > 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. > > Meaning that they are kicked out and told to start their own project > where they can take matters in their own hands. Just what they've > always wanted to do, I am sure.
It's not ideal, but the fact remains that the people carrying the load for getting the release out aren't capable of dealing with it any more. The current situation is *broken*. This is an attempt to fix it. > > 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. > > Which part of "unstable-only" does one of us fail to understand? This is not set in stone. Unstable-only is simply what the current team is willing to set up and support themselves. Nowhere in the email does it preclude the ports from setting up something to manage themselves. > > 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. > > And you still claim that having this solution (non-solution if you ask > me) forced on an architecture from above constitutes "flexibility to > take matters in their own hands"??? Yes. All the tools are there to do exactly what they want to do, if they so choose. > > 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. > > However, they have now made it their job to tell the ports that they > *must not* move alongside the rest of Debian, whether or not the > portes want to or not. It's the decision of those doing the work. It's just just setting up and running buildd's that's the problem. In fact, it's striking that this has been the focus of most "DROP TEH PORTS!" discussions over the past few years, and yet this really isn't the issue that the proposal is meant to solve. Those doing the work of managing the release, managing d-i, and managing our backend all say that this isn't working. Bitch all you want, but the problems have to be solved and the current load placed on the porters isn't solving it. > > This does not preclude porters from making a stable release. > > Which part of "unstable-only" does one of us fail to understand? Which part of "proposal" does one of us fail to understand? > > In fact, all the talk I've heard assumes that they will (via the > > snapshot method). > > If you think a snapshot makes a distribution stable, then why do we > have testing and freezes for the main architectures at all? A snapshot doesn't make a distribution stable. A snapshot (or "freeze" if you'd rather) followed by a stabilization period makes a distribution stable. Not to mention the support phase, which is an also an issue. > > I think that when a port makes a stable release > > ... which it is not allowed to according to the Vancouver plan. Got a quote for this? Everything I've read and heard from those involved says differently. > > But ultimately, it's not going to be the RM's jobs anymore to make > > sure that these ports do release. > > Why do the RM's think it is their job to *prevent* the lesser ports > from releasing? They're not preventing them from doing any such thing. > > Think of it as freedom (which it is) rather than exile (which it's > > most definitely not) > > WAR IS PEACE > FREEDOM IS SLAVERY > IGNORANCE IS STRENGTH Fine. If you want to troll, go ahead, but you still haven't fixed the problems. - David Nusinow -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
