Hi all
Currently, Squeeze is the most error-prone build (mostly thanks to
Squeeze's terrible support for rubygems, but also the ancient version
of ruby itself) and yet according to our webstats, accounts for only
2% of the downloaded Debian packages (0.1k out of 4.7k downloads). In
addition, the Debian package workload has increased thanks to the
release of Ubuntu 14.04, and I'd like to get back down to supporting 3
OSes again.
As such, I'd like to propose dropping Squeeze support for 1.6.
However, I'm happy to hear concerns before I make the changes in the
CI infrastructure.
In particular, I'm open to the idea of keeping the smart-proxy
available for 1.6. This is because, generally, DNS/DHCP/TFTP servers
are far harder to upgrade than a dedicated Foreman box. Ideally, I'll
drop the whole Squeeze package set, but if enough people convince me
otherwise, we could keep the proxy for that reason. Other concerns are
welcome too - fire away 
Greg
As an addendum, it's worth noting that official Squeeze support ended
on May 31st 2014, and the LTS Squeeze support is being handled by
volunteers:
https://www.debian.org/News/2014/20140424
To be clear, everything Debian releases is being handled by
volunteers. The LTS thing, is a new support feature Debian is trying
to be somewhat in line with Enterprise expectations. (And presumably
other distros that have LTS support ranging from 5-13 years.)
Although it is a separate team maintaining LTS, there is some overlap
in the team members of both.
I personally support efforts by Linux distros to have support
lifecycles in the 5+ year range, as that largely ties in with
Enterprise HW support.
I'm also curious does this also mean RedHat Enterprise Linux 5.x and
6.x users need to upgrade their foreman servers, since they were
released before Debian Squeeze?
Thanks,
Brian
···
On Mon, Jul 7, 2014 at 6:44 AM, Greg Sutcliffe wrote:
> As an addendum, it's worth noting that official Squeeze support ended
> on May 31st 2014, and the LTS Squeeze support is being handled by
> volunteers:
>
> https://www.debian.org/News/2014/20140424
> To be clear, everything Debian releases is being handled by
> volunteers. The LTS thing, is a new support feature Debian is trying
> to be somewhat in line with Enterprise expectations. (And presumably
> other distros that have LTS support ranging from 5-13 years.)
A fair point, I merely raise it since it reads like Debian (as an
organisation) trying to distance themselves from Squeeze support.
> Although it is a separate team maintaining LTS, there is some overlap
> in the team members of both.
>
> I personally support efforts by Linux distros to have support
> lifecycles in the 5+ year range, as that largely ties in with
> Enterprise HW support.
I'd love to continue supporting it, it's not my intention to disrupt
people. But I have limited free time (and it's still pretty much just
me doing the debs), so I have to rationalize where is best to spend
that time. 2% of the user base for 20% of my time is not a good
tradeoff.
As stated, I'm also open to the option of keeping the simpler packages
such as the proxy around a bit longer, since they tend to run on
servers with a longer lifecycle.
> I'm also curious does this also mean RedHat Enterprise Linux 5.x and
> 6.x users need to upgrade their foreman servers, since they were
> released before Debian Squeeze?
I don't handle the RPMs so I cannot make a definitive statement.
However, we haven't provided EL5 packages for some time, so I assume
users of that distro have already updated, or are comfortable with
their current setup.
Greg
···
On 7 July 2014 18:37, Brian Gupta wrote:
I'd say "drop it", simply because of that 2% user base, but please keep the
foreman-proxy package.
It's not hard to migrate a foreman server, especially when keeping the same
foreman version, but it can be downright impossible to upgrade a larger DNS
or what have you, just as you stated.
And I believe that if given the choice between you spending 20% of whatever
amount of time you can give on "packaging for the 2%" vs "doing anything
else", that choice would be "anything else" every time, even for 90% of
that 2%.
And since you always keep the current and the previous major releases
around, no one can claim being dropped like a hot potato just for using
squeeze, or whatever people could conceivably come up with for feeling
"ignored" as a result.
That 2% vs 20% and the state of ruby on Squeeze (which I can not believe
will be effected by LTS's existence) says it all, I think - maybe some
people wont be overjoyed, but I don't think there is anyone who wouldn't
understand.
···
On Tuesday, July 8, 2014 12:19:21 PM UTC+2, Greg Sutcliffe wrote:
>
> On 7 July 2014 18:37, Brian Gupta <brian...@brandorr.com > > wrote:
> > To be clear, everything Debian releases is being handled by
> > volunteers. The LTS thing, is a new support feature Debian is trying
> > to be somewhat in line with Enterprise expectations. (And presumably
> > other distros that have LTS support ranging from 5-13 years.)
>
> A fair point, I merely raise it since it reads like Debian (as an
> organisation) trying to distance themselves from Squeeze support.
>
> > Although it is a separate team maintaining LTS, there is some overlap
> > in the team members of both.
> >
> > I personally support efforts by Linux distros to have support
> > lifecycles in the 5+ year range, as that largely ties in with
> > Enterprise HW support.
>
> I'd love to continue supporting it, it's not my intention to disrupt
> people. But I have limited free time (and it's still pretty much just
> me doing the debs), so I have to rationalize where is best to spend
> that time. 2% of the user base for 20% of my time is not a good
> tradeoff.
>
> As stated, I'm also open to the option of keeping the simpler packages
> such as the proxy around a bit longer, since they tend to run on
> servers with a longer lifecycle.
>
>> To be clear, everything Debian releases is being handled by
>> volunteers. The LTS thing, is a new support feature Debian is trying
>> to be somewhat in line with Enterprise expectations. (And presumably
>> other distros that have LTS support ranging from 5-13 years.)
>
> A fair point, I merely raise it since it reads like Debian (as an
> organisation) trying to distance themselves from Squeeze support.
>
>> Although it is a separate team maintaining LTS, there is some overlap
>> in the team members of both.
>>
>> I personally support efforts by Linux distros to have support
>> lifecycles in the 5+ year range, as that largely ties in with
>> Enterprise HW support.
>
> I'd love to continue supporting it, it's not my intention to disrupt
> people. But I have limited free time (and it's still pretty much just
> me doing the debs), so I have to rationalize where is best to spend
> that time. 2% of the user base for 20% of my time is not a good
> tradeoff.
I am talking to a Debian Developer who should have time next week to
see how much work it will take to backport ruby 1.9.3 to squeeze. If
it's not too much work, he's willing to do it as an official
squeeze-backport.
Would this address the challenges you are facing with continued squeeze support?
If not, what other issues are there that make this time consuming?
···
On Tue, Jul 8, 2014 at 6:19 AM, Greg Sutcliffe wrote:
> On 7 July 2014 18:37, Brian Gupta wrote:
As stated, I’m also open to the option of keeping the simpler packages
such as the proxy around a bit longer, since they tend to run on
servers with a longer lifecycle.
I’m also curious does this also mean RedHat Enterprise Linux 5.x and
6.x users need to upgrade their foreman servers, since they were
released before Debian Squeeze?
I don’t handle the RPMs so I cannot make a definitive statement.
However, we haven’t provided EL5 packages for some time, so I assume
users of that distro have already updated, or are comfortable with
their current setup.
Greg
–
You received this message because you are subscribed to the Google Groups “Foreman users” group.
To unsubscribe from this group and stop receiving emails from it, send an email to foreman-users+unsubscribe@googlegroups.com.
To post to this group, send email to foreman-users@googlegroups.com.
Visit this group at http://groups.google.com/group/foreman-users.
For more options, visit https://groups.google.com/d/optout.
Partially. That would address the forced requirement to drop any
1.8.7-based distro when Foreman moves to 1.9.3 only (which will happen
fairly soon, I feel - more and more gems are 1.9 only now). That will
also be a problem from Ubuntu 12.04 (which ships a known-buggy version
of 1.9.3) but thats a different discussion.
However, it doesn't address the problems with rubygems compatibility
and bundler on Squeeze - the vast majority of build failures come from
bundler errors. We also have more gems to build for Squeeze as they're
not packaged, and many of those builds have to have their tests
disabled as they fail on Squeeze. That's always initially time
consuming when new gems are required by the installer or the new
modular proxy (core vendors it's gems via bundler), but also has an
impact on the confidence we can have in those packages.
In addition to the technical reasons above, and the small number of
users; I mentioned at the start of the thread that I've gone from
maintaining 3 deb OSs to 4 with the addition of Trusty Tahr 14.04. I'd
like to reduce that back to 3, since I already have limited time. I'm
re-iterating this just in case you missed it in the original post, I
have nothing new to say on the matter
Squeeze is now 3.5 years old, has always had issues with ruby support,
and Wheezy has been available for over a year as a stable upgrade
path. I had planned to drop Squeeze when it reached it's official EOL
(May 31st 2014) anyway - this mail was more to check if my 2% figure
was broadly correct (i.e. if a large number of people voiced concern,
then clearly my figuers are wrong). So far, I don't think I am wrong.
As Simon points out, I'll not be deleting the existing Squeeze repo,
and I'll do "best effort" to package anything that gets backported to
Foreman 1.5 in there too. For 1.6 however, I think it's time to drop
it.
Greg
···
On 10 July 2014 19:01, Brian Gupta wrote:
> Would this address the challenges you are facing with continued squeeze support?
In another discussion, one possible solution has presented itself
which I think may be workable.
Currently the packaging constructs for all the Debian packages are in
a single repo[1] - I'd be quite happy to take pull requests from
concerned members of the community to allow them to continue working.
I'm always happy to have more collaborators on the Debian packages
This would entail marking the Squeeze builds as allowed-to-fail in our
Jenkins infrastructure - otherwise other things could get held up.
Interested people would probably want to subscribe to the RSS feed for
the Squeeze jobs instead, to get a head's up on issues. There is also
some proactivity needed around the nightlies to ensure a new release
works correctly, but I'd be happy to advise if anyone wants to take it
on.
That would free me from dealing with Squeeze to spend my time on the
other distros, and also potentially increase community involvement -
sounds like win/win, assuming anyone wants the job
It's also worth noting that the current nightlies appear to work fine
on Squeeze, so barring major changes in the core, it's likely 1.6
could be released for Squeeze anyway, with us stepping away from it
for 1.7. That gives a good few months to see if there's any more
activity on this thread before we make a decision.
Greg
> a single repo[1]
Whoops!
[1] https://github.com/theforeman/foreman-packaging - deb/* branches
