[opensuse-buildservice] End Of Life: SUSE Linux 10.1 and Fedora 6
Hi, due to the fill rate of 80% on our storage, end of Life of the distributions and mirror admins complains about the size of our content, we will remove the following base distros and all repositories building against them: * SUSE Linux 10.1 * SUSE Linux 10.0 * Fedora Core & Extras 6 In case you want to mirror them for your own build service, this is your last chance :) bye adrian -- Adrian Schroeter SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg) email: adrian@suse.de --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org
Adrian Schröter wrote:
due to the fill rate of 80% on our storage, end of Life of the distributions and mirror admins complains about the size of our content, we will remove the following base distros and all repositories building against them:
* SUSE Linux 10.1
10.1 still has four weeks left until we stop recording security issues for it. cu Ludwig -- (o_ Ludwig Nussel //\ V_/_ http://www.suse.de/ SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nuernberg) --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org
On Tue, Apr 15, 2008 at 01:25:55PM +0200, Adrian Schröter wrote:
due to the fill rate of 80% on our storage, end of Life of the distributions and mirror admins complains about the size of our content, we will remove the following base distros and all repositories building against them:
* SUSE Linux 10.1 * SUSE Linux 10.0 * Fedora Core & Extras 6
In case you want to mirror them for your own build service, this is your last chance :)
Please, don't do such things without advanced notice. Don't remove 10.1 (which is still a maintained product!) without giving people time to adjust. For example, I'll need to switch several of our servers to repositories based on 10.1 to repositories based on SLE10. In some cases, I'll first have to make sure that a SLE10 source exists for those repositories. this means that I'll have to get the respective admins to change that for their projects, and hope that SLE10 will be suitable as build target. So could you please give a timeline? Thanks, Peter -- "WARNING: This bug is visible to non-employees. Please be respectful!" SUSE LINUX Products GmbH Research & Development
Hello,
due to the fill rate of 80% on our storage, end of Life of the distributions and mirror admins complains about the size of our content, we will remove the following base distros and all repositories building against them:
* SUSE Linux 10.1
This is 2 years old. Could we agree, that a server life cycle should be something about 5 years?
* SUSE Linux 10.0 * Fedora Core & Extras 6
Nearly the same for these.
In case you want to mirror them for your own build service, this is your last chance :)
Instead of deleting the still used distributions and forcing everyone to replace existing installations again and again, how about getting bigger harddisks? Example: SUSE 10.1 is the newest one to get for Strato V-Servers. We had this discussion a year ago and the situation did not change. A lot of root servers do not provide current suse releases, but only older ones. Removing these again in BuildService makes the whole BuildService concept somewhat useless. What do you want: - Provide a widely used BuildService - Provide a user community openSUSE:Factory building system Please define the project goals and make a clear decision about the supported targets. This 5 minute before the end notices are not acceptable for anyone using the BuildService in a more commercial sense. I switched to BuildService to allow customers to have easier installation of some packages. When you stop providing the repositories after such short times, the use of BuildService is limited to the Linux enthusiasts, as nearly everybody else uses older distributions. Ciao -- http://www.dstoecker.eu/ (PGP key available) --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org
On Tuesday 15 April 2008 14:01:38 wrote Dirk Stoecker:
Hello,
due to the fill rate of 80% on our storage, end of Life of the distributions and mirror admins complains about the size of our content, we will remove the following base distros and all repositories building against them:
* SUSE Linux 10.1
This is 2 years old. Could we agree, that a server life cycle should be something about 5 years?
if there is someone, who wants to do maintenance for SL 10.1, I am fine with that. But in the past, no one wanted to do it.
* SUSE Linux 10.0 * Fedora Core & Extras 6
Nearly the same for these.
In case you want to mirror them for your own build service, this is your last chance :)
Instead of deleting the still used distributions and forcing everyone to replace existing installations again and again, how about getting bigger harddisks?
Example: SUSE 10.1 is the newest one to get for Strato V-Servers.
We had this discussion a year ago and the situation did not change. A lot of root servers do not provide current suse releases, but only older ones. Removing these again in BuildService makes the whole BuildService concept somewhat useless.
This not true, we doubled already the hard disc size and run out of space again. On the other side, our mirrors are not able to handle it anymore, while random people simply add several Gigabytes to their projects without thinking. Therefore we will enforce this a bit more via quotas in the future.
What do you want: - Provide a widely used BuildService - Provide a user community openSUSE:Factory building system
Please define the project goals and make a clear decision about the supported targets. This 5 minute before the end notices are not acceptable for anyone using the BuildService in a more commercial sense.
no one said five minutes. But when you want to copy it for your own instances, you should do it now.
I switched to BuildService to allow customers to have easier installation of some packages. When you stop providing the repositories after such short times, the use of BuildService is limited to the Linux enthusiasts, as nearly everybody else uses older distributions.
In that case we would have a way bigger problem beyond the build service, because that means that all these instances are vulnerable and no one is caring about the security of their systems. -- Adrian Schroeter SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg) email: adrian@suse.de --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org
On Tue, 15 Apr 2008, Adrian Schröter wrote:
due to the fill rate of 80% on our storage, end of Life of the distributions and mirror admins complains about the size of our content, we will remove the following base distros and all repositories building against them:
* SUSE Linux 10.1
This is 2 years old. Could we agree, that a server life cycle should be something about 5 years?
if there is someone, who wants to do maintenance for SL 10.1, I am fine with that. But in the past, no one wanted to do it.
That has nothing to do with maintenance. Nobody talked about updating the distibution.
We had this discussion a year ago and the situation did not change. A lot of root servers do not provide current suse releases, but only older ones. Removing these again in BuildService makes the whole BuildService concept somewhat useless.
This not true, we doubled already the hard disc size and run out of space again. On the other side, our mirrors are not able to handle it anymore, while random people simply add several Gigabytes to their projects without thinking. Therefore we will enforce this a bit more via quotas in the future.
Then what about not mirroring older parts? That solves the problem with mirrors. BTW: Lots of newer stuff doesn't even build for the older distributions and is usually disabled. And I have nothing against quotas.
Please define the project goals and make a clear decision about the supported targets. This 5 minute before the end notices are not acceptable for anyone using the BuildService in a more commercial sense.
no one said five minutes. But when you want to copy it for your own instances, you should do it now.
Well, I did not talk about own instances. I started using BuildService and building all the geodesy stuff I do to have a stable reference for the packages. I started to spread the links to the BuildService download spaces. Now they get removed faster than anyone could expect and you tell me to go back to the old method of building the stuff for myself. Now what's the advantage of BuildService then?
I switched to BuildService to allow customers to have easier installation of some packages. When you stop providing the repositories after such short times, the use of BuildService is limited to the Linux enthusiasts, as nearly everybody else uses older distributions.
In that case we would have a way bigger problem beyond the build service, because that means that all these instances are vulnerable and no one is caring about the security of their systems.
Agreed. But this is nothing YOU (or I) can change! There are still SUSE 6 installations out there. I know of running RedHat pre-Fedora installations. And BTW there are still Win 3.1 installations. And there is a big difference between a 2-5 year old distibution we are talking about and the 1-15 year old stuff in the wild. I do not even want to convince you to support these. But 5 years is like a must. I cannot tell our customers to resetup their servers now and then. Instead of buying stuff from us they would go elsewhere. So the questions is, can BuildService provide the support packages or do I need to go back to the old method of providing all this support stuff ourselves. P.S. Could you stop to send each email twice? Or reconfigure the mailinglist to detect CC's. Ciao -- http://www.dstoecker.eu/ (PGP key available)
On Tuesday 15 April 2008 14:26:50 wrote Dirk Stoecker:
On Tue, 15 Apr 2008, Adrian Schröter wrote:
due to the fill rate of 80% on our storage, end of Life of the distributions and mirror admins complains about the size of our content, we will remove the following base distros and all repositories building against them:
* SUSE Linux 10.1
This is 2 years old. Could we agree, that a server life cycle should be something about 5 years?
if there is someone, who wants to do maintenance for SL 10.1, I am fine with that. But in the past, no one wanted to do it.
That has nothing to do with maintenance. Nobody talked about updating the distibution.
The policy is to remove all traces of that one to show the users that it does not exist anymore. Also the main ftp repo will go away, so even when you build something, it might not be installable, because of lack of the main ftp repo.
We had this discussion a year ago and the situation did not change. A lot of root servers do not provide current suse releases, but only older ones. Removing these again in BuildService makes the whole BuildService concept somewhat useless.
This not true, we doubled already the hard disc size and run out of space again. On the other side, our mirrors are not able to handle it anymore, while random people simply add several Gigabytes to their projects without thinking. Therefore we will enforce this a bit more via quotas in the future.
Then what about not mirroring older parts? That solves the problem with mirrors.
that is an approach which does exist already.
BTW: Lots of newer stuff doesn't even build for the older distributions and is usually disabled.
And I have nothing against quotas.
Please define the project goals and make a clear decision about the supported targets. This 5 minute before the end notices are not acceptable for anyone using the BuildService in a more commercial sense.
no one said five minutes. But when you want to copy it for your own instances, you should do it now.
Well, I did not talk about own instances. I started using BuildService and building all the geodesy stuff I do to have a stable reference for the packages. I started to spread the links to the BuildService download spaces. Now they get removed faster than anyone could expect and you tell me to go back to the old method of building the stuff for myself. Now what's the advantage of BuildService then?
sorry, but that is not a serious question. Supported distros are still there and if you need to build for older ones you can still do so on your own systems. This was the intention of the initial mail. If you do not like that openSUSE has only a 2 years life time, it would be better to discuss this on -project. But you should have some suggestion how to achieve this, since it is plenty of work ...
I switched to BuildService to allow customers to have easier installation of some packages. When you stop providing the repositories after such short times, the use of BuildService is limited to the Linux enthusiasts, as nearly everybody else uses older distributions.
In that case we would have a way bigger problem beyond the build service, because that means that all these instances are vulnerable and no one is caring about the security of their systems.
Agreed.
But this is nothing YOU (or I) can change!
There are still SUSE 6 installations out there. I know of running RedHat pre-Fedora installations. And BTW there are still Win 3.1 installations. And there is a big difference between a 2-5 year old distibution we are talking about and the 1-15 year old stuff in the wild. I do not even want to convince you to support these. But 5 years is like a must.
as said before, you should discuss this on -project. We do just follow the official rules.
I cannot tell our customers to resetup their servers now and then. Instead of buying stuff from us they would go elsewhere. So the questions is, can BuildService provide the support packages or do I need to go back to the old method of providing all this support stuff ourselves.
P.S. Could you stop to send each email twice? Or reconfigure the mailinglist to detect CC's.
Ciao
-- Adrian Schroeter SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg) email: adrian@suse.de --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org
This whole thread brings back a point I've been trying to make for a year now. The point, openSUSE should not bother itself with LTS(long term support) for 3 (4 if SLE counted) distributions. I say starting with 11.0 provide only support and fixes until 11.1 then only support 11.1 until 11.2, then 11.2 until 11.3 then give 11.3 a full three years support bringing us around to 12.3. This would make it clear that the other versions are truly community and that to get the 5 years a server should have a person needs to subscribe to SLE. This should not offend SUSE customers and it should please and even entice non-enterprise subscribers to look more closely at SLE. -- James Tremblay aka, SLEducator Director of Technology Newmarket School District Newmarket NH 03857 http://en.opensuse.org/education "Let's maker a difference!" Registered Linux user #440182 CNE 3,4,5 CLP 9 CLE in training ;) --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org
On Tue, 15 Apr 2008, James Tremblay wrote:
This whole thread brings back a point I've been trying to make for a year now. The point, openSUSE should not bother itself with LTS(long term support) for 3 (4 if SLE counted) distributions. I say starting
2 years is "Long Term" for you? In which world do you live? Actually what you suggest is to force people to upgrade to a buggy system each time it is released. This is evil. Until now it always has been fact, that releases x.0 x.1 have had lots of problems and x.2 and x.3 have been really usable. I don't think this will change in the future (especially when I see the changes in Factory). The problem here is, that everybody assumes a server really needs to be up-to-date always. E.g. why should a internal CVS/SVN server be updated at all. The remote vulnerabilities are nearly zero. But maybe I want an current SVN running there, but not update the server every 6 months with lots of hours downtime. Ciao -- http://www.dstoecker.eu/ (PGP key available) --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org
Hello,
The policy is to remove all traces of that one to show the users that it does not exist anymore. Also the main ftp repo will go away, so even when you build something, it might not be installable, because of lack of the main ftp repo.
Bad policy.
sorry, but that is not a serious question. Supported distros are still there and if you need to build for older ones you can still do so on your own systems. This was the intention of the initial mail.
Well, and you know, there is a big difference between managing some packages and setting up and managing an own buildservice.
If you do not like that openSUSE has only a 2 years life time, it would be better to discuss this on -project. But you should have some suggestion how to achieve this, since it is plenty of work ...
Well, SUSE openess has become much better since the pre openSUSE days, but the day when an outsider can influence the way the distribution is handled has still to come. So any discussion there is useless from the beginning. Ciao -- http://www.dstoecker.eu/ (PGP key available) --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org
* Dirk Stoecker
Hello,
The policy is to remove all traces of that one to show the users that it does not exist anymore. Also the main ftp repo will go away, so even when you build something, it might not be installable, because of lack of the main ftp repo.
Bad policy.
I tend to agree. Disk space is getting cheaper every day. So what prevents us from just leaving the 10.1 repository untouched after the official maintenance period ends ? Klaus --- SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg) --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org
On Tue, Apr 15, 2008 at 03:53:41PM +0200, Klaus Kaempf wrote:
* Dirk Stoecker
[Apr 15. 2008 15:41]: Hello,
The policy is to remove all traces of that one to show the users that it does not exist anymore. Also the main ftp repo will go away, so even when you build something, it might not be installable, because of lack of the main ftp repo.
Bad policy.
I tend to agree.
Disk space is getting cheaper every day. So what prevents us from just leaving the 10.1 repository untouched after the official maintenance period ends ?
Indeed. Adrian, do you remember the concept I circulated on a way to handle important content (which needs to be mirrored) and less important content (which doesn't need to be mirrored) about a year ago? Care to resurrect that? Peter -- "WARNING: This bug is visible to non-employees. Please be respectful!" SUSE LINUX Products GmbH Research & Development
On Tuesday 15 April 2008 16:26:43 wrote Dr. Peter Poeml:
On Tue, Apr 15, 2008 at 03:53:41PM +0200, Klaus Kaempf wrote:
* Dirk Stoecker
[Apr 15. 2008 15:41]: Hello,
The policy is to remove all traces of that one to show the users that it does not exist anymore. Also the main ftp repo will go away, so even when you build something, it might not be installable, because of lack of the main ftp repo.
Bad policy.
I tend to agree.
Disk space is getting cheaper every day. So what prevents us from just leaving the 10.1 repository untouched after the official maintenance period ends ?
Indeed.
Adrian, do you remember the concept I circulated on a way to handle important content (which needs to be mirrored) and less important content (which doesn't need to be mirrored) about a year ago?
Care to resurrect that?
The point is that we do not want to support not supported distrubtions. This a global policy. I you do not like it please discuss it on -project. If people do stand up and say they are maintaining it, we can get it back. But in the past no one wanted to do that. As long this is the status quo, there is no need to discuss any other mirror mechanism IMHO. -- Adrian Schroeter SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg) email: adrian@suse.de --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org
* Adrian Schröter
The point is that we do not want to support not supported distrubtions. This a global policy.
I think we should differentiate between - supported and - available for download/build I do not see anyone asking for ongoing support and maintenance. But I do see requests for availability. Klaus --- SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg) --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org
On Tue, Apr 15, 2008 at 04:48:54PM +0200, Klaus Kaempf wrote:
* Adrian Schröter
[Apr 15. 2008 16:42]: The point is that we do not want to support not supported distrubtions. This a global policy.
I think we should differentiate between - supported and - available for download/build
I do not see anyone asking for ongoing support and maintenance. But I do see requests for availability.
I was just about to ask the same. I don't see the interconnection between keeping a distro to build on, and a commitment to maintain it, that you postulate. Peter -- "WARNING: This bug is visible to non-employees. Please be respectful!" SUSE LINUX Products GmbH Research & Development
On Tuesday 15 April 2008 16:48:54 wrote Klaus Kaempf:
* Adrian Schröter
[Apr 15. 2008 16:42]: The point is that we do not want to support not supported distrubtions. This a global policy.
I think we should differentiate between - supported and - available for download/build
I do not see anyone asking for ongoing support and maintenance. But I do see requests for availability.
Than please start the discussion about that on -project. -- Adrian Schroeter SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg) email: adrian@suse.de --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org
* Adrian Schröter
On Tuesday 15 April 2008 16:48:54 wrote Klaus Kaempf:
* Adrian Schröter
[Apr 15. 2008 16:42]: The point is that we do not want to support not supported distrubtions. This a global policy.
I think we should differentiate between - supported and - available for download/build
I do not see anyone asking for ongoing support and maintenance. But I do see requests for availability.
Than please start the discussion about that on -project.
Will do. Klaus --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org
Op Tuesday 15 April 2008 16:48:54 schreef Klaus Kaempf:
I do not see anyone asking for ongoing support and maintenance. But I do see requests for availability.
Like the version's kept here: ftp://ftp.gwdg.de/pub/linux/suse/discontinued/i386 -- Richard Bos Without a home the journey is endless --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org
On Tue, Apr 15, 2008 at 04:42:37PM +0200, Adrian Schröter wrote:
On Tuesday 15 April 2008 16:26:43 wrote Dr. Peter Poeml:
On Tue, Apr 15, 2008 at 03:53:41PM +0200, Klaus Kaempf wrote:
* Dirk Stoecker
[Apr 15. 2008 15:41]: Hello,
The policy is to remove all traces of that one to show the users that it does not exist anymore. Also the main ftp repo will go away, so even when you build something, it might not be installable, because of lack of the main ftp repo.
Bad policy.
I tend to agree.
Disk space is getting cheaper every day. So what prevents us from just leaving the 10.1 repository untouched after the official maintenance period ends ?
Indeed.
Adrian, do you remember the concept I circulated on a way to handle important content (which needs to be mirrored) and less important content (which doesn't need to be mirrored) about a year ago?
Care to resurrect that?
The point is that we do not want to support not supported distrubtions. This a global policy. I you do not like it please discuss it on -project. If people do stand up and say they are maintaining it, we can get it back. But in the past no one wanted to do that.
If I may remind you, the proposal is completely generic, and has nothing to do with end of life or maintenance issues. It is based on the observation that only ca. a third of our content is "relevant", and the other two thirds not. It has the potential to drastically reduce our disk needs on our central servers. Which at the same time makes room for other interesting things. Peter -- "WARNING: This bug is visible to non-employees. Please be respectful!" SUSE LINUX Products GmbH Research & Development
On Tue, 15 Apr 2008, Adrian Schröter wrote:
The point is that we do not want to support not supported distrubtions. This a global policy. I you do not like it please discuss it on -project. If people do stand up and say they are maintaining it, we can get it back. But in the past no one wanted to do that.
Has there really ever been a discussion about that in the correct way? This means seperating between the two major topics "support" and "supply". Actually the buildservice and the stuff therein is a way of support of older distributions. New packages for older distributions aren't only new. Usually they fix bugs and vulnerabilities as well. And the Novell responsibility for this is only the "supply"-part and not "support". If the policy is to drop any reference to old distributions, what about a new domain unsupported.opensuse.org delivering this old stuff. This way everybody would notice it is unsupported and in switching the install targets also agrees explicitely to this state. And please don't redirect me to -project. Won't have any sense. If a real discussion should be done it must be started and done by Novell members. And please, please stall the project removal until such a discussion has been held. The Buildservice already includes other distributions, where Novell does not do any support. Why can't it include older Novell distributions without Novell support? Ciao -- http://www.dstoecker.eu/ (PGP key available)
On Tuesday 15 April 2008 16:57:59 wrote Dirk Stoecker:
On Tue, 15 Apr 2008, Adrian Schröter wrote:
The point is that we do not want to support not supported distrubtions. This a global policy. I you do not like it please discuss it on -project. If people do stand up and say they are maintaining it, we can get it back. But in the past no one wanted to do that.
Has there really ever been a discussion about that in the correct way? This means seperating between the two major topics "support" and "supply".
Actually the buildservice and the stuff therein is a way of support of older distributions. New packages for older distributions aren't only new. Usually they fix bugs and vulnerabilities as well. And the Novell responsibility for this is only the "supply"-part and not "support".
If the policy is to drop any reference to old distributions, what about a new domain unsupported.opensuse.org delivering this old stuff. This way everybody would notice it is unsupported and in switching the install targets also agrees explicitely to this state.
This is a possibility yes, but it does not exist yet. mls reminded me meanwhile that we accutually wanted to move the base projects in the OBS below "DISCONTINUED:" namespace, but remove the repos building against the original one.
And please don't redirect me to -project. Won't have any sense. If a real discussion should be done it must be started and done by Novell members.
well, we as a build service will not work against the opensuse.org rules. So, if you want to change this, you need to go there.
And please, please stall the project removal until such a discussion has been held.
The Buildservice already includes other distributions, where Novell does not do any support. Why can't it include older Novell distributions without Novell support?
You say there are some base distros missing in my list ? ;) -- Adrian Schroeter SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg) email: adrian@suse.de --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org
On Tue, Apr 15, 2008 at 03:17:54PM +0200, Adrian Schröter wrote:
Then what about not mirroring older parts? That solves the problem with mirrors.
that is an approach which does exist already.
No. Peter -- "WARNING: This bug is visible to non-employees. Please be respectful!" SUSE LINUX Products GmbH Research & Development
On Tue, Apr 15, 2008 at 02:01:38PM +0200, Dirk Stoecker wrote:
* SUSE Linux 10.1
This is 2 years old. Could we agree, that a server life cycle should be something about 5 years?
Unfortunately, I'm forced to upgrade my (private) servers to 10.3 even... which will live only one more good year, before it's ditched. The SLE10 target might help...
Instead of deleting the still used distributions and forcing everyone to replace existing installations again and again, how about getting bigger harddisks?
I was thinking it was one of the advantages of the buildservice that it could make it possible to still build software for older products...
Example: SUSE 10.1 is the newest one to get for Strato V-Servers.
Indeed, I'm telling this product management all the time... We shouldn't try to "force" ISPs at the expense of our users.
We had this discussion a year ago and the situation did not change. A lot of root servers do not provide current suse releases, but only older ones. Removing these again in BuildService makes the whole BuildService concept somewhat useless.
What do you want: - Provide a widely used BuildService - Provide a user community openSUSE:Factory building system
Please define the project goals and make a clear decision about the supported targets. This 5 minute before the end notices are not acceptable for anyone using the BuildService in a more commercial sense.
Exactly. Those "I'll remove xy now" is not acceptable to the community. It makes the whole thing unpredictable, and makes it appear to be lead in an arbitrary fashion. I would like to see such things driven more by consensus. Thanks, Peter -- "WARNING: This bug is visible to non-employees. Please be respectful!" SUSE LINUX Products GmbH Research & Development
On Tue, Apr 15, 2008 at 02:01:38PM +0200, Dirk Stoecker wrote:
* SUSE Linux 10.1
Well, I have some hardware which simply refused to work under anything newer than 10.0 . That already drove me crazy for days and days. The minimum for such an announcement would be a timeline and enough warning in advance. You still did not tell the timeframe we are talking about. 10.0 is end of live. Ok. Removing 10.1. Nah. Nevertheless: Removing the base distribution for 10.0 I consider doing the wrong thing. As long as my tools build against a distribution users should be able to access and use it. I must admit, I thought that was what the build service was designed for: Providing a platform for volunteers to improve the software installation experience for their (und therefore YOUR) users.
This is 2 years old. Could we agree, that a server life cycle should be something about 5 years?
Unfortunately, I'm forced to upgrade my (private) servers to 10.3 even... which will live only one more good year, before it's ditched.
The SLE10 target might help...
Instead of deleting the still used distributions and forcing everyone to replace existing installations again and again, how about getting bigger harddisks?
I was thinking it was one of the advantages of the buildservice that it could make it possible to still build software for older products...
Yes! That's why I'm here and not compiling on different local machines, real or virtual (as I did before). The build service is great for providing rpms for old OS releases not found on my machines anymore.
Please define the project goals and make a clear decision about the supported targets. This 5 minute before the end notices are not acceptable for anyone using the BuildService in a more commercial sense.
Exactly. Those "I'll remove xy now" is not acceptable to the community.
Exactly. Not only for commercial use. I spread the *opensuse.org adress to download rpms for the cummunity project I support in the believe to overcome exactly the problem of saving old versions. If you switch to "current release and factory"-mode the buildservice uses lots of potential for my way of using it. I guess I'm not alone.
It makes the whole thing unpredictable, and makes it appear to be lead in an arbitrary fashion.
And the last thing most people need is unpredictability. The build service is a fantastic project, giving real value to the linux world. Don't spoil it, please. May be it's enough to stop mirroring (but keeping!) end-of-live products plus introducing some kind of quota system? Detlef
I would like to see such things driven more by consensus.
Thanks, Peter -- "WARNING: This bug is visible to non-employees. Please be respectful!"
SUSE LINUX Products GmbH Research & Development
To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org
On Tuesday 15 April 2008 16:31:54 wrote Detlef Steuer:
On Tue, Apr 15, 2008 at 02:01:38PM +0200, Dirk Stoecker wrote:
* SUSE Linux 10.1
Well, I have some hardware which simply refused to work under anything newer than 10.0 . That already drove me crazy for days and days.
The minimum for such an announcement would be a timeline and enough warning in advance. You still did not tell the timeframe we are talking about.
10.0 is end of live. Ok. Removing 10.1. Nah.
10.1 will not get removed before it is end of live. But this is near. So take this as an heads up and copy the content, in case you want to keep it.
Nevertheless: Removing the base distribution for 10.0 I consider doing the wrong thing. As long as my tools build against a distribution users should be able to access and use it. I must admit, I thought that was what the build service was designed for: Providing a platform for volunteers to improve the software installation experience for their (und therefore YOUR) users.
and it still does that. But it is no Auto-fix-all-my-security-problems tool. And please keep in mind that to redesign security patches for old software can be quite some work. This is really not a build service question, but a general openSUSE question. You can discuss here to promote software with known security holes, but it will not have much effect... And let me say this again, it is complete okay to keep it, when you find people who want to maintain it here. Last time I asked, no one stand up. bye adrian -- Adrian Schroeter SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg) email: adrian@suse.de --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org
On Tue, Apr 15, 2008 at 04:31:54PM +0200, Detlef Steuer wrote:
May be it's enough to stop mirroring (but keeping!) end-of-live products plus introducing some kind of quota system?
I see two aspects here, one is diskspace on download.opensuse.org, another is diskspace on the mirrors. The former is a decision done elsewhere, let's see what opensuse-project thinks about it, the suggestion to move the discussion there is a good idea. The latter is something that we easily can take care about, with a little bit of preparation. I just gathered some data. What they show is the following: - 10.1 distro usage: It is not downloaded in any significant amount, we can definitely remove it from all rsync modules right now (or rather move into a separate "discontinued" rsync module so it is actually still available). We actually could have done so earlier, and even though no mirror so far complained about the size of those rsync modules, it is always good to keep them small because in the end it might enable more mirrors. - 10.1 BS repositories usage: The popular repos (KDE:, server:, OpenOffice.org, and others) are all accessed with about 1 req/s. The overall average traffic generated looks like only 25 K/s. It should nicely work to exclude all those from the rsync modules, thereby shrinking them and removing them from the mirrors, without impact on our download infrastructure. [Overall request rate for BS repos is 80 req/s, 1 req/s of that is for 10.1 repos if I don't mistake anything.] Maybe this helps in the decision. Peter -- "WARNING: This bug is visible to non-employees. Please be respectful!" SUSE LINUX Products GmbH Research & Development
On Tue, Apr 15, 2008 at 07:07:37PM +0200, Dr. Peter Poeml wrote:
On Tue, Apr 15, 2008 at 04:31:54PM +0200, Detlef Steuer wrote:
May be it's enough to stop mirroring (but keeping!) end-of-live products plus introducing some kind of quota system?
I see two aspects here, one is diskspace on download.opensuse.org, another is diskspace on the mirrors.
The former is a decision done elsewhere, let's see what opensuse-project thinks about it, the suggestion to move the discussion there is a good idea.
The latter is something that we easily can take care about, with a little bit of preparation.
I just gathered some data. What they show is the following:
- 10.1 distro usage: It is not downloaded in any significant amount, we can definitely remove it from all rsync modules right now (or rather move into a separate "discontinued" rsync module so it is actually still available). We actually could have done so earlier, and even though no mirror so far complained about the size of those rsync modules, it is always good to keep them small because in the end it might enable more mirrors.
- 10.1 BS repositories usage: The popular repos (KDE:, server:, OpenOffice.org, and others) are all accessed with about 1 req/s. The overall average traffic generated looks like only 25 K/s. It should nicely work to exclude all those from the rsync modules, thereby shrinking them and removing them from the mirrors, without impact on our download infrastructure. [Overall request rate for BS repos is 80 req/s, 1 req/s of that is for 10.1 repos if I don't mistake anything.]
I gathered some more (build service specific) data, which may be of interest. The following numbers are space occupied on rsync.opensuse.org by repositories matching the following expressions: *Mandriva_2006* 1G *Mandriva_2007* 2G *Mandriva_2008* 2G *Debian* 0.5G *Ubuntu* 1G *Fedora_7* 5G *Fedora_8* 8G *RHEL_4* 0.1G *RHEL_5* 2G *SLES_9* 9G *SLE_10* 31G *10.0* 19G *10.1* 45G *10.2* 73G *10.3* 88G *Factory* 100G TOTAL 393G TOTAL w/o home 223G So, these numbers allow for some interesting insight. However they'll be fully useful together with statistics about downloads, and I'll wait for But I _seriously_ wonder already now, whether we need to have 100G of Factory rpms on the mirrors, which are probably downloaded only by extremely few users. A quick look into the logs indicates that the requests on the 100G Factory packages cause _less_ of traffic for us, as the requests on the 10.1 packages... Peter -- "WARNING: This bug is visible to non-employees. Please be respectful!" SUSE LINUX Products GmbH Research & Development
On Thursday 17 April 2008 15:20:02 wrote Dr. Peter Poeml:
On Tue, Apr 15, 2008 at 07:07:37PM +0200, Dr. Peter Poeml wrote:
On Tue, Apr 15, 2008 at 04:31:54PM +0200, Detlef Steuer wrote:
May be it's enough to stop mirroring (but keeping!) end-of-live products plus introducing some kind of quota system?
I see two aspects here, one is diskspace on download.opensuse.org, another is diskspace on the mirrors.
The former is a decision done elsewhere, let's see what opensuse-project thinks about it, the suggestion to move the discussion there is a good idea.
The latter is something that we easily can take care about, with a little bit of preparation.
I just gathered some data. What they show is the following:
- 10.1 distro usage: It is not downloaded in any significant amount, we can definitely remove it from all rsync modules right now (or rather move into a separate "discontinued" rsync module so it is actually still available). We actually could have done so earlier, and even though no mirror so far complained about the size of those rsync modules, it is always good to keep them small because in the end it might enable more mirrors.
- 10.1 BS repositories usage: The popular repos (KDE:, server:, OpenOffice.org, and others) are all accessed with about 1 req/s. The overall average traffic generated looks like only 25 K/s. It should nicely work to exclude all those from the rsync modules, thereby shrinking them and removing them from the mirrors, without impact on our download infrastructure. [Overall request rate for BS repos is 80 req/s, 1 req/s of that is for 10.1 repos if I don't mistake anything.]
I gathered some more (build service specific) data, which may be of interest. The following numbers are space occupied on rsync.opensuse.org by repositories matching the following expressions:
*Mandriva_2006* 1G *Mandriva_2007* 2G *Mandriva_2008* 2G *Debian* 0.5G *Ubuntu* 1G
*Fedora_7* 5G *Fedora_8* 8G *RHEL_4* 0.1G *RHEL_5* 2G
*SLES_9* 9G *SLE_10* 31G
*10.0* 19G *10.1* 45G *10.2* 73G *10.3* 88G *Factory* 100G
TOTAL 393G TOTAL w/o home 223G
So, these numbers allow for some interesting insight. However they'll be fully useful together with statistics about downloads, and I'll wait for
But I _seriously_ wonder already now, whether we need to have 100G of Factory rpms on the mirrors, which are probably downloaded only by extremely few users.
A quick look into the logs indicates that the requests on the 100G Factory packages cause _less_ of traffic for us, as the requests on the 10.1 packages...
does this include one or both Factory distribution trees itself ? How did you calculate what repodir comes from which project ? -- Adrian Schroeter SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg) email: adrian@suse.de --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org
On Thu, Apr 17, 2008 at 03:56:09PM +0200, Adrian Schröter wrote:
does this include one or both Factory distribution trees itself ?
Directories on rsync.o.o matching "*Factory*". find . -type d -name \*Factory\* -print0 | xargs -0 du -sch |grep total This only excludes repoview directories which aren't mirrored by rsync.o.o.
How did you calculate what repodir comes from which project ?
I didn't. The numbers are project-agnostic. Thinking along the lines of possible cut down on rsync modules for mirror feeding, by excludes that are simple to manage. Peter -- "WARNING: This bug is visible to non-employees. Please be respectful!" SUSE LINUX Products GmbH Research & Development
On Thu, 17 Apr 2008, Dr. Peter Poeml wrote:
I gathered some more (build service specific) data, which may be of interest. The following numbers are space occupied on rsync.opensuse.org by repositories matching the following expressions:
*Mandriva_2006* 1G *Mandriva_2007* 2G *Mandriva_2008* 2G *Debian* 0.5G *Ubuntu* 1G
*Fedora_7* 5G *Fedora_8* 8G *RHEL_4* 0.1G *RHEL_5* 2G
*SLES_9* 9G *SLE_10* 31G
*10.0* 19G *10.1* 45G *10.2* 73G *10.3* 88G *Factory* 100G
TOTAL 393G TOTAL w/o home 223G
So, these numbers allow for some interesting insight. However they'll be fully useful together with statistics about downloads, and I'll wait for
But I _seriously_ wonder already now, whether we need to have 100G of Factory rpms on the mirrors, which are probably downloaded only by extremely few users.
A quick look into the logs indicates that the requests on the 100G Factory packages cause _less_ of traffic for us, as the requests on the 10.1 packages...
Actually I would have expected exactly what your numbers show: - The older the distribution, the less packages are there: Making stuff ready for older distributions gets more and more complicated, the older the distribution is. - Only little use of non SUSE packages. Adapting SUSE packages to work with the other distros makes a lot of work also. - Lots of Factory stuff, as BuildService gets used more often. I also think not mirroring Factory is a good idea. In Application:Geo I (we) use Factory mainly as a testbed. So I step by step fixed compiler bugs and dependencies, so the changes may be included in upstream early and when next release is ready the stuff works from the first day on. I doubt everybody ever really installs the Factory stuff there. The main targets for me are 10.2 and 10.3. For some packages I care for older and really old packages, but for most this is not the case. But these, where I care for old distributions, are these, which I do not want to loose. For the downloads I would expect same distibution except for Factory. Would be nice to see the numbers. When does the BuildService stats work again? It's a long time for debugging it. P.S. And please add "osc wipebinaries" to the Webinterface. That would save space also (a little :-). Ciao -- http://www.dstoecker.eu/ (PGP key available) --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org
On Thu, Apr 17, 2008 at 03:20:02PM +0200, Dr. Peter Poeml wrote: > On Tue, Apr 15, 2008 at 07:07:37PM +0200, Dr. Peter Poeml wrote: > > On Tue, Apr 15, 2008 at 04:31:54PM +0200, Detlef Steuer wrote: > > > May be it's enough to stop mirroring (but keeping!) end-of-live products plus introducing some kind of quota system? [...] > > I just gathered some data. What they show is the following: [...] > > - 10.1 BS repositories usage: > > The popular repos (KDE:, server:, OpenOffice.org, and others) are all > > accessed with about 1 req/s. The overall average traffic generated > > looks like only 25 K/s. It should nicely work to exclude all those > > from the rsync modules, thereby shrinking them and removing them from > > the mirrors, without impact on our download infrastructure. > > [Overall request rate for BS repos is 80 req/s, 1 req/s of that is for > > 10.1 repos if I don't mistake anything.] I worked on the two build service rsync modules last night, and could reduce their size by 50%. buildservice-repos 424G -> 220G buildservice-repos-main 240G -> 122G I basically excluded 10.0, 10.1, Factory, Fedora, RHEL and similar content. Note: The excluded software will still be available on download.opensuse.org as before. It is just not being mirrored anymore, except one or two mirrors. It'll also be available for rsyncing from our rsync servers. Thus, the change shouldn't make a substantial difference in regard to availability. There is more potential -- like debug* and src packages -- but it'll also need some more careful work. I'm still working on cleaning up those mirrors which get a push sync from us. So just in case you encounter any irregularities, I would be very interested to hear from you. But you shouldn't notice anything - as usual. Peter -- "WARNING: This bug is visible to non-employees. Please be respectful!" SUSE LINUX Products GmbH Research & Development
participants (9)
-
Adrian Schröter
-
Detlef Steuer
-
Dirk Stoecker
-
Dr. Peter Poeml
-
James Tremblay
-
Klaus Kaempf
-
Ludwig Nussel
-
Peter Poeml
-
Richard Bos