Re: [Oneiric-Topic] SRU Process
On Thursday, March 31, 2011 01:45:21 PM Chuck Short wrote: > On Wed, 30 Mar 2011 11:25:44 -0400 > > Etienne Goyer wrote: > > On 11-03-30 11:05 AM, Scott Kitterman wrote: > > > On Wednesday, March 30, 2011 10:40:36 AM Chuck Short wrote: > > >> Hi, > > >> > > >> I do not have the statistics in front of me, but I believe most of > > >> users are using LTS releases of Ubuntu. The policy of cherrypicking > > >> fixes from the development releases does not scale in my opinon. We > > >> should offer PPAs for users who want to use a new version of for > > >> example Apache. Or go through the list of packages we support and > > >> see if we can get it to qualify as a micro release update. > > > > > > We can also do a lot of this through backports. We are very close > > > to having the backports only install packages that users explicitly > > > request from backports (just waiting on an LP change that's in > > > progress), so it will be much safer to use going forward. > > > > The mechanism itself is really only half the question. I am more > > interested in the level of commitment we are willing to make in > > keeping certain key software "fresh" in LTS. Whether we deliver > > these in backports, PPA or some other mechanism is really just an > > implementation detail, IMHO. > > Right when I brought this up, I was more interested in the burden of > tracking down the fixes in upstream code, backporing the fix, and > asking for user testing. If you look at: > > http://people.canonical.com/~chucks/SRUTracker/sru-tracker-bugs.html > > We have a lot of requests for SRU bug fixes which takes time to > fix. Depending on the workload that what have, we do what we can. > > From the systems administrator perspective if they want to use newer > versions of apache, mysql, etc then great they can use backports/ppa. > If they want to be a more cautious then they can still use the > *-updates pocket. Its really all about choice in this case. The one thing I'm not allowed to do in Backports is use it as a substitute for the SRU process (I know no one has suggested that, just trying to be clear). Scott K -- ubuntu-server mailing list ubuntu-server@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-server More info: https://wiki.ubuntu.com/ServerTeam
Re: [Oneiric-Topic] SRU Process
On Wed, 30 Mar 2011 11:25:44 -0400 Etienne Goyer wrote: > On 11-03-30 11:05 AM, Scott Kitterman wrote: > > On Wednesday, March 30, 2011 10:40:36 AM Chuck Short wrote: > >> Hi, > >> > >> I do not have the statistics in front of me, but I believe most of > >> users are using LTS releases of Ubuntu. The policy of cherrypicking > >> fixes from the development releases does not scale in my opinon. We > >> should offer PPAs for users who want to use a new version of for > >> example Apache. Or go through the list of packages we support and > >> see if we can get it to qualify as a micro release update. > > > > We can also do a lot of this through backports. We are very close > > to having the backports only install packages that users explicitly > > request from backports (just waiting on an LP change that's in > > progress), so it will be much safer to use going forward. > > The mechanism itself is really only half the question. I am more > interested in the level of commitment we are willing to make in > keeping certain key software "fresh" in LTS. Whether we deliver > these in backports, PPA or some other mechanism is really just an > implementation detail, IMHO. > > Right when I brought this up, I was more interested in the burden of tracking down the fixes in upstream code, backporing the fix, and asking for user testing. If you look at: http://people.canonical.com/~chucks/SRUTracker/sru-tracker-bugs.html We have a lot of requests for SRU bug fixes which takes time to fix. Depending on the workload that what have, we do what we can. >From the systems administrator perspective if they want to use newer versions of apache, mysql, etc then great they can use backports/ppa. If they want to be a more cautious then they can still use the *-updates pocket. Its really all about choice in this case. chuck -- ubuntu-server mailing list ubuntu-server@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-server More info: https://wiki.ubuntu.com/ServerTeam
Re: [Oneiric-Topic] SRU Process
On 11-03-30 11:38 AM, Marc Deslauriers wrote: > On the other hand, it doesn't make sense to break everyone's servers > every month when we update the apache or php version and the config > files/features/ABI change and their applications stop working. This is > the type of thing that enterprises dread...and is why IE6 took so long > to die... The use-case I have in mind is people deploying LTS now to found out there is a bug in a package important to them that has been fixed in a later release. If the bug is not SRU-worthy, their options boils down to 1. run a non-LTS release of Ubuntu to benefit from the bug fix, or 2. use an unsupported/unmaintained version of the buggy package (backport, PPA, compiled from source, whatever). Agreed that Apache is not such a good example here. -- Etienne Goyer Technical Account Manager - Canonical Ltd Ubuntu Certified Instructor -LPIC-3 ~= Ubuntu: Linux for Human Beings =~ -- ubuntu-server mailing list ubuntu-server@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-server More info: https://wiki.ubuntu.com/ServerTeam
Re: [Oneiric-Topic] SRU Process
On Thursday, March 31, 2011 11:02:11 AM Clint Byrum wrote: > Excerpts from Scott Kitterman's message of Wed Mar 30 08:31:15 -0700 2011: > > https://help.ubuntu.com/community/UbuntuBackports > > > > It's driven by user request and testing. In the case of packages with > > rdepends we require testing of those as well (sometimes rdepends need to > > be backported as well) so we don't leave users with a broken system. A > > reasonably large fraction of users enable backports, so we need to be > > careful (you should have seenthe flurry of bug reports when I did a > > backport that broke Flash). > > > > Once we have not-automatic fully deployed we might be able to reconsider > > this. > > > > Backports are a purely community driven process, so we're always looking > > for more help. > > Scott, I think it may be worth arguing for a bit more of the > Canonical-Employed server team members' time if backports achieves the > level of usability that seems very close. I think it would certainly > make upstreams happier too if instead of cherrypicking medium priority > fixes into -updates, we just put critical fixes in -updates and pointed > anyone wanting those nit-pick bugs fixed at backports. That's exactly the model we'd like to have. More contribution is, of course, welcome. I would really like to minimize the amount of out of archive stuff our users need to get their needs met. Backports is, IMO, an important part of this. Scott K -- ubuntu-server mailing list ubuntu-server@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-server More info: https://wiki.ubuntu.com/ServerTeam
Re: [Oneiric-Topic] SRU Process
Excerpts from Scott Kitterman's message of Wed Mar 30 08:31:15 -0700 2011: > > https://help.ubuntu.com/community/UbuntuBackports > > It's driven by user request and testing. In the case of packages with > rdepends we require testing of those as well (sometimes rdepends need to be > backported as well) so we don't leave users with a broken system. A > reasonably large fraction of users enable backports, so we need to be careful > (you should have seenthe flurry of bug reports when I did a backport that > broke Flash). > > Once we have not-automatic fully deployed we might be able to reconsider this. > > Backports are a purely community driven process, so we're always looking for > more help. Scott, I think it may be worth arguing for a bit more of the Canonical-Employed server team members' time if backports achieves the level of usability that seems very close. I think it would certainly make upstreams happier too if instead of cherrypicking medium priority fixes into -updates, we just put critical fixes in -updates and pointed anyone wanting those nit-pick bugs fixed at backports. -- ubuntu-server mailing list ubuntu-server@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-server More info: https://wiki.ubuntu.com/ServerTeam
Re: [Oneiric-Topic] SRU Process
On 03/30/2011 04:40 PM, Chuck Short wrote: > Hi, > > I do not have the statistics in front of me, but I believe most of > users are using LTS releases of Ubuntu. Here are the stats from the latest server survey: 10.10 (8) 1793 33.17% 10.04 LTS (7) 2880 53.28% 9.10 (6) 461 8.53% 9.04 (5) 306 5.66% 8.10 (4) 121 2.24% 8.04LTS (3) 854 15.80% 6.06LTS (1) 104 1.92% Which confirms you point: 71% of our user base is on an LTS. > The policy of cherrypicking > fixes from the development releases does not scale in my opinon. We > should offer PPAs for users who want to use a new version of for > example Apache. Or go through the list of packages we support and see > if we can get it to qualify as a micro release update. Strongly agree on this point if we focus on stable release for a list of specified packages (defining this list should be our first task). I would suggest that our commitment should be the same as for point releases: for the list of packages, stable releases would be made available until the next LTS, on PPA per stable release. The PPA usage would, I think, ensure that people do not upgrade to a major new version without knowing it. Nick signature.asc Description: OpenPGP digital signature -- ubuntu-server mailing list ubuntu-server@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-server More info: https://wiki.ubuntu.com/ServerTeam
Re: [Oneiric-Topic] SRU Process
On Wed, 30 Mar 2011 11:38:14 -0400 Marc Deslauriers wrote: > On Wed, 2011-03-30 at 11:00 -0400, Etienne Goyer wrote: > > On 11-03-30 10:40 AM, Chuck Short wrote: > > > I do not have the statistics in front of me, but I believe most of > > > users are using LTS releases of Ubuntu. The policy of > > > cherrypicking fixes from the development releases does not scale > > > in my opinon. We should offer PPAs for users who want to use a > > > new version of for example Apache. Or go through the list of > > > packages we support and see if we can get it to qualify as a > > > micro release update. > > > > Agreed. Some mechanism to "modularize" the distribution is in > > order. From an end-user perspective, it does no make any sense that > > you need to upgrade the OS to run a new version of Apache. I > > understand why we are doing this from the distribution perspective, > > and I know a lot of people are very attached to the way things are > > being done now, but it really baffles people coming to Ubuntu from > > other platforms at time. > > On the other hand, it doesn't make sense to break everyone's servers > every month when we update the apache or php version and the config > files/features/ABI change and their applications stop working. This is > the type of thing that enterprises dread...and is why IE6 took so long > to die... > > Most people in enterprise scenarios that I've seen who use stuff like > Apache on other platforms tend to install the latest version once, and > stick with that version for the life of the server once it goes into > production...foregoing any security updates. In fact, the constant > update of Apache to remain secure on Windows is one of the reasons > I've seen listed in security audits that recommend either migrating > to IIS, which remains at the same version throughout the life of the > OS, but gets constant security updates, or switching to Linux to > benefit from stable release security updates. > > Apache may be a bad example here for the type of application that > should get updated instead of fixed, as it is not something that is > stand-alone enough and updating it would have a great impact on > Ubuntu use in enterprise environments. > > Besides backports, there is also a process to obtain micro-release > exceptions. Unfortunately, upstream projects who don't change > ABI/config files/features with new versions are the exception and the > massive QA effort to test upgrading them in stable releases would be > orders of magnitude bigger than backporting a patch to fix a specific > issue with a specific test case. > > Marc. > > > Hi Marc, I agree with the points that you brought up and software such as Mysql and Apache are probably not a good idea for such a process because of their history. However I just wanted to put into people's minds that users do want to this. Like your experience in the past I would just install a server and leave it alone. But there is times where I wish the distro developers would have version X rather than version Y. As developers we have to make sure that we are making the best choice of backporting the packages that users want. chuck -- ubuntu-server mailing list ubuntu-server@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-server More info: https://wiki.ubuntu.com/ServerTeam
Re: [Oneiric-Topic] SRU Process
On Wed, 2011-03-30 at 11:00 -0400, Etienne Goyer wrote: > On 11-03-30 10:40 AM, Chuck Short wrote: > > I do not have the statistics in front of me, but I believe most of > > users are using LTS releases of Ubuntu. The policy of cherrypicking > > fixes from the development releases does not scale in my opinon. We > > should offer PPAs for users who want to use a new version of for > > example Apache. Or go through the list of packages we support and see > > if we can get it to qualify as a micro release update. > > Agreed. Some mechanism to "modularize" the distribution is in order. > From an end-user perspective, it does no make any sense that you need to > upgrade the OS to run a new version of Apache. I understand why we are > doing this from the distribution perspective, and I know a lot of people > are very attached to the way things are being done now, but it really > baffles people coming to Ubuntu from other platforms at time. On the other hand, it doesn't make sense to break everyone's servers every month when we update the apache or php version and the config files/features/ABI change and their applications stop working. This is the type of thing that enterprises dread...and is why IE6 took so long to die... Most people in enterprise scenarios that I've seen who use stuff like Apache on other platforms tend to install the latest version once, and stick with that version for the life of the server once it goes into production...foregoing any security updates. In fact, the constant update of Apache to remain secure on Windows is one of the reasons I've seen listed in security audits that recommend either migrating to IIS, which remains at the same version throughout the life of the OS, but gets constant security updates, or switching to Linux to benefit from stable release security updates. Apache may be a bad example here for the type of application that should get updated instead of fixed, as it is not something that is stand-alone enough and updating it would have a great impact on Ubuntu use in enterprise environments. Besides backports, there is also a process to obtain micro-release exceptions. Unfortunately, upstream projects who don't change ABI/config files/features with new versions are the exception and the massive QA effort to test upgrading them in stable releases would be orders of magnitude bigger than backporting a patch to fix a specific issue with a specific test case. Marc. -- ubuntu-server mailing list ubuntu-server@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-server More info: https://wiki.ubuntu.com/ServerTeam
Re: [Oneiric-Topic] SRU Process
On Wednesday, March 30, 2011 11:18:00 AM Douglas Stanley wrote: > On Wed, Mar 30, 2011 at 11:05 AM, Scott Kitterman wrote: > > On Wednesday, March 30, 2011 10:40:36 AM Chuck Short wrote: > >> Hi, > >> > >> I do not have the statistics in front of me, but I believe most of > >> users are using LTS releases of Ubuntu. The policy of cherrypicking > >> fixes from the development releases does not scale in my opinon. We > >> should offer PPAs for users who want to use a new version of for > >> example Apache. Or go through the list of packages we support and see > >> if we can get it to qualify as a micro release update. > > > > We can also do a lot of this through backports. We are very close to > > having the backports only install packages that users explicitly request > > from backports (just waiting on an LP change that's in progress), so it > > will be much safer to use going forward. > > > > Scott K > > This is something I've wanted for a while. I know backports exist, but > they're usually pretty limited. I'd really like to see more things > backported. Like the previous poster stated, there's no reason to > upgrade the entire OS if all we want is say a newer apache or nginx or > puppetmaster, etc. > > How are packages being selected for backports currently? Here is the current documentation. It's been awhile since I reviewed it, but I think it's ~up to date. https://help.ubuntu.com/community/UbuntuBackports It's driven by user request and testing. In the case of packages with rdepends we require testing of those as well (sometimes rdepends need to be backported as well) so we don't leave users with a broken system. A reasonably large fraction of users enable backports, so we need to be careful (you should have seenthe flurry of bug reports when I did a backport that broke Flash). Once we have not-automatic fully deployed we might be able to reconsider this. Backports are a purely community driven process, so we're always looking for more help. Scott K -- ubuntu-server mailing list ubuntu-server@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-server More info: https://wiki.ubuntu.com/ServerTeam
Re: [Oneiric-Topic] SRU Process
On 11-03-30 11:05 AM, Scott Kitterman wrote: > On Wednesday, March 30, 2011 10:40:36 AM Chuck Short wrote: >> Hi, >> >> I do not have the statistics in front of me, but I believe most of >> users are using LTS releases of Ubuntu. The policy of cherrypicking >> fixes from the development releases does not scale in my opinon. We >> should offer PPAs for users who want to use a new version of for >> example Apache. Or go through the list of packages we support and see >> if we can get it to qualify as a micro release update. > > We can also do a lot of this through backports. We are very close to having > the backports only install packages that users explicitly request from > backports (just waiting on an LP change that's in progress), so it will be > much safer to use going forward. The mechanism itself is really only half the question. I am more interested in the level of commitment we are willing to make in keeping certain key software "fresh" in LTS. Whether we deliver these in backports, PPA or some other mechanism is really just an implementation detail, IMHO. -- Etienne Goyer Technical Account Manager - Canonical Ltd Ubuntu Certified Instructor -LPIC-3 ~= Ubuntu: Linux for Human Beings =~ -- ubuntu-server mailing list ubuntu-server@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-server More info: https://wiki.ubuntu.com/ServerTeam
Re: [Oneiric-Topic] SRU Process
On Wed, Mar 30, 2011 at 11:05 AM, Scott Kitterman wrote: > On Wednesday, March 30, 2011 10:40:36 AM Chuck Short wrote: >> Hi, >> >> I do not have the statistics in front of me, but I believe most of >> users are using LTS releases of Ubuntu. The policy of cherrypicking >> fixes from the development releases does not scale in my opinon. We >> should offer PPAs for users who want to use a new version of for >> example Apache. Or go through the list of packages we support and see >> if we can get it to qualify as a micro release update. > > We can also do a lot of this through backports. We are very close to having > the backports only install packages that users explicitly request from > backports (just waiting on an LP change that's in progress), so it will be > much safer to use going forward. > > Scott K > This is something I've wanted for a while. I know backports exist, but they're usually pretty limited. I'd really like to see more things backported. Like the previous poster stated, there's no reason to upgrade the entire OS if all we want is say a newer apache or nginx or puppetmaster, etc. How are packages being selected for backports currently? Doug > -- > ubuntu-server mailing list > ubuntu-server@lists.ubuntu.com > https://lists.ubuntu.com/mailman/listinfo/ubuntu-server > More info: https://wiki.ubuntu.com/ServerTeam > -- Please avoid sending me Word or PowerPoint attachments. See http://www.gnu.org/philosophy/no-word-attachments.html -- ubuntu-server mailing list ubuntu-server@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-server More info: https://wiki.ubuntu.com/ServerTeam
Re: [Oneiric-Topic] SRU Process
On Wednesday, March 30, 2011 10:40:36 AM Chuck Short wrote: > Hi, > > I do not have the statistics in front of me, but I believe most of > users are using LTS releases of Ubuntu. The policy of cherrypicking > fixes from the development releases does not scale in my opinon. We > should offer PPAs for users who want to use a new version of for > example Apache. Or go through the list of packages we support and see > if we can get it to qualify as a micro release update. We can also do a lot of this through backports. We are very close to having the backports only install packages that users explicitly request from backports (just waiting on an LP change that's in progress), so it will be much safer to use going forward. Scott K -- ubuntu-server mailing list ubuntu-server@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-server More info: https://wiki.ubuntu.com/ServerTeam
Re: [Oneiric-Topic] SRU Process
On 11-03-30 10:40 AM, Chuck Short wrote: > I do not have the statistics in front of me, but I believe most of > users are using LTS releases of Ubuntu. The policy of cherrypicking > fixes from the development releases does not scale in my opinon. We > should offer PPAs for users who want to use a new version of for > example Apache. Or go through the list of packages we support and see > if we can get it to qualify as a micro release update. Agreed. Some mechanism to "modularize" the distribution is in order. >From an end-user perspective, it does no make any sense that you need to upgrade the OS to run a new version of Apache. I understand why we are doing this from the distribution perspective, and I know a lot of people are very attached to the way things are being done now, but it really baffles people coming to Ubuntu from other platforms at time. mdz blogged about this a while ago: http://mdzlog.alcor.net/2010/07/06/weve-packaged-all-of-the-free-software-what-now/ Decoupling certain key software from the distribution so that it does not have to be upgraded in lockstep would be a start. I would really like to discuss that at the UDS; count me in. -- Etienne Goyer Technical Account Manager - Canonical Ltd Ubuntu Certified Instructor -LPIC-3 ~= Ubuntu: Linux for Human Beings =~ -- ubuntu-server mailing list ubuntu-server@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-server More info: https://wiki.ubuntu.com/ServerTeam
