[opensuse-buildservice] One common community repository in BuildService?
Hi all, some of other distributions has some kind of a community repository. The Ubuntu guys has universe/multiverse repos, there are Arch User repository for Arch Linux, the Gentoo has Sunrise Overlay, etc. The OpenSUSE has a BuildService, which is an excellent building system for maintenance of the community repository. But the OpenSUSE also has a several hunderds of specialized repos and that is too much complicated for many users. Why are there 10 games: repositories? Or a small one like devel:languages:smalltalk with 2 packages only? I think, that using of several different repos should consists the package conflicts on client's side. And some peoples hates this system, because is too much complex. Are there any technical problems to create a one (or a few) common community repository in BuildService? Do you think, that the existing state is good, or it'll be fine to have a one big community repositry? BTW: Yes, there is also a Packman repository, but guys from Packman team has only one machine (afaik) and the BS has a big farm of building machines. The BS community repo should be much bigger, than Packman one. Regards Michal Vyskocil --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org
On Thursday 24 January 2008 09:17:31 wrote Michal Vyskocil:
Hi all,
some of other distributions has some kind of a community repository. The Ubuntu guys has universe/multiverse repos, there are Arch User repository for Arch Linux, the Gentoo has Sunrise Overlay, etc.
The OpenSUSE has a BuildService, which is an excellent building system for maintenance of the community repository. But the OpenSUSE also has a several hunderds of specialized repos and that is too much complicated for many users. Why are there 10 games: repositories? Or a small one like devel:languages:smalltalk with 2 packages only? I think, that using of several different repos should consists the package conflicts on client's side. And some peoples hates this system, because is too much complex.
Are there any technical problems to create a one (or a few) common community repository in BuildService? Do you think, that the existing state is good, or it'll be fine to have a one big community repositry?
I agree that some of the projects should get packed together and one should look at this. But having only project would have several dis advatanges: * All needs to use same project setup config, means building for the same base distributions and using same package project config. * write access to that project needs to be either more strict and less open than atm, or if you keep it open, no one can really trust this repo and you should not add it. Keep in mind that such a repo would be a perfect target for someone who wants to steal your credit cards numbers for example, what would be really easy than (no, I will not describe how;). * several projects do conflict even at build time. We had the problem in the past that submissions to the old "supplementary" to fix A destroed B. (It was really hard for me sometimes to keep KDE working in that and often enough even more low level stuff like apache got crashed but other peoples submissions. And at that time only less than 10 people have commited to that. Imagine what happens with write access to more than 100 people) * More people with write access will keep the project building, that means in worst case it will get never get released to the ftp server. I think we do our best to improve the handling of multiple repos, something what we need anyway. Esp. the YaST meta package installer from Benjiman has helped here a lot already. However, when you have suggestions like, put project A and B and C together to D, we should really discuss and consider it here. Because I agree that we can reduce the number of projects. 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 24/01/2008, Adrian Schröter <adrian@suse.de> wrote:
But having only project would have several dis advatanges:
<snip> Also until there is diffed metadata support, one frequently changing large repository will frequently require a large metadata download to refresh. Packman is already causing this and it's not particularly big. -- Benjamin Weber --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org
Adrian Schröter wrote:
But having only project would have several dis advatanges:
* All needs to use same project setup config, means building for the same base distributions and using same package project config.
* write access to that project needs to be either more strict and less open than atm, or if you keep it open, no one can really trust this repo and you should not add it. Keep in mind that such a repo would be a perfect target for someone who wants to steal your credit cards numbers for example, what would be really easy than (no, I will not describe how;).
* several projects do conflict even at build time. We had the problem in the past that submissions to the old "supplementary" to fix A destroed B. (It was really hard for me sometimes to keep KDE working in that and often enough even more low level stuff like apache got crashed but other peoples submissions. And at that time only less than 10 people have commited to that. Imagine what happens with write access to more than 100 people)
* More people with write access will keep the project building, that means in worst case it will get never get released to the ftp server.
* With one large repo, it's 'either all or nothing' for the end user. E.g. imagine a web developer who wants the latest LAMP stack, but wants KDE to stay as is, so that his non-techie girlfriend doesn't get scared each time she uses the computer. I'd say the current setup suits him better in this case. Of course, with users who subscribe 100+ buildservice repos, there's surely room for improvement ;) Michal --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org
Hi, On Thursday, January 24, 2008 at 12:03:00, Michal Marek wrote:
Of course, with users who subscribe 100+ buildservice repos, there's surely room for improvement ;)
Get a buildservice account, link everything you want to your home, be done with it? That process has to be improved but in theory its very simple. Henne -- Henne Vogelsang, openSUSE. Everybody has a plan, until they get hit. - Mike Tyson --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org
On 2008-01-24 12:16:18 +0100, Henne Vogelsang wrote:
On Thursday, January 24, 2008 at 12:03:00, Michal Marek wrote:
Of course, with users who subscribe 100+ buildservice repos, there's surely room for improvement ;)
Get a buildservice account, link everything you want to your home, be done with it?
err no? this is plain stupid. first of all you would/should use aggregate. anyway just duplicating packages to avoid signing up multiple repositories is plain stupid. it waste build time, space on mirrors. imho it is much better to have small repositories focused on single package groups to avoid cross dependencies. packman is a bad example there. if you just want mediacodecs you get updated versions of tons of other libs. and sometimes they even broken other programs with it (libxml2 updates breaking kde's meinproc in the past).
That process has to be improved but in theory its very simple.
yeah. it is simple just subscribe the small repositories you really need. the most simple way might be one click installer. darix -- openSUSE - SUSE Linux is my linux openSUSE is good for you www.opensuse.org --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org
On Thursday 24 January 2008 12:16:18 wrote Henne Vogelsang:
Hi,
On Thursday, January 24, 2008 at 12:03:00, Michal Marek wrote:
Of course, with users who subscribe 100+ buildservice repos, there's surely room for improvement ;)
Get a buildservice account, link everything you want to your home, be done with it?
HELLO ???? I will kick such people. Do not expect to get your account back soon. And the quota system will protect us from such kind of missuse. package managers are designed to handle multiple repos. If they do not do well, fix it or use a different package manager. There should be no difference by having the same data in one or more repos for the package manager. 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
Hi, On Thursday, January 24, 2008 at 13:37:48, Adrian Schröter wrote:
On Thursday 24 January 2008 12:16:18 wrote Henne Vogelsang:
On Thursday, January 24, 2008 at 12:03:00, Michal Marek wrote:
Of course, with users who subscribe 100+ buildservice repos, there's surely room for improvement ;)
Get a buildservice account, link everything you want to your home, be done with it?
HELLO ????
Hey there. How is it hanging? :) I dont know where you have been the last 4 years but static content like we have now is outmoded. You have to provide the building blocks, the means and the user (or a group of users) does the rest. Not necessarily in the buildservice frontend we have now, i tend to agree with you on that, but thats what these requests are about.
package managers are designed to handle multiple repos. If they do not do well, fix it or use a different package manager.
There should be no difference by having the same data in one or more repos for the package manager.
Im sorry but you are (still) designing the OBS for packagemanagers instead of people :) Henne -- Henne Vogelsang, openSUSE. Everybody has a plan, until they get hit. - Mike Tyson --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org
On Thursday 24 January 2008 14:06:40 wrote Henne Vogelsang:
Hi,
On Thursday, January 24, 2008 at 13:37:48, Adrian Schröter wrote:
On Thursday 24 January 2008 12:16:18 wrote Henne Vogelsang:
On Thursday, January 24, 2008 at 12:03:00, Michal Marek wrote:
Of course, with users who subscribe 100+ buildservice repos, there's surely room for improvement ;)
Get a buildservice account, link everything you want to your home, be done with it?
HELLO ????
Hey there. How is it hanging? :)
I dont know where you have been the last 4 years but static content like we have now is outmoded. You have to provide the building blocks, the means and the user (or a group of users) does the rest.
Not necessarily in the buildservice frontend we have now, i tend to agree with you on that, but thats what these requests are about.
You are aware that you suggested to duplicate several 100 of Gigabytes on our main server and all it's mirrors, because one single person wants a different repo setup ? Can you calculate, how much space we and all our mirrors would need to fullfill this request when every second of our openSUSE users will do this ?
package managers are designed to handle multiple repos. If they do not do well, fix it or use a different package manager.
There should be no difference by having the same data in one or more repos for the package manager.
Im sorry but you are (still) designing the OBS for packagemanagers instead of people :)
I simply refuse to implement workarounds in OBS, just because no one fixes packagemanagers or design them for users. -- 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
Hi, On Thursday, January 24, 2008 at 14:17:18, Adrian Schröter wrote:
On Thursday 24 January 2008 14:06:40 wrote Henne Vogelsang:
On Thursday, January 24, 2008 at 13:37:48, Adrian Schröter wrote:
On Thursday 24 January 2008 12:16:18 wrote Henne Vogelsang:
On Thursday, January 24, 2008 at 12:03:00, Michal Marek wrote:
Of course, with users who subscribe 100+ buildservice repos, there's surely room for improvement ;)
Get a buildservice account, link everything you want to your home, be done with it?
HELLO ????
Hey there. How is it hanging? :)
I dont know where you have been the last 4 years but static content like we have now is outmoded. You have to provide the building blocks, the means and the user (or a group of users) does the rest.
Not necessarily in the buildservice frontend we have now, i tend to agree with you on that, but thats what these requests are about.
You are aware that you suggested to duplicate several 100 of Gigabytes on our main server and all it's mirrors, because one single person wants a different repo setup ?
You are aware that you need to provide the means to do that right? Maybe in a way that it does not have the consequences you describe above...
Can you calculate, how much space we and all our mirrors would need to fullfill this request when every second of our openSUSE users will do this ?
Nope. But i can see other (web)services that provide content that is far more space intensive, to way more users then we do, without a problem. So it cant be that hard dont you think? :)
package managers are designed to handle multiple repos. If they do not do well, fix it or use a different package manager.
There should be no difference by having the same data in one or more repos for the package manager.
Im sorry but you are (still) designing the OBS for packagemanagers instead of people :)
I simply refuse to implement workarounds in OBS, just because no one fixes packagemanagers or design them for users.
You cant make the task of package installations (== what a package manager does) _much_ easier as it is right now. I think we can all agree on that. What you can make easier is providing the packages the user wants. A huge repository with thousands of packages is not the answer. A thousand repositories, with one package in each, aren't either. Henne -- Henne Vogelsang, openSUSE. Everybody has a plan, until they get hit. - Mike Tyson --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org
On 24-01-2008 at 15:06, Henne Vogelsang <hvogel@opensuse.org> wrote: I dont know where you have been the last 4 years but static content like we have now is outmoded. You have to provide the building blocks, the means and the user (or a group of users) does the rest.
Hmmmm. so you think we should jump on the web2.0 hype with OBS ;) well: actually, for the end user, a sort of 'aggregate' would be enough to offer. Maybe we can do something with just providing an updated 'repodata' directory for that user, having them point to the actual directore (project) where from they got linked? something like: http://download.opensuse.org/users/dimstar/repodata contains all the repodata set for 'my' own project, but I do not have rpms there myself. all the needed xml files (repomd, other, primary and filelists) would be provided per user basis (I think other is not really nescessary, no clue about filelists, if we can skip it / have them empty dummy files) primary.xml would contain the location-hrefs to the original 'aggregated' RPMs (are absolute path allowed here, like http://download.opensuse.org/repositories/games:/arcade/openSUSE_Factory/x86...) The impact with the repodata only structure should be rather small on the whole system. Maybe we can try to investigate on something like this, instead of denying the whole idea from the beginning? I of course see many problems arising from missing dependencies (user select package a from project A but does not select A-data from project B and the like). Dominique -- --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org
On Thursday 24 January 2008 12:03:00 wrote:
* With one large repo, it's 'either all or nothing' for the end user. E.g. imagine a web developer who wants the latest LAMP stack, but wants KDE to stay as is, so that his non-techie girlfriend doesn't get scared each time she uses the computer. I'd say the current setup suits him better in this case.
This is a misinterpretation of my post. I'm talking about the packages, which are not in openSUSE (for example gle-graphics.org, or the Squeak Smalltalk). Not about latest versions of KDE, or a LAMP. The BuildService provides a repositories like OpenSUSE_10.3 and a community repo should countain only packages based on libraries or tools included in this repos *only*. If any package needs the newest version of gcc, KDE, or something else, there's also a Factory repository (Debian users often use a mixed system and libzypp should brings a support for repository priorities like apt, or yum, which avoids to break the system). As Adrian saids, the Packman guys often tends to duplicate a packages from openSUSE, which should breaks the distribution and its bad. I'm talking about the policy, that a creation of a specialized repo is exception, not a rule. I'm understand, that a big projects, like KDE, Gnome, Java*, or Apache needs the specific repository, because they are much more complex and its hard to maintain them. But there are already a part of a OpenSUSE (or will be in a future) and not be interested for the community repo. I believe, that most of simple end-user applications should be included in one repository, without a big problems. * in Java:jpackage-1.7 we have about 200+ packages and many of them don't have their build dependencies yet. In that case is necessary to have a specialized repository, because the jpackage project is really big and there are a few peoples, which commits the packages. Regards Michal Vyskocil --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org
Michal Vyskocil wrote:
On Thursday 24 January 2008 12:03:00 wrote:
* With one large repo, it's 'either all or nothing' for the end user. E.g. imagine a web developer who wants the latest LAMP stack, but wants KDE to stay as is, so that his non-techie girlfriend doesn't get scared each time she uses the computer. I'd say the current setup suits him better in this case.
This is a misinterpretation of my post. I'm talking about the packages, which are not in openSUSE (for example gle-graphics.org, or the Squeak Smalltalk). Not about latest versions of KDE, or a LAMP.
The BuildService provides a repositories like OpenSUSE_10.3 and a community repo should countain only packages based on libraries or tools included in this repos *only*. If any package needs the newest version of gcc, KDE, or something else, there's also a Factory repository
# cat /etc/SuSE-release SUSE Linux Enterprise Server 10 (x86_64) VERSION = 10 PATCHLEVEL = 1 # zypper sa http://download.opensuse.org/distribution/SL-OSS-factory/inst-source/ FACTORY ... Added Installation Sources: [x]* FACTORY (http://download.opensuse.org/distribution/SL-OSS-factory/inst-source/) # zypper in mysql Restoring system sources... Parsing metadata for FACTORY... Invalid object: Can't open /var/lib/zypp/cache/Source.wBVYRq/DATA/descr/packages Unexpected exception. Can't parse packages file: Can't open /var/lib/zypp/cache/Source.wBVYRq/DATA/descr/packages Please file a bug report about this. It _might_ work to mix the latest released version and factory, but then reread my mail - it's all or nothing (and no, I don't think that tweaking the package manager config is any easier than choosing the right buildservice repositories).
I believe, that most of simple end-user applications should be included in one repository, without a big problems.
Again, this might be true when you only build for a recent enough distribution. Michal --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org
On pátek 25 leden 2008, Michal Vyskocil wrote:
On Thursday 24 January 2008 12:03:00 wrote:
* With one large repo, it's 'either all or nothing' for the end user. E.g. imagine a web developer who wants the latest LAMP stack, but wants KDE to stay as is, so that his non-techie girlfriend doesn't get scared each time she uses the computer. I'd say the current setup suits him better in this case.
This is a misinterpretation of my post. I'm talking about the packages, which are not in openSUSE (for example gle-graphics.org, or the Squeak Smalltalk). Not about latest versions of KDE, or a LAMP.
I think that we are mixing these 2 things: 1. provide packages that are not in the base distro 2. provide newer versions of packages in the base distro
The BuildService provides a repositories like OpenSUSE_10.3 and a community repo should countain only packages based on libraries or tools included in this repos *only*. If any package needs the newest version of gcc, KDE, or something else, there's also a Factory repository (Debian users often use a mixed system and libzypp should brings a support for repository priorities like apt, or yum, which avoids to break the system). As Adrian saids, the Packman guys often tends to duplicate a packages from openSUSE, which should breaks the distribution and its bad.
I'm talking about the policy, that a creation of a specialized repo is exception, not a rule. I'm understand, that a big projects, like KDE, Gnome, Java*, or Apache needs the specific repository, because they are much more complex and its hard to maintain them. But there are already a part of a OpenSUSE (or will be in a future) and not be interested for the community repo. I believe, that most of simple end-user applications should be included in one repository, without a big problems.
Specialized repos are ideal for case 2 - for users that want to be on the bleeding edge in just one area and want to have stable distro otherwise. Even one-package top-level project is OK from this point of view. For case 1 we could have a project called like "Addon" with carefully selected stable packages that does not conflict with the packages in main distro. It should have limited number of maintainers who would review submissions of others. Links or aggregates to specialized projects probably can't be used because this project should typically get only well tested versions. Popular packages from this project would be good candidates for inclusion in next version of base distro. Vladimir Nadvornik --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org
On Thu, 24 Jan 2008, Adrian Schröter wrote:
However, when you have suggestions like, put project A and B and C together to D, we should really discuss and consider it here. Because I agree that we can reduce the number of projects.
Ok. Some suggestions for cleanup. a) Move contents of "net-snmp" into "network:utilities". b) Move "filesharing" into "network:" tree. c) Move contents of "Subversion" into "devel:tools". d) Move "ggz" into "games:" tree e) Move "editors" into "devel:" tree. Ciao -- http://www.dstoecker.eu/ (PGP key available)
On 25-01-2008 at 09:59, Dirk Stoecker <opensuse@dstoecker.de> wrote: On Thu, 24 Jan 2008, Adrian Schröter wrote:
However, when you have suggestions like, put project A and B and C together to D, we should really discuss and consider it here. Because I agree
Hello, that we
can
reduce the number of projects.
Ok. Some suggestions for cleanup.
a) Move contents of "net-snmp" into "network:utilities".
b) Move "filesharing" into "network:" tree.
c) Move contents of "Subversion" into "devel:tools".
d) Move "ggz" into "games:" tree
e) Move "editors" into "devel:" tree.
Looks like some sane suggestions... editors -> devel appears a bit strange... but I can't see a better point neither and it's very few packages there. Why is Apache for example an own Top-Level project? I would suppose it in server:http (as a subproject or whatever) Apache serves little other than http server. ASCIIParadize is mainly games... maybe games: (there are 2 games... could not identify what the hird package is). By name it sounds like a space invaders ;) Banshee -> Multimedia GPhoto -> Graphics In general I think the 'one product' projects should not exist at TopLevel. Dominique --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org
On Friday 25 January 2008 09:28:49 wrote Dominique Leuenberger:
Hello,
On 25-01-2008 at 09:59, Dirk Stoecker <opensuse@dstoecker.de>
wrote:
On Thu, 24 Jan 2008, Adrian Schröter wrote:
However, when you have suggestions like, put project A and B and C
together
to
D, we should really discuss and consider it here. Because I agree
that we
can
reduce the number of projects.
Ok. Some suggestions for cleanup.
a) Move contents of "net-snmp" into "network:utilities".
b) Move "filesharing" into "network:" tree.
c) Move contents of "Subversion" into "devel:tools".
d) Move "ggz" into "games:" tree
e) Move "editors" into "devel:" tree.
Looks like some sane suggestions... editors -> devel appears a bit strange... but I can't see a better point neither and it's very few packages there.
Why is Apache for example an own Top-Level project? I would suppose it in server:http (as a subproject or whatever) Apache serves little other than http server.
I would like just point out some things. Project definitions (and even the names) are not meant to help finding stuff. Therefore we have the web interfaces (or we need to improve them if not sufficiant, but I would like to skip this discussion for now). Joining projects have the consequence that: * a larger common list of people with write access to it. This might not be acceptable in all cases. Esp. for apache I can see an argument, that server admins might only want to trust the official openSUSE packagers. (This does not mean that there can't be another, let's say Apache:Community project). * Joint projects need to ensure that they have nothing inside where they conflict. The failure of delivering a joint repo with KDE and Gnome packages in the past proves this point as important ... * All packages needs to be able to use the same base repos. This does not work out always, when for example the latest stack is needed for some packages. But other packages want to stick with the original stack from the distro to avoid problems updating it. (The feature of KDE:Backports project is that it does not require to update also to the latest KDE. This is a big improvement for people who just want a single app.) So, joining projects can only be done if the upper things can get fullfilled. Beside that, several of the suggestion are just moves. Btw, we can do the moves and add a rule to our redirector to avoid that users need to re-add the repos. However, I would like to get rid of these rules in the long run again.
ASCIIParadize is mainly games... maybe games: (there are 2 games... could not identify what the hird package is). By name it sounds like a space invaders ;)
ASCIIParadize was just our first test project ... I will check if we can remove it ...
Banshee -> Multimedia GPhoto -> Graphics
In general I think the 'one product' projects should not exist at TopLevel.
Might be a valid rule .. -- 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 Fri, 25 Jan 2008, Adrian Schröter wrote:
Beside that, several of the suggestion are just moves. Btw, we can do the moves and add a rule to our redirector to avoid that users need to re-add the repos. However, I would like to get rid of these rules in the long run again.
Well, that's why doing a bit of cleanup now. The later it is done, the more trouble it will be.
In general I think the 'one product' projects should not exist at TopLevel.
Might be a valid rule ..
That was the idea behind my 3 tree-move suggestions :-) Another point: What is done with inactive home directories? There are some homes, which have partial stuff never finished, which keep the search results confusing. Can't there be something like "1/2 year no login" -> disable (with mail notice), "1 year no login" -> kill? Ciao -- http://www.dstoecker.eu/ (PGP key available)
Hello,
In general I think the 'one product' projects should not exist at TopLevel.
Might be a valid rule ..
Now we had this discussion and nothing happend. 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
participants (9)
-
Adrian Schröter -
Benji Weber -
Dirk Stoecker -
Dominique Leuenberger -
Henne Vogelsang -
Marcus Rueckert -
Michal Marek -
Michal Vyskocil -
Vladimir Nadvornik