For how long we should continue supporting squeeze/oldstable?

[myhro]

I was testing a fix for this problem with backports syntax in squeeze/oldstable that I reported on #96 and got a CalledProcessError: Command 'chroot /target/5e231a2a/root grub-install /dev/dm-0' returned non-zero exit status 1. Before trying to investigate this problem with grub-install, I started to ask myself for how long we will be worrying in providing fixes for this release.

The official support for squeeze/oldstable ended on last May 31st. Probably isn't news for anyone, but its Long Term Support (LTS) was announced to last until Feb/2016, which is a little bit more than 18 months ahead. I see that makes sense for us to support it, as squeeze-lts targets exactly the same two architectures that we do, amd64 and i386, but is there a real need for that? To me, looks like that the public that this LTS support targets is not the "cloud public" that we do.

I would like to hear not only what Anders has to say about this, but also James (@JamesBromberger), Jimmy (@jkaplowitz), Olivier (@osallou) and Tomasz (@rybaktomasz) - and, of course, everyone else who would be interested in the matter.

Ps.: maybe I should also ask this on debian-cloud mailing list?

[andsens]

Yup. I think that is a matter for the mailing list.

[myhro]

I've sent an e-mail to there a few minutes ago.

[myhro]

I guess it is up to us, Anders. Looks like 6.0.x images are still being built for EC2. Maybe it's time to fix those bugs regarding oldstable and add squeeze-lts to its sources.

[andsens]

Agreed. Supporting squeeze until LTS ends (02/2016) is quite a challenge. But I think with automated testing etc. we will be ok. Is squeeze-lts an actual release-target?

[myhro]

Is squeeze-lts an actual release-target?

Yes it is. You have to add the squeeze-lts entry, otherwise you won't get any LTS updates.

[JamesBromberger]

On 21/07/2014 1:05 AM, Tiago Ilieve wrote:

I guess it is up to us, Anders. Looks like |6.0.x| images are still
being built for EC2
https://lists.debian.org/debian-cloud/2014/07/msg00037.html. Maybe
it's time to fix those bugs regarding |oldstable| and add
|squeeze-lts| to its sources.

Our goal is to support the last point release of every major release if
possible starting from Squeeze. So IMHO we I think we should updated to
LTS support for Squeeze; patches welcome. :)

/Mobile:/ +61 422 166 708, /Email:/ james_AT_rcpt.to

[andsens]

@myhro can you open a new issue to track the error you reported in the first message and close this issue? The verdict is that we support squeeze until LTS runs out, if only through a tagged version which we know works (and maybe patch here and there, shouldn't be too hard).

[myhro]

@myhro can you open a new issue to track the error you reported in the first message and close this issue?

Yes I can. I'll soon test this again and fill a proper issue.

(...) if only through a tagged version which we know works (and maybe patch here and there, shouldn't be too hard).

I guess this can lead to some sort of confusion, mostly because of the master branch being the source for the Debian package. If we maintain it on a separate branch/tag, patches from development that breaks the squeeze compatibility merged onto master would bring new bugs to the package, affecting its stability regarding oldstable.

[andsens]

mostly because of the master branch being the source for the Debian package

This is the source of the problem. I think once we have released 1.0, there should be a 1.x branch where we'll put all backwards compatible changes that don't break the API (i.e. manifest semantics).

For me master means latest stable, for the 1.0.0 release I'm sure we will have oldstable compatibility, but it would suck to have to keep maintaining that compatibility at all costs. If we make some changes that break compatibility it should go into 2.0.0 which in my mind would be master until the version is tagged.

[myhro]

Oh, nevermind... I made a confusion about which branch is being used to build the Debian package: it's v0.9.0, not master (they just point to the same commit tn this moment). Sorry about that.

[myhro]

Yes I can. I'll soon test this again and fill a proper issue.

Anders, I was testing this again and noticed that the changes introduced by 89a74a3 also breaks the squeeze installation, raising an E: Unable to locate package linux-headers-amd64 error. Supporting it is becoming harder and harder. :-(

[andsens]

Yup, once we get testing up and running it should get simpler though. Right now I am fighting with getting remote building to work -- paramiko is a PITA when you want do do SSH reverse tunneling. I am switching to twisted conch now, hopefully this will help with getting things done in a more speedy manner.

[myhro]

I'm closing this issue, as the decision has already been made.