>>>>> "Nikolaus" == Nikolaus Rath <nikol...@rath.org> writes:
Nikolaus> I agree that this is unfortunate, but preserving backwards Nikolaus> compatibility over so many upstream versions just for Nikolaus> Debian wheezy users did not seem worth the time. I totally understand that it's a lot of work and totally get that you might not want to do that work. However, Debian as a project balances stability and upgrade tradeoffs across the project, and this is one of those areas where a project goal may require more work to be put into a package for that package to be suitable for inclusion in a Debian release. No one is obligated to do that work, but Debian's philosophy is generally that if the work to make upgrades work well can't be done, then a package should not be included in releases. If a package is not going to provide an upgrade from one debian release to the next, it should not generally be in the Debian release. It would be fine for it to continue to be in unstable. We need to figure out if someone is willing to commit to doing the necessary work for stretch and if not probably leave s3ql in unstable but pull from stretch and investigate whether it should be pulled from Jessie in a point release. s3ql tends to get used for backups and other things where availability is quite important and saying "oops, you don't get your data when you upgraded," is kind of a big deal. If Debian users can't count on maintaining access to their data after the upgrades, then we probably want to warn them about that up front, and the experience may not be good enough to actually recommend that people store data in s3ql. I understand that as an upstream author you might well want a more rapid deployment cycle than Debian's release process. That's fine. I'm not judging anything here. I'm just saying that if software's going to be in a Debian release it needs to live up to what that means. Nikolaus> Theoretically, it is possible to do all the upgrades in Nikolaus> one step and integrate that into Jessie's s3ql package, Nikolaus> but that would be a major coding effort. Nikolaus> I guess it would have been better to package S3QL 2.x as a Nikolaus> new s3ql2 package instead of it replacing the s3ql Nikolaus> package. But I don't think there is a way to recticify Nikolaus> that now - or is there? But then people still lose their data from wheezy->jessie. So, you talked about it being a lot of work to do the upgrade in one step. Why does that need to happen? Why can't the upgrade be handled in two steps and we just package the necessary parts to do all the steps? How much harder are we talking about than getting the s3qladm and s3ql libraries from the 2.5 version of s3ql into Jessie? -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org