On Wed, Oct 15, 2014 at 09:44:43PM +0200, Christoph Anton Mitterer wrote: > Well a bug is at least something, where one has a central log of all > discussions... and where one can really keep track of...
Only if people remember to copy it. And that's less likely to happen when you start getting down to the nitty-gritty of changes to actual packages. Those discussions are more likely to happen on more specific bugs. It's also a lousy way of keeping track of the current state of affairs. Just consider the recent mammoth tech-ctte bugs. It must have been a herculean effort for the tech-ctte to keep track of what had been considered and what had not. A wiki page would be a much better way of keeping a summary in place. Something like https://wiki.debian.org/ReproducibleBuilds or https://wiki.debian.org/DebianEdu/Status/Jessie for good examples. > The problem with release goals / DEP is, that there is a lot of talking > but in the end nothing might really happen. The DEP process, at least, has had some thought put into the design to address that issue. > Also, I think that supporting broken algorithms actually *is* a bug :) Well, it's a meta-bug, of sorts; really it isn't a bug itself. There are others, that could be theoretically filed and blocking information between this one and those filed in the BTS. Without that, how would you otherwise consider when this bug is "fixed"? You can't really leverage the excellent versioning features of the BTS with the general package. Another problem with the "general" package is, who is responsible? Are you prepared to take responsibility to close this bug yourself? If it isn't a release goal, there's no push to have it resolved in any particular time frame. It could languish forever. -- Jonathan Dowland -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141015203321.gb1...@chew.redmars.org
