Differences between revisions 14 and 15
Revision 14 as of 2009-01-14 16:34:13
Size: 5539
Editor: SvenMueller
Revision 15 as of 2009-03-16 03:32:39
Size: 5539
Editor: anonymous
Comment: converted to 1.6 markup
No differences found!

It seems to me that the goal testing was set to accomplish has never been fulfilled. It was supposed to be RC-bug free, or very nearly so, and if one wanted a newer version of some package, one had to fix bugs in its unstable version so that it could enter testing.

The problem is that sometimes a bug is discovered after a package has entered testing, thus defeating its purpose. As it stands, it only helps to prevent the freezing of unstable when preparing for a new release, but is this really necesary, given that Debian has also experimental?

It seems to me that the way testing ended up being used has to be very carefully thought over and see if it is worth keeping. Maybe it doesn't do what it was supposed to do. But it may be useful none the less.


Mod first paragraph (Score: 5, Insightful) ;). --Ellmist

Could we perhaps explore ways to make it more likely to find RC bugs while a package is still in unstable, before it propagates to testing? Would that help any --?KenBloom

I think that one way of doing this is changing the way the migration of packages works (i.e. not automatic). Lots of packages have gone into testing while the maintainer intended for them to stay in unstable a lot longer. Let the maintainers submit an email to some bot when they think the package is ready for testing, and NOT have to file an RC bug to keep the package outside testing. In this way, we are leaving a lot of judgement to the maintainer, but it's still better than automatic migration. -- Marga Manterola.

I totally agree with Marga. I find myself to often upload to unstable software that does work fine, but that doesn't meet the quality requirements I'd want on a proper release. If I uploaded it to experimental, noone would use it, because experimental is understood to contain what is known NOT to work. If I didn't uplaod it, developers and bleeding-edge people wouldn't be able to use it, so it would be useless and get no testing, delaying a high-quality release even more. I had in mind the idea of making a 'release-quality-unstable" archive where one could upload new versions that are thought to be "good!", but Marga's proposal of advertising "ready-for-testing" versions is actually better since it avoids the creation of yet another archive. -- EnricoZini

I think automatic propagation is important and I wouldn't want to lose it. The extra work of having to push packages into testing by hand would be too much, IMHO. That said, I think that allowing maintainers to block propagation without filing an RC bug is a great idea and a missing feature. If maintainers would like to upload a bug fix of the version of the package in testing, they can currently upload directly into testing. More complex solutions with additional distros could help mediate some of the problems here but I think that may become more complex a solution than the scope of the problem implies. Having something simple and mostly automatic that just Does The Right Thing is important and I think that fixing the current problems with additional complexity will ultimately create more problems than it solves. -- BenjaminMakoHill

I apologize for my ignorance on the debian repository system, but--and this really only applies to an automated unstable>testing migration--perhaps instead of (especially RC) bugfixes being applied directly to testing, what about the testing package being jumped back up to unstable upon an RC bug being submitted? I know this would cause havoc with ppl's systems that only allow <=testing installed, so we'd probably have to modify how dpkg/apt handles such cases (when apt-get update'ing for instance, to notify the user of a package's move back upstream, and whether they want to keep their current version or re-install the older one).. This is sort-of the opposite of AddAnotherRepositoryBetweenUnstableAndTesting, since it's blurring unstable and testing into one repository with two categories (RC-ready, and RC-bugged). So, package management headaches aside, this should provide a much more release-ready testing at any given instant.. Although it will probably have an adverse effect on how 'modern' certain versions of software will be in the archive -- axs

This looks a lot like AddAnotherRepositoryBetweenUnstableAndTesting. I had some ideas along the lines of increasing the time to propagate to testing (probably a bad idea), or forcing urgency=low in any case where the urgency=medium or urgency=high package doesn't fix an RC bug in testing. And also RunDinstallHourly. -- ?KenBloom

Why is increasing the time to propagate a bad idea? From a user's perspective, I see little difference between Unstable and Testing. In order for me to use (and test, and thus help to ensure timely Stable releases) Testing, there needs to be a difference. -Ben Smith

I would propose adding a new priority, which allows the maintainer to say that a package shouldn't automatically propagate to Testing. Obviously this should be overridable later on, without the need to upload a new package version again. Perhaps by signed mail or a signed control file uploaded to Incoming. Also, I don't see why increasing the time to propagate would be such a bad idea, I always thought that 10 days are a bit too short to really detect problems in the uploads. And there is always the option to shorten the period by a higher priority upload if the need should really be there. -- SvenMueller

Back to ReleaseProposals