Michael Scherer <[EMAIL PROTECTED]> writes: >> 1. A developer is still maintaining a package, but wants to stop >> 2. A developer has stopped maintaining the package and wants to let >> others know about it. > > Well, orphaned package need to be adopted before any work is done on it, > that's right ?
Before significant work is done, yes. > If so, why not put them in a special zone, where people can submit some > changes, without having the burden of maintening it ? That's about what it amounts to, actually, though those changes are generally supposed to not be significant -- that is, bug fixes, etc. But you have an interesting idea that we might be able to use. Makes sense to go ahead and let orphaned packages have more effort. What generally happens is that if nobody steps up to maintain them, they will eventually become bug-ridden and uncompilable, and be removed from the distribution. That generally means that nobody cared enough about the package to maintain it, and so removing it is probably a good thing. >> I'm not sure what the difference is here. Debian's release schedule >> is, according to everyone, too long. No quibbles there. It's >> nominally based on time, too. > > Well, I tought it was in term of software. > For Woody, it was perl 5.6, Xfree4.0 and kernel 2.4, or something similar, I > think. That was true at one time, but it's not how it works now. We're taling now about when to freeze for the next release, and we're waiting for a serious bug in the latest glibc to work out. The way it is supposed to workq now is we set a timeframe for the next release, and then when that time arrives, the software that has shown up in unstable is put into testing and then we get it out the door. Sometimes we hold up the release to work out bugs in the packaging of major things like a new Perl, if we decide it's important enough to put into the new release. > So, no features freeze until these are out and tested a lot. > But, it is possible I was wrong. Actually, here's how it happens: 1. Developers build all their packages with "unstable". 2. After a given package has been in unstable for x days without an open serious bug on it, it will be migrated to "testing", but ONLY if all the packages it depends on are already in testing. This is an automated process. 3. Testers for the next "stable" release track testing, submitting bug reports where necessary. 4. When we decide to make a release, we restrict migration from stable to testing to be bugfixes only. 5. When there are no open release-critical bugs on testing, the release is made. -- John
