[opensuse-project] openSUSE Strategy Discussion: Base for derivatives
Hello again! As we promised earlier[1] starting today we'll be discussing the second of strategies: Base for derivatives[2]. [1] http://news.opensuse.org/2010/06/17/a-strategy-for- the-opensuse-project-proposals-and-discussions/ [2] http://en.opensuse.org/Documents/Strategy/Derivatives ----8<--------8<--------8<--------8<--------8<--------8<---- openSUSE - Base for derivatives ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 1.) Statement: We are a diverse active and inviting community delivering the best foundation for Linux derivatives by providing a high quality, long-term supported core distribution, with tools and infrastructure to easily build on top of it. We encourage projects and developers to create additional building blocks and specialized spin-offs and provide a platform to make them visible and appreciated. The center of this strategy is a high quality and long-term supported core distribution surrounded by tools to build derivatives which includes remote system administration. Behind that we will have a marketing team spreading the word about our Project and the derivatives made with it. Additionally, we will provide derivatives for desktops, server usage, software and web development. To be successful we see the collaboration with upstream and other Linux distributions as a key factor in providing quality derivatives. 2.) Key ideas: * reduce the number of packages in Factory - provide smaller, stable, high quality core distro - provide Long Term Support (LTS) for this reduced set - core suitable for servers - available for more platforms (including ARM, PowerPC, etc.) * provide platform for building derivatives around core distro (onion model) - building blocks - software grouped by theme (Build Service - repositories) - infrastructure for building spinoffs (Build Service - kiwi image build / SUSE Studio) - spin-offs promotion ("gallery" for spin-offs with ratings, download links, etc.) * support diversity - openSUSE as a base for MeeGo, OpenWRT and other projects - desktop spin-offs for users (KDE, GNOME, LXDE, Xfce) - specialized spin-offs like Education, Photo edition 3.) Activities: 3.a.) We need to be excellent in the following: * provide stable core packages with LTS (Factory) * openSUSE Build Service * provide tools for remote system administration * process/mechanism to qualify those custom distribution for usage of openSUSE name/trademark * large testing of various OBS repositories combinations 3.b.) We will try to do the following effectively: * provide the openSUSE distro as it is today (no long term support) * provide environment for web development (webserver/database stack) * provide development tools for C/C++, Java, C#, J, Python, Ruby, ... * collaboration with upstream * collaboration with other Linux distros 3.c.) As project, we will not focus on the following anymore: * There are many packages that exist in Factory and we don't know if they are used or needed. We'll have them in major OBS projects only. -- Best Regards / S pozdravom, Pavol RUSNAK SUSE LINUX, s.r.o openSUSE Boosters Team Lihovarska 1060/12 PGP 0xA6917144 19000 Praha 9 prusnak[at]opensuse.org Czech Republic -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org
On Thursday 2010-06-24 13:58, Pavol Rusnak wrote:
2.) Key ideas:
* reduce the number of packages in Factory - provide smaller, stable, high quality core distro - provide Long Term Support (LTS) for this reduced set - core suitable for servers - available for more platforms (including ARM, PowerPC, etc.) * provide platform for building derivatives around core distro (onion model) - building blocks - software grouped by theme (Build Service - repositories)
I object to this strategy. A few years ago, there were voices that said "but Debian has more packages", now that we have the OBS, the problem still is not really gone. First you would have to add extra repositories, that alone is unacceptible. Having to manually add packman & personal repo already does not scale to well. Already today, we see posts by forum visitors (and/or other communication media) who seem to have utterly many reopsitories just because they think it is cool or something, when in fact, they are on the edge of breaking something in the process, and nobody wants to deal with the "mess" of finding where exactly in those umpteenth repositories the problem comes from. I also am inclined to call this a Windows model, where you spend extra time installing all the non-core stuff. Linux distributions' strengths have always been to have more software agglomerated in a single location. Then, repositories often carry packages also found in others. It raises the problem which to choose.
- infrastructure for building spinoffs (Build Service - kiwi image build / SUSE Studio) - spin-offs promotion ("gallery" for spin-offs with ratings, download links, etc.) * support diversity - openSUSE as a base for MeeGo, OpenWRT and other projects - desktop spin-offs for users (KDE, GNOME, LXDE, Xfce) - specialized spin-offs like Education, Photo edition
openSUSE(:Factory) is the effort that has been put into unification, and the proposed strategy just pulls it apart again. As if the world and its users did not already have enough problems choosing which distribution to use of the many (distrowatch lists 317), this strategy would add another handful. (I certainly don't mind live CDs or installer CDs that carry only part of the packages, but the end result should be that zypper should, out of the box without adding extra repositories, give access to the base repo, that is, /distribution/XY/repo.) Letting the distribution split into spin-offs also causes update headaches. Someday a spin's maintainer ceases to be able to track it all, or wanders of to other interests, you are stuck. No timely updates, and the failing attempt to get the dependency hell right when trying to pull a package that also happens to be included in another spin. Getting together or disbanding oneself. I prefer the former. -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org
Dear Jan,
2.) Key ideas:
* reduce the number of packages in Factory - provide smaller, stable, high quality core distro - provide Long Term Support (LTS) for this reduced set - core suitable for servers - available for more platforms (including ARM, PowerPC, etc.) * provide platform for building derivatives around core distro (onion model) - building blocks - software grouped by theme (Build Service - repositories)
I object to this strategy. A few years ago, there were voices that said "but Debian has more packages", now that we have the OBS, the problem still is not really gone.
First you would have to add extra repositories, that alone is unacceptible. Having to manually add packman & personal repo already does not scale to well.
Already today, we see posts by forum visitors (and/or other communication media) who seem to have utterly many reopsitories just because they think it is cool or something, when in fact, they are on the edge of breaking something in the process, and nobody wants to deal with the "mess" of finding where exactly in those umpteenth repositories the problem comes from.
I also am inclined to call this a Windows model, where you spend extra time installing all the non-core stuff. Linux distributions' strengths have always been to have more software agglomerated in a single location.
Then, repositories often carry packages also found in others. It raises the problem which to choose.
I totally agree on that, but it's a problem we have in general. At our university (and in our German forums), most support cases are related to 3rd party repositories, replacing core packages. One option is not to only display home: repos at software.opensuse.org (are they already hidden? not hitting them very often, now but the advanced search option is checked by default). Another good thing would be something like a rating platform. Greets Marcus -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org
On Thursday 2010-06-24 15:05, Marcus Moeller wrote:
I object to this strategy. A few years ago, there were voices that said "but Debian has more packages", now that we have the OBS, the problem still is not really gone.
First you would have to add extra repositories, that alone is unacceptible. Having to manually add packman & personal repo already does not scale to well.
Already today, we see posts by forum visitors (and/or other communication media) who seem to have utterly many reopsitories just because they think it is cool or something, when in fact, they are on the edge of breaking something in the process, and nobody wants to deal with the "mess" of finding where exactly in those umpteenth repositories the problem comes from.
I also am inclined to call this a Windows model, where you spend extra time installing all the non-core stuff. Linux distributions' strengths have always been to have more software agglomerated in a single location.
Then, repositories often carry packages also found in others. It raises the problem which to choose.
I totally agree on that, but it's a problem we have in general.
It could certainly do better, by integrating. Up on the list is # rpm -qa --qf="%{VENDOR}\t%{NAME}\n" | sort | less obs://build.opensuse.org/science R-base obs://build.opensuse.org/science blas obs://build.opensuse.org/science libblas3 openSUSE-Education latex-pgf openSUSE-Education latex-xcolor openSUSE-Education libenca0 openSUSE-Education liblapack3 openSUSE-Education libinotifytools0 openSUSE-Education python-numpy openSUSE-Education maxima openSUSE-Education maxima-exec-clisp openSUSE-Education wxMaxima obs://build.opensuse.org/Application:Geo gdal obs://build.opensuse.org/Application:Geo libgdal1 obs://build.opensuse.org/Application:Geo libgeos0 obs://build.opensuse.org/Application:Geo libgeotiff1_2 obs://build.opensuse.org/openSUSE:11.2:Contrib poedit The only reasons to fail putting something into Factory (or opensuse in general) is * licensing * preference (colors, layouts, etc) * package-hoarding by maintainer * ..something else too
At our university (and in our German forums), most support cases are related to 3rd party repositories, replacing core packages.
One option is not to only display home: repos at software.opensuse.org (are they already hidden? not hitting them very often, now but the advanced search option is checked by default).
home: is not so much a problem IMO, just a consequence. With more packages migrating to factory, the fewer repos you need. The fewer repos you have, the stronger one is inclined to keep it that way (to not add more). -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org
Hi Jan,
I object to this strategy. A few years ago, there were voices that said "but Debian has more packages", now that we have the OBS, the problem still is not really gone.
First you would have to add extra repositories, that alone is unacceptible. Having to manually add packman & personal repo already does not scale to well.
Already today, we see posts by forum visitors (and/or other communication media) who seem to have utterly many reopsitories just because they think it is cool or something, when in fact, they are on the edge of breaking something in the process, and nobody wants to deal with the "mess" of finding where exactly in those umpteenth repositories the problem comes from.
I also am inclined to call this a Windows model, where you spend extra time installing all the non-core stuff. Linux distributions' strengths have always been to have more software agglomerated in a single location.
Then, repositories often carry packages also found in others. It raises the problem which to choose.
I totally agree on that, but it's a problem we have in general.
It could certainly do better, by integrating. Up on the list is
# rpm -qa --qf="%{VENDOR}\t%{NAME}\n" | sort | less obs://build.opensuse.org/science R-base obs://build.opensuse.org/science blas obs://build.opensuse.org/science libblas3 openSUSE-Education latex-pgf openSUSE-Education latex-xcolor openSUSE-Education libenca0 openSUSE-Education liblapack3 openSUSE-Education libinotifytools0 openSUSE-Education python-numpy openSUSE-Education maxima openSUSE-Education maxima-exec-clisp openSUSE-Education wxMaxima obs://build.opensuse.org/Application:Geo gdal obs://build.opensuse.org/Application:Geo libgdal1 obs://build.opensuse.org/Application:Geo libgeos0 obs://build.opensuse.org/Application:Geo libgeotiff1_2 obs://build.opensuse.org/openSUSE:11.2:Contrib poedit
The only reasons to fail putting something into Factory (or opensuse in general) is
* licensing * preference (colors, layouts, etc) * package-hoarding by maintainer * ..something else too
At our university (and in our German forums), most support cases are related to 3rd party repositories, replacing core packages.
One option is not to only display home: repos at software.opensuse.org (are they already hidden? not hitting them very often, now but the advanced search option is checked by default).
home: is not so much a problem IMO, just a consequence. With more packages migrating to factory, the fewer repos you need. The fewer repos you have, the stronger one is inclined to keep it that way (to not add more).
Okay, got your point. But isn't 'Base for derivatives' heading in the other direction: fewer packages in Factory and more in 3rd party subprojects? Greets Marcus -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org
* Marcus Moeller <mail@marcus-moeller.de> [2010-06-24 15:43]:
home: is not so much a problem IMO, just a consequence. With more packages migrating to factory, the fewer repos you need. The fewer repos you have, the stronger one is inclined to keep it that way (to not add more).
Okay, got your point. But isn't 'Base for derivatives' heading in the other direction: fewer packages in Factory and more in 3rd party subprojects?
Yes, and it doesn't make sense to me. Why not simply create a Factory-LTS branch containing links to a subset of Factory packages which are designated to receive LTS support instead of messing with Factory itself? -- Guido Berhoerster -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org
On Thursday 2010-06-24 16:00, Guido Berhoerster wrote:
* Marcus Moeller <mail@marcus-moeller.de> [2010-06-24 15:43]:
home: is not so much a problem IMO, just a consequence. With more packages migrating to factory, the fewer repos you need. The fewer repos you have, the stronger one is inclined to keep it that way (to not add more).
Okay, got your point. But isn't 'Base for derivatives' heading in the other direction: fewer packages in Factory and more in 3rd party subprojects?
Yes, and it doesn't make sense to me. Why not simply create a Factory-LTS branch containing links to a subset of Factory packages which are designated to receive LTS support instead of messing with Factory itself?
You don't need a specific Factory-LTS branch. openSUSE:11.3:Update already takes the place. You only need to keep it around longer and fill it with updates of packages that belong to that 'core' package set. -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org
On Thursday 2010-06-24 15:42, Marcus Moeller wrote:
home: is not so much a problem IMO, just a consequence. With more packages migrating to factory, the fewer repos you need. The fewer repos you have, the stronger one is inclined to keep it that way (to not add more).
Okay, got your point. But isn't 'Base for derivatives' heading in the other direction: fewer packages in Factory and more in 3rd party subprojects?
Yes, and I can't thus agree with that strategy because of that. More packages in extra repositories means users are likely to make erroneous choices more often when they have to collect all their repos together. -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org
On 24.06.2010 15:05, Marcus Moeller wrote:
At our university (and in our German forums), most support cases are related to 3rd party repositories, replacing core packages.
One option is not to only display home: repos at software.opensuse.org (are they already hidden? not hitting them very often, now but the advanced search option is checked by default).
Yes, they are not shown by default since some days, but can be enabled in the 'search options'. Greetings -- Thomas Schmidt (tom [at] opensuse.org) openSUSE Boosters Team "Don't Panic", Douglas Adams (1952 - 11.05.2001) -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org
2010/6/24 Thomas Schmidt <tom@opensuse.org>:
On 24.06.2010 15:05, Marcus Moeller wrote:
At our university (and in our German forums), most support cases are related to 3rd party repositories, replacing core packages.
One option is not to only display home: repos at software.opensuse.org (are they already hidden? not hitting them very often, now but the advanced search option is checked by default).
Yes, they are not shown by default since some days, but can be enabled in the 'search options'.
Ah, okay. Thanks for the update. -- Greets Marcus -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org
On Thu, 24 Jun 2010 14:39:35 +0200, Jan Engelhardt wrote:
Already today, we see posts by forum visitors (and/or other communication media) who seem to have utterly many reopsitories just because they think it is cool or something,
Actually, one of the biggest reasons I see cited is that many people use one-click install, and they go with the default behaviour, which is to add the repo to the list of repos on the system. I understand there was a fair amount of discussion about what the default should be (though I didn't see it, might've been before I joined the list the discussion took place on) and that the decision was to default to adding the repos. Generally when we start seeing "RPM Hell" in the forums, the point at which we start is to get back to the basics and have the user remove all nonessential repos. That usually resolves the issues well enough that they can get updates. I don't want to get too far off track here - I like the idea of openSUSE being a base for derivative distributions (as it is to some degree already, with SOAD and others), but in order to be successful with this, we need to address this underlying problem of repo management when combined with one-click installs. Maybe the solution is to modify OBS to allow someone to submit packages to a "community" repository that somehow validates that a submitted package doesn't conflict. (Maybe that repo already exists as the Packman repo and a process just needs to be built/clearly documented around getting a contributed package into it? Maybe such a process/ documentation already exists?) Jim -- Jim Henderson Please keep on-topic replies on the list so everyone benefits -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org
On Thursday 2010-06-24 18:26, Jim Henderson wrote:
Maybe the solution is to modify OBS to allow someone to submit packages to a "community" repository
openSUSE:Contrib is there already. Then again, if you have enough guts you could just as well send it to openSUSE:Factory outright.
that somehow validates that a submitted package doesn't conflict. (Maybe that repo already exists as the Packman repo and a process just needs to be built/clearly documented around getting a contributed package into it? Maybe such a process/ documentation already exists?)
http://en.opensuse.org/Build_Service/Collaboration -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org
On Thu, Jun 24, 2010 at 06:52:10PM +0200, Jan Engelhardt wrote:
On Thursday 2010-06-24 18:26, Jim Henderson wrote:
Maybe the solution is to modify OBS to allow someone to submit packages to a "community" repository
openSUSE:Contrib is there already. Then again, if you have enough guts you could just as well send it to openSUSE:Factory outright.
yes, with Factory that open as it is now, Factory is the right way. Ciao, Marcus -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org
On Thu, 24 Jun 2010 19:42:37 +0200, Marcus Meissner wrote:
On Thu, Jun 24, 2010 at 06:52:10PM +0200, Jan Engelhardt wrote:
On Thursday 2010-06-24 18:26, Jim Henderson wrote:
Maybe the solution is to modify OBS to allow someone to submit packages to a "community" repository
openSUSE:Contrib is there already. Then again, if you have enough guts you could just as well send it to openSUSE:Factory outright.
yes, with Factory that open as it is now, Factory is the right way.
I had thought Factory was for "future development" - ie, the basis for the builds that go into the "next release". Am I misunderstanding that? Thanks for the clarification both of you. Jim -- Jim Henderson Please keep on-topic replies on the list so everyone benefits -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org
On Thursday 2010-06-24 20:31, Jim Henderson wrote:
Maybe the solution is to modify OBS to allow someone to submit packages to a "community" repository
openSUSE:Contrib is there already. Then again, if you have enough guts you could just as well send it to openSUSE:Factory outright.
yes, with Factory that open as it is now, Factory is the right way.
I had thought Factory was for "future development" - ie, the basis for the builds that go into the "next release". Am I misunderstanding that?
Is there a problem with that? -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org
On Thu, 24 Jun 2010 20:40:15 +0200, Jan Engelhardt wrote:
On Thursday 2010-06-24 20:31, Jim Henderson wrote:
Maybe the solution is to modify OBS to allow someone to submit packages to a "community" repository
openSUSE:Contrib is there already. Then again, if you have enough guts you could just as well send it to openSUSE:Factory outright.
yes, with Factory that open as it is now, Factory is the right way.
I had thought Factory was for "future development" - ie, the basis for the builds that go into the "next release". Am I misunderstanding that?
Is there a problem with that?
Not a problem so much, but rather if someone's running on the "current" release, having to go to the "experimental" area for a piece of software that isn't in the standard repo seems like overkill. The 'contrib' repo would seem to me to be a better fit. If I'm looking to run brltty (for example - intentionally picked a package I didn't find in OBS at all) on openSUSE 11.2 and someone's contributed it, I wouldn't want to have to sub to a repo that gets me into the development repo for 11.3 - I'd want to stay on 11.2. That's how I'm seeing that. Does that make sense? Jim -- Jim Henderson Please keep on-topic replies on the list so everyone benefits -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org
On Thursday 2010-06-24 20:45, Jim Henderson wrote:
openSUSE:Contrib is there already. Then again, if you have enough guts you could just as well send it to openSUSE:Factory outright.
yes, with Factory that open as it is now, Factory is the right way.
I had thought Factory was for "future development" - ie, the basis for the builds that go into the "next release". Am I misunderstanding that?
Is there a problem with that?
Not a problem so much, but rather if someone's running on the "current" release, having to go to the "experimental" area for a piece of software that isn't in the standard repo seems like overkill.
Well if you took all the "updated" software, and agglomerated them into a new repository, you _would_ have something equivalent to factory. What you _can_ do is add the repo for brltty/openSUSE_11.2, and just live with it until the next release has a brltty recent enough for you. -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org
On Thu, 24 Jun 2010 20:53:14 +0200, Jan Engelhardt wrote:
On Thursday 2010-06-24 20:45, Jim Henderson wrote:
openSUSE:Contrib is there already. Then again, if you have enough guts you could just as well send it to openSUSE:Factory outright.
yes, with Factory that open as it is now, Factory is the right way.
I had thought Factory was for "future development" - ie, the basis for the builds that go into the "next release". Am I misunderstanding that?
Is there a problem with that?
Not a problem so much, but rather if someone's running on the "current" release, having to go to the "experimental" area for a piece of software that isn't in the standard repo seems like overkill.
Well if you took all the "updated" software, and agglomerated them into a new repository, you _would_ have something equivalent to factory.
What you _can_ do is add the repo for brltty/openSUSE_11.2, and just live with it until the next release has a brltty recent enough for you.
That kinda brings us back to the issue of multiple repositories being a problem, though - one of the common forum issues we see is users who have done one-click from a number of individual repos who then run into incompatibilities. It isn't necessarily 'updated' software, but software that's not included. For example, recently it was announced that amarok didn't have a maintainer, so would be dropped from the standard packages. If an unknown packager opted to maintain it, rather than add it back into the oss repo, have it in the contrib repo as something that works with the standard libs installed with 11.2 out of the OSS repo (for example). Jim -- Jim Henderson Please keep on-topic replies on the list so everyone benefits -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org
On Thursday 2010-06-24 21:03, Jim Henderson wrote:
Well if you took all the "updated" software, and agglomerated them into a new repository, you _would_ have something equivalent to factory.
What you _can_ do is add the repo for brltty/openSUSE_11.2, and just live with it until the next release has a brltty recent enough for you.
[...] It isn't necessarily 'updated' software, but software that's not included.
Ok, sounds like a plan. -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org
On Thu, Jun 24, 2010 at 2:45 PM, Jim Henderson <hendersj@gmail.com> wrote:
On Thu, 24 Jun 2010 20:40:15 +0200, Jan Engelhardt wrote:
On Thursday 2010-06-24 20:31, Jim Henderson wrote:
Maybe the solution is to modify OBS to allow someone to submit packages to a "community" repository
openSUSE:Contrib is there already. Then again, if you have enough guts you could just as well send it to openSUSE:Factory outright.
yes, with Factory that open as it is now, Factory is the right way.
I had thought Factory was for "future development" - ie, the basis for the builds that go into the "next release". Am I misunderstanding that?
Is there a problem with that?
Not a problem so much, but rather if someone's running on the "current" release, having to go to the "experimental" area for a piece of software that isn't in the standard repo seems like overkill.
The 'contrib' repo would seem to me to be a better fit. If I'm looking to run brltty (for example - intentionally picked a package I didn't find in OBS at all) on openSUSE 11.2 and someone's contributed it, I wouldn't want to have to sub to a repo that gets me into the development repo for 11.3 - I'd want to stay on 11.2.
That's how I'm seeing that. Does that make sense?
Jim
Contrib is also versioned. We currently have it for 11.2 and factory I believe: http://en.opensuse.org/Package_repositories#Contrib Greg -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org
Contrib is also versioned.
We currently have it for 11.2 and factory I believe:
Good to know, thanks, Greg. Jim -- Jim Henderson Please keep on-topic replies on the list so everyone benefits -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org
On Thu, Jun 24, 2010 at 06:31:53PM +0000, Jim Henderson wrote:
On Thu, 24 Jun 2010 19:42:37 +0200, Marcus Meissner wrote:
On Thu, Jun 24, 2010 at 06:52:10PM +0200, Jan Engelhardt wrote:
On Thursday 2010-06-24 18:26, Jim Henderson wrote:
Maybe the solution is to modify OBS to allow someone to submit packages to a "community" repository
openSUSE:Contrib is there already. Then again, if you have enough guts you could just as well send it to openSUSE:Factory outright.
yes, with Factory that open as it is now, Factory is the right way.
I had thought Factory was for "future development" - ie, the basis for the builds that go into the "next release". Am I misunderstanding that?
Thanks for the clarification both of you.
Yes of course. You can add stuff there for the next product.. Ciao, Marcus -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org
I wonder if we are not simply missing the scope, here. As what I said seems most near this proposal, I post here. To build a strategy, we have to ask what we have to do to make our work better. What do we do well, what do we do bad. I think most of the general goals of an Operating System are already available with the present openSUSE 11.2. So, why change at all? Why an 11.3? This reflexion was led by the fact than on my second computer I still run Windows *XP* So, * why do I run Windows? * Why can I run XP (nearly 10 years old OS, on a 4 years old computer) To have an answer ("I" being not myself, but the average openSUSE user), ask anybody on this list: do you or your family/colleagues run windows, and if yes, why? For me it's very limited: * I (in fact my 90 years old mum) have to read the power point slideshow his relatives send him once a day. Right now openoffice can't completely; * I (that's me) need to syn my GPS/cell phones and openSUSE can't * I need to do video camcorder editing and no present application can do what Magix do in Windows (I would even accept to pay for that the $100 I pay for Magix) - Magix, or Vegas, or Pinnacle studio... That's nearly all. I'm sure that if we didn't so much emphasis on having the very last kde/what so ever, we could have a handfull devs working on these problems and solving them. So "the distribution that make Windows unusefull" would be a good name... this could be 'the base". And this base shouldn't change too often jdd NB: and why can I run XP? because all the hardware vendors still support it -- http://www.dodin.net http://www.facebook.com/pages/I-support-the-Linux-Documentation-Project/3720... http://www.facebook.com/pages/The-fan-page-of-Claire-Dodin/106485119372062?v... -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org
On 06/24/2010 07:42 PM, Marcus Meissner wrote:
On Thu, Jun 24, 2010 at 06:52:10PM +0200, Jan Engelhardt wrote:
On Thursday 2010-06-24 18:26, Jim Henderson wrote:
Maybe the solution is to modify OBS to allow someone to submit packages to a "community" repository
openSUSE:Contrib is there already. Then again, if you have enough guts you could just as well send it to openSUSE:Factory outright.
yes, with Factory that open as it is now, Factory is the right way.
I agree, but we have to come up with the version update policy for some of the Factory packages. Some maintainers are not going to push packages into Factory if they are not allowed to do version updates.
Ciao, Marcus
-- Best Regards / S pozdravom, Pavol RUSNAK SUSE LINUX, s.r.o openSUSE Boosters Team Lihovarska 1060/12 PGP 0xA6917144 19000 Praha 9 prusnak[at]opensuse.org Czech Republic -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org
On Fri, Jun 25, 2010 at 01:44:44PM +0200, Pavol Rusnak wrote:
On 06/24/2010 07:42 PM, Marcus Meissner wrote:
On Thu, Jun 24, 2010 at 06:52:10PM +0200, Jan Engelhardt wrote:
On Thursday 2010-06-24 18:26, Jim Henderson wrote:
Maybe the solution is to modify OBS to allow someone to submit packages to a "community" repository
openSUSE:Contrib is there already. Then again, if you have enough guts you could just as well send it to openSUSE:Factory outright.
yes, with Factory that open as it is now, Factory is the right way.
I agree, but we have to come up with the version update policy for some of the Factory packages. Some maintainers are not going to push packages into Factory if they are not allowed to do version updates.
Well, while this might be a good idea for some packages, it is bad for others. We do not want to lose stability... Ciao, Marcus -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org
On 06/25/2010 01:47 PM, Marcus Meissner wrote:
I agree, but we have to come up with the version update policy for some of the Factory packages. Some maintainers are not going to push packages into Factory if they are not allowed to do version updates.
Well, while this might be a good idea for some packages, it is bad for others.
We do not want to lose stability...
Sure, that's why I wrote "some packages", but the need for such policy is there. I plan to open discussion shortly (on -factory and/or -contrib ML, we'll discuss it there ...) -- Best Regards / S pozdravom, Pavol RUSNAK SUSE LINUX, s.r.o openSUSE Boosters Team Lihovarska 1060/12 PGP 0xA6917144 19000 Praha 9 prusnak[at]opensuse.org Czech Republic -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org
Le 24/06/2010 13:58, Pavol Rusnak a écrit :
of strategies: Base for derivatives[2].
If we can't continue like we did before (and I was still never said why), this is a very good option. The benefits are LTS (Long Term Support) and being a platform for derivatives may bring to us many people. Right now, Debian play this role, but there is none in the rpm part of the linux world. plus, this could be seen (for now, at least) as: Novell and it's man power back the main part and other community groups can focus on derivatives. Don't be overconfident, for some years, the non-Novell openSUSE community will be light (developpers wise). Using this limited power to build derivatives may allow groups structuration and building and the community taking part more and more in the core group. jdd -- http://www.dodin.net http://www.facebook.com/pages/I-support-the-Linux-Documentation-Project/3720... http://www.facebook.com/pages/The-fan-page-of-Claire-Dodin/106485119372062?v... -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org
IMHO this is the worst proposal since it sounds like some ThisUbuntu, ThatUbuntu, ThereUbuntu, HereUbuntu, YouProllyGetItByNowUbuntu. There certainly are some great respins, e.g. the Education one, and it totally should be mandatory to be able to easily create one but this shouldn't be the main "strategy" in any way. On Thursday June 24 2010 13:58:35 Pavol Rusnak wrote:
Hello again!
As we promised earlier[1] starting today we'll be discussing the second of strategies: Base for derivatives[2].
[1] http://news.opensuse.org/2010/06/17/a-strategy-for- the-opensuse-project-proposals-and-discussions/ [2] http://en.opensuse.org/Documents/Strategy/Derivatives
----8<--------8<--------8<--------8<--------8<--------8<----
openSUSE - Base for derivatives ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
1.) Statement:
We are a diverse active and inviting community delivering the best foundation for Linux derivatives by providing a high quality, long-term supported core distribution, with tools and infrastructure to easily build on top of it. We encourage projects and developers to create additional building blocks and specialized spin-offs and provide a platform to make them visible and appreciated.
The center of this strategy is a high quality and long-term supported core distribution surrounded by tools to build derivatives which includes remote system administration. Behind that we will have a marketing team spreading the word about our Project and the derivatives made with it. Additionally, we will provide derivatives for desktops, server usage, software and web development. To be successful we see the collaboration with upstream and other Linux distributions as a key factor in providing quality derivatives.
2.) Key ideas:
* reduce the number of packages in Factory - provide smaller, stable, high quality core distro
If you don't have the man power to maintain the current amount of factory packages there is no way around dropping some.
- provide Long Term Support (LTS) for this reduced set - core suitable for servers
I refuse to comment on that part besides that we already have something that can be used for servers quite easily.
- available for more platforms (including ARM, PowerPC, etc.)
ARM builds would be great for coming tablets but it already has been proven that no one (iirc ~ 0.3%) is interested in PowerPC builds so why start wasting resources on it again (also the amount of ppl trying to fix powerpc for 11.3 / factory is pretty small either)?
* provide platform for building derivatives around core distro (onion model) - building blocks - software grouped by theme (Build Service - repositories) - infrastructure for building spinoffs (Build Service - kiwi image build / SUSE Studio) - spin-offs promotion ("gallery" for spin-offs with ratings, download links, etc.) * support diversity - openSUSE as a base for MeeGo, OpenWRT and other projects - desktop spin-offs for users (KDE, GNOME, LXDE, Xfce) - specialized spin-offs like Education, Photo edition
We have all that already and until you try to sell the same stuff under different names like Ubuntu and KUbuntu (I prolly don't need to tell you what I think about that way) I see no benefits from it compared to simply adding the needed repos. Also, thanks to the branding packages, it is already easy to create a different branded respin.
3.) Activities:
3.a.) We need to be excellent in the following:
* provide stable core packages with LTS (Factory) * openSUSE Build Service * provide tools for remote system administration
Like e.g. "web yast"? Please just stop wasting resources on such stuff since there is more important stuff lacking.
* process/mechanism to qualify those custom distribution for usage of openSUSE name/trademark * large testing of various OBS repositories combinations
No offense, but first open up the testing team like it is planned for quite some months now and then those prolly still will be swamped with testing the current set of packages (and the current 2 repos) so I fail to see how that should effectively work. Also it should be the task of the derivative creators to ensure that the repos they use work.
3.b.) We will try to do the following effectively:
* provide the openSUSE distro as it is today (no long term support)
Makes me wonder where that LTS part from above went then?
* provide environment for web development (webserver/database stack) * provide development tools for C/C++, Java, C#, J, Python, Ruby, ... * collaboration with upstream * collaboration with other Linux distros
That's like the bare minimum which every distribution should do but nothing worth explicitly targeting as "strategy".
3.c.) As project, we will not focus on the following anymore:
* There are many packages that exist in Factory and we don't know if they are used or needed. We'll have them in major OBS projects only.
As said, if you don't have the man power to support the current amount of packages there is no way around dropping some. -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org
On 06/24/2010 03:47 PM, Stephan Kleine wrote:
* reduce the number of packages in Factory - provide smaller, stable, high quality core distro
If you don't have the man power to maintain the current amount of factory packages there is no way around dropping some.
I don't get this comment.
- core suitable for servers
I refuse to comment on that part besides that we already have something that can be used for servers quite easily.
That's a good thing, isn't it?
Like e.g. "web yast"? Please just stop wasting resources on such stuff since there is more important stuff lacking.
AFAIK currently there is no-one outside Novell working on WebYaST and they will continue "wasting resources" on it, because it is a part of Novell's strategy. We (as in openSUSE) can't tell Novell to stop working on that, we can only benefit from it.
3.b.) We will try to do the following effectively:
* provide the openSUSE distro as it is today (no long term support)
Makes me wonder where that LTS part from above went then?
Core will be under LTS, the rest of distro (desktops, applications) will not be. -- Best Regards / S pozdravom, Pavol RUSNAK SUSE LINUX, s.r.o openSUSE Boosters Team Lihovarska 1060/12 PGP 0xA6917144 19000 Praha 9 prusnak[at]opensuse.org Czech Republic -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org
On Thu, 24 Jun 2010 17:30:04 +0200 Pavol Rusnak <prusnak@opensuse.org> wrote:
Core will be under LTS, the rest of distro (desktops, applications) will not be.
Hi My understanding is kernel 2.6.32 is meant to be the current LTS type kernel, eg SLE, RedHat, Ubuntu etc as this has LTS from the kernel developers? Does this mean a regression from the newer kernel in 11.3? -- Cheers Malcolm °¿° (Linux Counter #276890) openSUSE 11.3 RC 1 (i586) Kernel 2.6.34-9-desktop up 1:47, 2 users, load average: 0.03, 0.07, 0.07 ASUS eeePC 1000HE ATOM N280 1.66GHz | GPU Mobile 945GM/GMS/GME -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org
Hello, 2010-06-24 18:06 keltezéssel, Malcolm írta:
On Thu, 24 Jun 2010 17:30:04 +0200 Pavol Rusnak <prusnak@opensuse.org> wrote:
Core will be under LTS, the rest of distro (desktops, applications) will not be.
Hi My understanding is kernel 2.6.32 is meant to be the current LTS type kernel, eg SLE, RedHat, Ubuntu etc as this has LTS from the kernel developers? Does this mean a regression from the newer kernel in 11.3?
RC1 is already out, so I suppose, that the strategy discussion targets 12.0. I don't know, if it would make sense, but I'd create a three tire system for derivatives: - there would be a core distro, which could be easier to port to other architectures (PPC, ARM) and to maintain long term - major derivatives (KDE, GNOME, special interest applications, etc.) would make a second, larger repository (think of contrib, but being larger than core), so it would be still a coherent system, but parts of it lead by different parts of the community - smaller, independent derivatives could stay as OBS projects Bye, CzP -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org
On 06/24/2010 06:45 PM, Peter Czanik wrote:
My understanding is kernel 2.6.32 is meant to be the current LTS type kernel, eg SLE, RedHat, Ubuntu etc as this has LTS from the kernel developers? Does this mean a regression from the newer kernel in 11.3?
RC1 is already out, so I suppose, that the strategy discussion targets 12.0.
The strategy targets project in general, not only distribution. This question is technical, take it to appropriate mailing list (opensuse-kernel@o.o).
I don't know, if it would make sense, but I'd create a three tire system for derivatives: - there would be a core distro, which could be easier to port to other architectures (PPC, ARM) and to maintain long term - major derivatives (KDE, GNOME, special interest applications, etc.) would make a second, larger repository (think of contrib, but being larger than core), so it would be still a coherent system, but parts of it lead by different parts of the community
I think it makes sense and I like it.
- smaller, independent derivatives could stay as OBS projects
-- Best Regards / S pozdravom, Pavol RUSNAK SUSE LINUX, s.r.o openSUSE Boosters Team Lihovarska 1060/12 PGP 0xA6917144 19000 Praha 9 prusnak[at]opensuse.org Czech Republic -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org
On Thu, 24 Jun 2010, Malcolm wrote:
My understanding is kernel 2.6.32 is meant to be the current LTS type kernel, eg SLE, RedHat, Ubuntu etc as this has LTS from the kernel developers? Does this mean a regression from the newer kernel in 11.3?
Both Novell and Red Hat are fully capable of providing LTS for whatever kernel (or other package) they choose for SLE and RHEL, respectively. Ubuntu, I have some serious doubts. What you probably have in mind is the fact some certain upstream kernels receive longer maintenance; these are called -stable (or -sucker) kernels. As implied by the above, though, there is no 1:1 correlation between these and longer term maintenance provided by Enterprise distributions. And, no, openSUSE 11.3 using a more recent kernel than 2.6.32 is not a regression nor a problem; it's the nature of a project like this and brings new and positive changes overall. Gerald -- Dr. Gerald Pfeifer <gp@novell.com> Director Product Management, SUSE Linux Enterprise, openSUSE, Appliances -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org
On Thursday 2010-06-24 15:47, Stephan Kleine wrote:
IMHO this is the worst proposal since it sounds like some ThisUbuntu, ThatUbuntu, ThereUbuntu, HereUbuntu, YouProllyGetItByNowUbuntu.
Sounded to me like ThisUbuntu, ThatMEPIS, ThereCrunchbang, HereDreamlinux, YourSidux :-)
2.) Key ideas:
* reduce the number of packages in Factory - provide smaller, stable, high quality core distro
If you don't have the man power to maintain the current amount of factory packages there is no way around dropping some.
"You" is an overgeneralization here. Quite a bunch of packages exist in factory whose develproject maintainer is not someone who was, or is, working with Novell.
- available for more platforms (including ARM, PowerPC, etc.)
ARM builds would be great for coming tablets but it already has been proven that no one (iirc ~ 0.3%) is interested in PowerPC builds so why start wasting resources on it again (also the amount of ppl trying to fix powerpc for 11.3 / factory is pretty small either)?
Hey, if you have something to donate with reasonable build power, why not. But it's a sad fact that anything but x86 is either slow, or requires a few extra bucks. -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org
Torsdag den 24. juni 2010 13:58:35 skrev Pavol Rusnak:
[2] http://en.opensuse.org/Documents/Strategy/Derivatives
openSUSE - Base for derivatives
I think this strategy has some serious fundamental flaws. * Very few people are interested in making derivatives. Both in general and within our existing community. While we can't (and shouldn't try to) make *everyone* happy, the strategy at least should avoid alienating too many existing contributors. I'd hate the thought of going to a lug meeting and a guy asks "Why openSUSE?" and I'd have to say "Oh, it's specialized in being a great base for derivatives and appliances". * Even if openSUSE was objectively, technically the best distro for making derivatives, I think noone would care if it wasn't also the best general purpose distro for them. I think most people will tend to choose their own preferred everyday distro for their derivatives - because this is what they know and what they can support etc. * Even if derivative makers would choose openSUSE, I doubt they would contribute much. I think a derivative maker will not ask "what can I do for openSUSE?" but only "what can openSUSE do for me?". * If some big succesful derivative should come into existence, then the derivative would get all the hype - not openSUSE. Being a good base for derivatives might be a good sub-strategy, but it's not a good main focus for the project. -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org
+1 Thread on this topic in forums did not get single answer by now. That much how non-developer user base cares about. -- Regards Rajko, -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org
On Sat, 26 Jun 2010 04:57:43 -0500, Rajko M. wrote:
+1
Thread on this topic in forums did not get single answer by now. That much how non-developer user base cares about.
I would tend to agree as well - if it's a strong general distribution, then it should also be a strong base for respins. Jim -- Jim Henderson Please keep on-topic replies on the list so everyone benefits -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org
Hi, Le jeudi 24 juin 2010, à 13:58 +0200, Pavol Rusnak a écrit :
openSUSE - Base for derivatives ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
I'm mixed on this one: + on one hand, I think we have already a good basis for this strategy, and this is something that could enable us to do some really cool stuff. + on the other hand, it's one strategy where I'm actually unsure that "growing the contributors => growing user base" is true: most users just don't care about derivatives. A few random comments: + as others pointed out, I don't think reducing the size of Factory to a small core will help. This will just lead to forcing people to use more repositories, and this is just a way to move the problem further, without really solving it. (we can also start discussing about how to define what enters the core and what doesn't: there's a big gray area where we won't have an answer) + I'm unsure why we have the LTS stuff associated to this strategy. I'm not saying I'm against it, it just feels like "oh, let's put LTS somewhere and it fits well here" ;-) + as someone who is interested in the technical side of things, I like the idea of derivatives, and I think having some "main" derivatives (as suggested earlier in the thread) is a natural path. + the hard question is: how do we make the idea of derivatives attractive to people outside our community? And for users, we probably shouldn't talk about derivatives at all; I mean, we shouldn't use the term "derivatives", but we should explain why the main derivatives are great and better than alternatives. + it's one strategy where focus is not so much about the openSUSE distribution, but about how to use the openSUSE infrastructure. I kind of like that. A random thought related to this is that, with the build service, we can make it easier for upstream to create packages for all distributions. If we really pushed this, we could potentially change the way software is distributed on distributions (not all software, sure, but that can work for applications at least). That's a game-changer thing for the whole free software world, and not just for the openSUSE distribution. I'd like to see this happen. All in all, I think I'd push this proposal to be even more about the infrastructure side of things, even if it means lowering the important of the distribution in our project -- something which is not uncontroversial, I guess. Vincent -- Les gens heureux ne sont pas pressés. -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org
On Tuesday 06 July 2010 05:24:34 Vincent Untz wrote:
A random thought related to this is that, with the build service, we can make it easier for upstream to create packages for all distributions. If we really pushed this, we could potentially change the way software is distributed on distributions (not all software, sure, but that can work for applications at least). That's a game-changer thing for the whole free software world, and not just for the openSUSE distribution. I'd like to see this happen.
Good random thought :) If pursued can give openSUSE more visibility in Linux world than many other (marketing) efforts. -- Regards Rajko, -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org
participants (16)
-
Gerald Pfeifer -
Greg Freemyer -
Guido Berhoerster -
Jan Engelhardt -
jdd -
Jim Henderson -
Malcolm -
Marcus Meissner -
Marcus Moeller -
Martin Schlander -
Pavol Rusnak -
Peter Czanik -
Rajko M. -
Stephan Kleine -
Thomas Schmidt -
Vincent Untz