Neil McGovern wrote: > On Mon, Apr 01, 2013 at 02:38:51PM +0300, Uoti Urpala wrote: > > It is unreasonable to tell the users and upstreams that Debian is > > going to keep users on a known inferior version by default for a long > > time, just in case more testing is needed to discover problems in the > > release version (often in addition to multiple already discovered > > problems that Debian is intentionally leaving for users to suffer > > from, as the most natural way to fix them would be to update to a > > newer upstream version). > > > > You may consider it most natural, the rest of the project values > stability and not introducing untested new features.
I think you misunderstood that as saying I wanted to change packages in stable; the above was from the perspective of unstable (the natural way to fix known issues in unstable would be to upload a new upstream version). I do not believe there is any project-wide consensus to avoid newer versions in unstable. > Perhaps you may > feel more at home in a different distribution which aligns with your > priorities more. I think unstable works reasonably well outside release problems (there are sometimes issues with new enough packages not being available, but I think those are mostly due to activity of individual maintainers, not project priorities). And I don't believe it to be a shared view of all Debian maintainers that only stable releases matter, and users of unstable are only tools to use to polish stable. Nor do I believe that all other users of unstable are only trying to help create stable releases for others to use, intentionally sacrificing their own experience to do so. And whatever distro I personally choose, as upstream of packaged software I certainly do not approve of Debian leaving its upstable users at a known inferior version during long release freezes. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1364827693.1928.122.camel@glyph.nonexistent.invalid
