>>>>> "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-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
