Hi, Thanks for voicing your opinion.
On 09/15/2011 02:15 AM, Joerg Jaspert wrote: >> I think that going this way, with RC bugs preventing migration, is a >> much more reasonable way to manage the issues. > > That depends on the severity of the issues. And on a possible wrong > perception of what unstable actually is. > > Wrong: A dumping ground for software, and if it doesn't work out for a > stable release we just file RC bugs to prevent migration. > This, quite unneccessary, costs resources on the release team > (and possibly QA team) side, which are very sparse anyways. > > Right: Putting software into unstable means "This is software that I, as > its maintainer, happen to think ready for Debians next stable > release". > > Sure, this well may have bugs, but then they should be fixed > timely and the software kept up to par with policy and all other > requirements for a stable release. And not "out of it". I believe I have done timely fixes of the security issues that have been (recently) reported. I also uploaded a security update for the old-stable (which took longer to release), but I still don't have an answer for that one (see below). Now, I believe everybody understands that having fixes for being policy compliant is another much longer process: since I had a different reading of the policy manual for #637501 and #637622, a major redesign has to happen. I believe I will find a solution for #637501 in the long run, thanks to discussions I had with other DDs at Debconf and new design ideas that I have. But this implies other package maintainers to cooperate, which might be the harder part here. I would like to use this opportunity to discuss #637622 here as well. I have seen many pointing fingers, but very few showing interest in finding solutions for this problem. Remember that this is an issue that Debian EDU is also facing. Software generating configuration automatically is a Debian problem at large. I would be pleased to have advices and opinion on what would be the right way to do it. I strongly believe that saying such a software writing configuration files for Apache, Postfix and bind shouldn't exist at all is wrong. There's a demand from users, and many companies have built software doing the same things, that they sell for a lot of money (see Plesk, cPanel, DirectAdmin, and many others). My previous reading of the policy manual was that *maintainer scripts* shouldn’t do that, and I believe this was the reading of other DDs too. If currently there's no way to do it cleanly, and being policy compliant, then we really need to solve this. What are your opinions and ideas? > Oldstable is a thing for the (O)SRMs, whatever they decide. If they tell > us next time we do a point release to remove it, gone it will be. > > Now, reading through this bugreport and skimming over > > http://bugs.debian.org/cgi-bin/pkgreport.cgi?src=dtc FYI, somebody pointed out that I failed to tag "fixed-in" for #637630 and #637632, so "only" (with quotes to tell I understand it's serious issues) #637501 and #637622 are now relevant to the SID version, and also I've uploaded a lenny-security version (which I have no news from, I don't know if it has been accepted or rejected). If the package is to be removed from Lenny, I'd really like that the security update that I uploaded be shipped first. There would be nothing more wrong than just removing the package without giving support to our users. > my thought is that this package should not be in sid. So yes, I support > those thoughts by the ftp and release team members who spoke up on it > yet. > > OTOH that makes it harder to keep track how its going on and we only end > up with it back in NEW whenever, so it won't help anyone. > > My (strong) suggestion is to upload the latest version to experimental > and then remove the one from sid. Keep it in experimental, get it > developed further, fixed, whatever. Recheck it in some time (half a > year, a year, whatever) and see if it would be able to end up in a > stable release. If so, welcome back in unstable. A total removal from Debian will not help fixing issues or find solutions, and keeping it in Experimental sounds like a much much better solution to me. I will upload a new version to Experimental soon. Cheers, Thomas Goirand (zigo) -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
