[opensuse-buildservice] Project classifications
Hi, the openSUSE booster teams has started to improve the http://software.opensuse.org/search interface. One important thing is to improve the search results. It is important from our POV that the project owner can classify the purpose of his project. This is currently suggested in this fate request : https://features.opensuse.org/306232 as STABLE -- project is considered to be ready to use for End-Users TESTING -- project should work from point of developer view, but needs verification DEVELOPMENT -- project is random state, it might work. BROKEN -- project is known to be not working atm. The default value would be "DEVELOPMENT", which is also used when someone creates a new branch of a package by default. by default the software search would just show "STABLE" projects in their results. If no result can be found, the search will offer to search also for the unstable versions. Project owners can set this state in their project at any time. I would like to hear some feedback about the suggested states. Are they understandable and do they make sense ? thank you adrian -- Adrian Schroeter SUSE Linux Products GmbH 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, Apr 23, 2010 at 10:53:16AM +0200, Adrian Schröter wrote:
Hi,
the openSUSE booster teams has started to improve the
http://software.opensuse.org/search
interface. One important thing is to improve the search results. It is important from our POV that the project owner can classify the purpose of his project.
This is currently suggested in this fate request :
https://features.opensuse.org/306232
as
STABLE -- project is considered to be ready to use for End-Users TESTING -- project should work from point of developer view, but needs verification DEVELOPMENT -- project is random state, it might work. BROKEN -- project is known to be not working atm.
The default value would be "DEVELOPMENT", which is also used when someone creates a new branch of a package by default.
by default the software search would just show "STABLE" projects in their results. If no result can be found, the search will offer to search also for the unstable versions.
Project owners can set this state in their project at any time.
I would like to hear some feedback about the suggested states. Are they understandable and do they make sense ?
Sounds reasonable to me and I like the idea. I'm just wondering how to handle home:<login> projects. They might "win" against an official devel project in state DEVELOPMENT since they have been classified as STABLE at some point, but are meanwhile in a complete broken state ... Best regards, Stefan Public Key available ------------------------------------------------------ Stefan Dirsch (Res. & Dev.) SUSE LINUX Products GmbH Tel: 0911-740 53 0 Maxfeldstraße 5 FAX: 0911-740 53 479 D-90409 Nürnberg http://www.suse.de Germany ----------------------------------------------------------------- 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
Am Freitag, 23. April 2010 11:12:20 schrieb Stefan Dirsch:
On Fri, Apr 23, 2010 at 10:53:16AM +0200, Adrian Schröter wrote:
Hi,
the openSUSE booster teams has started to improve the
http://software.opensuse.org/search
interface. One important thing is to improve the search results. It is important from our POV that the project owner can classify the purpose of his project.
This is currently suggested in this fate request :
https://features.opensuse.org/306232
as
STABLE -- project is considered to be ready to use for End-Users TESTING -- project should work from point of developer view, but needs verification DEVELOPMENT -- project is random state, it might work. BROKEN -- project is known to be not working atm.
The default value would be "DEVELOPMENT", which is also used when someone creates a new branch of a package by default.
by default the software search would just show "STABLE" projects in their results. If no result can be found, the search will offer to search also for the unstable versions.
Project owners can set this state in their project at any time.
I would like to hear some feedback about the suggested states. Are they understandable and do they make sense ?
Sounds reasonable to me and I like the idea. I'm just wondering how to handle home:<login> projects. They might "win" against an official devel project in state DEVELOPMENT since they have been classified as STABLE at some point, but are meanwhile in a complete broken state ...
Yes, but a handle for complete unmaintained projects need to be supported differently. This mechanism only gives the active developers a chance to flag their projects. However, default will be "DEVELOPMENT", so all the in-active home: projects will just not be visible in first place. bye adrian -- Adrian Schroeter SUSE Linux Products GmbH 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, Apr 23, 2010 at 11:32:53AM +0200, Adrian Schröter wrote:
Am Freitag, 23. April 2010 11:12:20 schrieb Stefan Dirsch:
On Fri, Apr 23, 2010 at 10:53:16AM +0200, Adrian Schröter wrote:
Hi,
the openSUSE booster teams has started to improve the
http://software.opensuse.org/search
interface. One important thing is to improve the search results. It is important from our POV that the project owner can classify the purpose of his project.
This is currently suggested in this fate request :
https://features.opensuse.org/306232
as
STABLE -- project is considered to be ready to use for End-Users TESTING -- project should work from point of developer view, but needs verification DEVELOPMENT -- project is random state, it might work. BROKEN -- project is known to be not working atm.
The default value would be "DEVELOPMENT", which is also used when someone creates a new branch of a package by default.
by default the software search would just show "STABLE" projects in their results. If no result can be found, the search will offer to search also for the unstable versions.
Project owners can set this state in their project at any time.
I would like to hear some feedback about the suggested states. Are they understandable and do they make sense ?
Sounds reasonable to me and I like the idea. I'm just wondering how to handle home:<login> projects. They might "win" against an official devel project in state DEVELOPMENT since they have been classified as STABLE at some point, but are meanwhile in a complete broken state ...
Yes, but a handle for complete unmaintained projects need to be supported differently. This mechanism only gives the active developers a chance to flag their projects.
Ok. I didn't know that home projects were intended to be handled differently anyway. Stefan Public Key available ------------------------------------------------------ Stefan Dirsch (Res. & Dev.) SUSE LINUX Products GmbH Tel: 0911-740 53 0 Maxfeldstraße 5 FAX: 0911-740 53 479 D-90409 Nürnberg http://www.suse.de Germany ----------------------------------------------------------------- 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 04/23/2010 05:32 AM, Adrian Schröter wrote:
Am Freitag, 23. April 2010 11:12:20 schrieb Stefan Dirsch:
On Fri, Apr 23, 2010 at 10:53:16AM +0200, Adrian Schröter wrote:
Hi,
the openSUSE booster teams has started to improve the
http://software.opensuse.org/search
interface. One important thing is to improve the search results. It is important from our POV that the project owner can classify the purpose of his project.
This is currently suggested in this fate request :
https://features.opensuse.org/306232
as
STABLE -- project is considered to be ready to use for End-Users TESTING -- project should work from point of developer view, but needs verification DEVELOPMENT -- project is random state, it might work. BROKEN -- project is known to be not working atm.
The default value would be "DEVELOPMENT", which is also used when someone creates a new branch of a package by default.
by default the software search would just show "STABLE" projects in their results. If no result can be found, the search will offer to search also for the unstable versions.
Project owners can set this state in their project at any time.
I would like to hear some feedback about the suggested states. Are they understandable and do they make sense ?
Sounds reasonable to me and I like the idea. I'm just wondering how to handle home:<login> projects. They might "win" against an official devel project in state DEVELOPMENT since they have been classified as STABLE at some point, but are meanwhile in a complete broken state ...
Yes, but a handle for complete unmaintained projects need to be supported differently. This mechanism only gives the active developers a chance to flag their projects.
I'm not sure that the classification on a project level is sufficient. It appears that one should have the option to make this classification at the package level. For example, it is perfectly reasonable to build unrelated packages in home:<login>, some of these packages can be considered STABLE while others may have any of the other states. Further the software search searches for packages and not projects. Thus there is a more direct correlation between a state set up on a package rather than a state of a project. Tagging a project with a given state is IMHO a convenience to mark all packages in a given project with the same state. Robert
However, default will be "DEVELOPMENT", so all the in-active home: projects will just not be visible in first place.
bye adrian
-- Robert Schweikert MAY THE SOURCE BE WITH YOU Software Engineer Consultant LINUX rschweikert@novell.com 781-464-8147 Novell Making IT Work As One -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org
Am Freitag, 23. April 2010 13:16:10 schrieb Robert Schweikert:
On 04/23/2010 05:32 AM, Adrian Schröter wrote:
Am Freitag, 23. April 2010 11:12:20 schrieb Stefan Dirsch:
On Fri, Apr 23, 2010 at 10:53:16AM +0200, Adrian Schröter wrote:
Hi,
the openSUSE booster teams has started to improve the
http://software.opensuse.org/search
interface. One important thing is to improve the search results. It is important from our POV that the project owner can classify the purpose of his project.
This is currently suggested in this fate request :
https://features.opensuse.org/306232
as
STABLE -- project is considered to be ready to use for End-Users TESTING -- project should work from point of developer view, but needs verification DEVELOPMENT -- project is random state, it might work. BROKEN -- project is known to be not working atm.
The default value would be "DEVELOPMENT", which is also used when someone creates a new branch of a package by default.
by default the software search would just show "STABLE" projects in their results. If no result can be found, the search will offer to search also for the unstable versions.
Project owners can set this state in their project at any time.
I would like to hear some feedback about the suggested states. Are they understandable and do they make sense ?
Sounds reasonable to me and I like the idea. I'm just wondering how to handle home:<login> projects. They might "win" against an official devel project in state DEVELOPMENT since they have been classified as STABLE at some point, but are meanwhile in a complete broken state ...
Yes, but a handle for complete unmaintained projects need to be supported differently. This mechanism only gives the active developers a chance to flag their projects.
I'm not sure that the classification on a project level is sufficient. It appears that one should have the option to make this classification at the package level.
For the user it is most interesting if he can add the repository or not. And one single package can make an entire repo broken. So I would just go for the simple project wide approach for now. Calculating the trust in single packages, depending on the content and submitters is a complete different approach (read the trust concept in the wiki for this). bye adrian -- Adrian Schroeter SUSE Linux Products GmbH email: adrian@suse.de -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org
On 04/23/2010 07:36 AM, Adrian Schröter wrote:
Am Freitag, 23. April 2010 13:16:10 schrieb Robert Schweikert:
On 04/23/2010 05:32 AM, Adrian Schröter wrote:
Am Freitag, 23. April 2010 11:12:20 schrieb Stefan Dirsch:
On Fri, Apr 23, 2010 at 10:53:16AM +0200, Adrian Schröter wrote:
Hi,
the openSUSE booster teams has started to improve the
http://software.opensuse.org/search
interface. One important thing is to improve the search results. It is important from our POV that the project owner can classify the purpose of his project.
This is currently suggested in this fate request :
https://features.opensuse.org/306232
as
STABLE -- project is considered to be ready to use for End-Users TESTING -- project should work from point of developer view, but needs verification DEVELOPMENT -- project is random state, it might work. BROKEN -- project is known to be not working atm.
The default value would be "DEVELOPMENT", which is also used when someone creates a new branch of a package by default.
by default the software search would just show "STABLE" projects in their results. If no result can be found, the search will offer to search also for the unstable versions.
Project owners can set this state in their project at any time.
I would like to hear some feedback about the suggested states. Are they understandable and do they make sense ?
Sounds reasonable to me and I like the idea. I'm just wondering how to handle home:<login> projects. They might "win" against an official devel project in state DEVELOPMENT since they have been classified as STABLE at some point, but are meanwhile in a complete broken state ...
Yes, but a handle for complete unmaintained projects need to be supported differently. This mechanism only gives the active developers a chance to flag their projects.
I'm not sure that the classification on a project level is sufficient. It appears that one should have the option to make this classification at the package level.
For the user it is most interesting if he can add the repository or not. And one single package can make an entire repo broken.
But software search does not search for repositories, it searches for packages. Those packages happen to be part of a project but a user searching for couchDB for example is interested in that package and not in the classification of the project that happens to contain the package. Projects are a nice abstraction and organization mechanism for developers and contributers. IMHO from a user point of view in most cases functionality provided by a given package is of most interest. Robert
So I would just go for the simple project wide approach for now.
Calculating the trust in single packages, depending on the content and submitters is a complete different approach (read the trust concept in the wiki for this).
bye adrian
-- Robert Schweikert MAY THE SOURCE BE WITH YOU Software Engineer Consultant LINUX rschweikert@novell.com 781-464-8147 Novell Making IT Work As One -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org
On Friday 23 of April 2010, Adrian Schröter wrote:
This is currently suggested in this fate request :
https://features.opensuse.org/306232
as
STABLE -- project is considered to be ready to use for End-Users TESTING -- project should work from point of developer view, but needs verification DEVELOPMENT -- project is random state, it might work. BROKEN -- project is known to be not working atm.
I find it rather hard to see the difference between two adjacent states. I'm not even sure what states I would use e.g. for the KDE: repos (http://en.opensuse.org/KDE/Repositories). Is KDE:KDE4:STABLE:Desktop STABLE or TESTING here, when from developers' point of view it's stable and fixes keep getting added, but we don't really test it that much as such and expect users to find possible problems? Is KDE:KDE4:Factory:Desktop TESTING or DEVELOPMENT? We develop for next openSUSE there, but it's usually stable enough to be normally used. Or should we switch the state all the time depending on the situation, which nobody will bother to keep doing anyway? And I fail to see the point of BROKEN. Why would anybody intentionally have a broken repo? What are the expected workflows with these states? The first 3 could match the 3 KDE STABLE/Factory/UNSTABLE repos, but the descriptions don't seem to fit. -- Lubos Lunak openSUSE Boosters team, KDE developer l.lunak@suse.cz , l.lunak@kde.org -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org
Am Freitag, 23. April 2010 11:53:38 schrieb Lubos Lunak:
On Friday 23 of April 2010, Adrian Schröter wrote:
This is currently suggested in this fate request :
https://features.opensuse.org/306232
as
STABLE -- project is considered to be ready to use for End-Users TESTING -- project should work from point of developer view, but needs verification DEVELOPMENT -- project is random state, it might work. BROKEN -- project is known to be not working atm.
I find it rather hard to see the difference between two adjacent states. I'm not even sure what states I would use e.g. for the KDE: repos (http://en.opensuse.org/KDE/Repositories).
Is KDE:KDE4:STABLE:Desktop STABLE or TESTING here, when from developers' point of view it's stable and fixes keep getting added, but we don't really test it that much as such and expect users to find possible problems?
From my POV it is STABLE. It does not make sense to call the project STABLE and then it isn't ? Sure, a bug can be everywhere, also in a final release like openSUSE:11.2, but it is by definition STABLE and it should be handled like it is.
Is KDE:KDE4:Factory:Desktop TESTING or DEVELOPMENT? We develop for next openSUSE there, but it's usually stable enough to be normally used. Or should we switch the state all the time depending on the situation, which nobody will bother to keep doing anyway?
Switching all the time makes no sense of course, because people would not add/remove the repos all the time. Since it you say it is usually stable, I would consider it as "TESTING". If you do experimental stuff, you do switch off publishing or do it somewhere else instead.
And I fail to see the point of BROKEN. Why would anybody intentionally have a broken repo?
Well, it is maybe not intentionally, but currently anyway broken. So it is known not to work and we may disable the bugreport link in this case. bye adrian -- Adrian Schroeter SUSE Linux Products GmbH email: adrian@suse.de -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org
On Friday 23 April 2010 11:53:38 Lubos Lunak wrote:
What are the expected workflows with these states? The first 3 could match the 3 KDE STABLE/Factory/UNSTABLE repos, but the descriptions don't seem to fit.
That was my reaction as well. But looked at another way, it seems a lot like debian stable/testing/lenny without the Toy Story references, which is at least widely understood. Perhaps this could be our new KDE: namespace naming scheme too? ;) Will -- Will Stephenson, KDE Developer, openSUSE Boosters Team SUSE LINUX Products GmbH - Nürnberg - AG Nürnberg - HRB 16746 - GF: Markus Rex -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org
On Fri, Apr 23, 2010 at 10:53:16AM +0200, Adrian Schröter wrote: [ 8< ]
This is currently suggested in this fate request :
https://features.opensuse.org/306232
as
STABLE -- project is considered to be ready to use for End-Users TESTING -- project should work from point of developer view, but needs verification DEVELOPMENT -- project is random state, it might work. BROKEN -- project is known to be not working atm.
In general I like the approach. In particular as we use the same names STABLE and TESTING already for our Samba repositories. I'm not sure if the states DEVELOPMENT and BROKEN are required. More opportunities might make it more and unwanted complex. Here I have the Keep It Simple Stupid approach in mind. [ 8< ]
I would like to hear some feedback about the suggested states. Are they understandable and do they make sense ?
In general this is good and your suggestion makes sense to me. We had a log discussion how to name our branches. And as native speakers had been part of the disusssion it's very likely that more people are able to follow the names. Lars -- Lars Müller [ˈlaː(r)z ˈmʏlɐ] Samba Team SUSE Linux, Maxfeldstraße 5, 90409 Nürnberg, Germany
On 4/23/2010 at 10:53, Adrian Schröter<adrian@suse.de> wrote:
STABLE -- project is considered to be ready to use for End-Users TESTING -- project should work from point of developer view, but needs verification DEVELOPMENT -- project is random state, it might work. BROKEN -- project is known to be not working atm.
Am I right in assuming that BROKEN is a state that would never be shown on the search results? I would maybe favor a different name, like INTERNALUSE or whatever (or having this as an additional state). Why? I'd like to have my 'playgrounds' tagged in a way to be sure users are not getting there in any way until instructed to do so. I'm not willing to get any bugreports for any such repository. so excluding it intentionally from the search result is a good thing, tagging it as 'BROKEN' would not be the right 'word' for it (internal testing). I hope anybody can make any sense of that scribble :) Dominique -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org
On 04/23/2010 07:00 AM, Dominique Leuenberger wrote:
On 4/23/2010 at 10:53, Adrian Schröter<adrian@suse.de> wrote:
STABLE -- project is considered to be ready to use for End-Users TESTING -- project should work from point of developer view, but needs verification DEVELOPMENT -- project is random state, it might work. BROKEN -- project is known to be not working atm.
Am I right in assuming that BROKEN is a state that would never be shown on the search results? I would maybe favor a different name, like INTERNALUSE or whatever (or having this as an additional state).
I think PRIVATE would be a bit more obvious for this use case. INTERNALUSE would imply this is internal to some organization, but obs by definition is open and external to Novell and any other organization. Robert
Why? I'd like to have my 'playgrounds' tagged in a way to be sure users are not getting there in any way until instructed to do so. I'm not willing to get any bugreports for any such repository. so excluding it intentionally from the search result is a good thing, tagging it as 'BROKEN' would not be the right 'word' for it (internal testing).
I hope anybody can make any sense of that scribble :)
Dominique
-- Robert Schweikert MAY THE SOURCE BE WITH YOU Software Engineer Consultant LINUX rschweikert@novell.com 781-464-8147 Novell Making IT Work As One -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org
Am Freitag, 23. April 2010 13:00:09 schrieb Dominique Leuenberger:
On 4/23/2010 at 10:53, Adrian Schröter<adrian@suse.de> wrote:
STABLE -- project is considered to be ready to use for End-Users TESTING -- project should work from point of developer view, but needs verification DEVELOPMENT -- project is random state, it might work. BROKEN -- project is known to be not working atm.
Am I right in assuming that BROKEN is a state that would never be shown on the search results? I would maybe favor a different name, like INTERNALUSE or whatever (or having this as an additional state).
Why? I'd like to have my 'playgrounds' tagged in a way to be sure users are not getting there in any way until instructed to do so. I'm not willing to get any bugreports for any such repository. so excluding it intentionally from the search result is a good thing, tagging it as 'BROKEN' would not be the right 'word' for it (internal testing).
k, makes sense to me. But I would just name it "INTERNAL" or "PRIVATE" . bye adrian -- Adrian Schroeter SUSE Linux Products GmbH email: adrian@suse.de -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org
On 04/23/2010 01:24 PM, Adrian Schröter wrote:
Am Freitag, 23. April 2010 13:00:09 schrieb Dominique Leuenberger:
On 4/23/2010 at 10:53, Adrian Schröter<adrian@suse.de> wrote:
STABLE -- project is considered to be ready to use for End-Users TESTING -- project should work from point of developer view, but needs verification DEVELOPMENT -- project is random state, it might work. BROKEN -- project is known to be not working atm.
Am I right in assuming that BROKEN is a state that would never be shown on the search results? I would maybe favor a different name, like INTERNALUSE or whatever (or having this as an additional state).
Why? I'd like to have my 'playgrounds' tagged in a way to be sure users are not getting there in any way until instructed to do so. I'm not willing to get any bugreports for any such repository. so excluding it intentionally from the search result is a good thing, tagging it as 'BROKEN' would not be the right 'word' for it (internal testing).
k, makes sense to me. But I would just name it "INTERNAL" or "PRIVATE" .
"INTERNAL" or "PRIVATE" is fine, but I would stick home:* projects to this state without any option to override this. It would encourage contributions to devel projects and using home:* project as install repo is not good anyway.
bye adrian
-- Best Regards / S pozdravom, Pavol RUSNAK SUSE LINUX, s.r.o openSUSE Boosters Team Lihovarska 1060/12 PGP 0xA6917144 19000 Praha 9, CR prusnak[at]suse.cz http://www.suse.cz -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org
On Mon, Apr 26, 2010 at 9:41 AM, Pavol Rusnak <prusnak@suse.cz> wrote:
On 04/23/2010 01:24 PM, Adrian Schröter wrote:
Am Freitag, 23. April 2010 13:00:09 schrieb Dominique Leuenberger:
On 4/23/2010 at 10:53, Adrian Schröter<adrian@suse.de> wrote:
STABLE -- project is considered to be ready to use for End-Users TESTING -- project should work from point of developer view, but needs verification DEVELOPMENT -- project is random state, it might work. BROKEN -- project is known to be not working atm.
Am I right in assuming that BROKEN is a state that would never be shown on the search results? I would maybe favor a different name, like INTERNALUSE or whatever (or having this as an additional state).
Why? I'd like to have my 'playgrounds' tagged in a way to be sure users are not getting there in any way until instructed to do so. I'm not willing to get any bugreports for any such repository. so excluding it intentionally from the search result is a good thing, tagging it as 'BROKEN' would not be the right 'word' for it (internal testing).
k, makes sense to me. But I would just name it "INTERNAL" or "PRIVATE" .
"INTERNAL" or "PRIVATE" is fine, but I would stick home:* projects to this state without any option to override this. It would encourage contributions to devel projects and using home:* project as install repo is not good anyway.
Are all projects really supposed to pushed out of home projects once they're stable. For instance: I have a OBS home project for open2300. It has very few users and I would not be shocked to find out no one but me has downloaded it, but to my knowledge it is the only place to download a installable package, instead of source. (ie. The home page for the project used to only reference the source. Its a wiki, so I built the package via OBS in my home directory and edited the wiki page to refer to it.) Is something with that small an audience really supposed to be pushed into a more formal repo? If so, which one in my case? fyi: open2300 is a program for reading the data records of a LaCrosse Weather Station via rs-232 port. Greg -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org
On 26/04/10 15:13, Greg Freemyer wrote:
On Mon, Apr 26, 2010 at 9:41 AM, Pavol Rusnak <prusnak@suse.cz> wrote:
"INTERNAL" or "PRIVATE" is fine, but I would stick home:* projects to this state without any option to override this. It would encourage contributions to devel projects and using home:* project as install repo is not good anyway.
Are all projects really supposed to pushed out of home projects once they're stable.
For instance:
I have a OBS home project for open2300. It has very few users and I would not be shocked to find out no one but me has downloaded it, but to my knowledge it is the only place to download a installable package, instead of source.
(ie. The home page for the project used to only reference the source. Its a wiki, so I built the package via OBS in my home directory and edited the wiki page to refer to it.)
Is something with that small an audience really supposed to be pushed into a more formal repo? If so, which one in my case?
fyi: open2300 is a program for reading the data records of a LaCrosse Weather Station via rs-232 port.
Greg
I don't think this proposal is about stopping people from distributing packages via home projects altogether. Instead it is about ensuring users do not unintentionally stumble on a home project via search.oo or similar. This will make it safer to say "just go search for it on search.oo", which right now it is not, because there are development and broken versions visible, and a malicious packager can easily trick the unsuspecting into using bad packages by recreating popular packages in their home project. If you are linking to the home project on external wikis etc. this will do nothing to change that AFAIK. Regards, Tejas -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org
On Mon, Apr 26, 2010 at 12:45 PM, Tejas Guruswamy <masterpatricko@gmail.com> wrote:
On 26/04/10 15:13, Greg Freemyer wrote:
On Mon, Apr 26, 2010 at 9:41 AM, Pavol Rusnak <prusnak@suse.cz> wrote:
"INTERNAL" or "PRIVATE" is fine, but I would stick home:* projects to this state without any option to override this. It would encourage contributions to devel projects and using home:* project as install repo is not good anyway.
Are all projects really supposed to pushed out of home projects once they're stable.
For instance:
I have a OBS home project for open2300. It has very few users and I would not be shocked to find out no one but me has downloaded it, but to my knowledge it is the only place to download a installable package, instead of source.
(ie. The home page for the project used to only reference the source. Its a wiki, so I built the package via OBS in my home directory and edited the wiki page to refer to it.)
Is something with that small an audience really supposed to be pushed into a more formal repo? If so, which one in my case?
fyi: open2300 is a program for reading the data records of a LaCrosse Weather Station via rs-232 port.
Greg
I don't think this proposal is about stopping people from distributing packages via home projects altogether. Instead it is about ensuring users do not unintentionally stumble on a home project via search.oo or similar.
This will make it safer to say "just go search for it on search.oo", which right now it is not, because there are development and broken versions visible, and a malicious packager can easily trick the unsuspecting into using bad packages by recreating popular packages in their home project.
If you are linking to the home project on external wikis etc. this will do nothing to change that AFAIK.
Regards, Tejas
My real goal is long term persistent link to package that does not require login. == details I don't know about now or the future, but in the past you could not link to project from outside because it required login. The choices were to link to a specific package/repo or link to the search page with the package filled in. If that hasn't changed it will be a problem The specific package/repo gets stale after every release and 2 years later points to a dead link. That may seem like a long time, but I discovered it after following other peoples dead links into obs 2 years ago. Who knows how many of them there are now. The link to a search result seems to work fine currently and it refreshes itself as new repos (11.3) are added. But, it I understand this proposal it will not find anything assuming it is accepted. Greg -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org
Am Montag, 26. April 2010 18:45:11 schrieb Tejas Guruswamy:
On 26/04/10 15:13, Greg Freemyer wrote:
On Mon, Apr 26, 2010 at 9:41 AM, Pavol Rusnak <prusnak@suse.cz> wrote:
"INTERNAL" or "PRIVATE" is fine, but I would stick home:* projects to this state without any option to override this. It would encourage contributions to devel projects and using home:* project as install repo is not good anyway.
Are all projects really supposed to pushed out of home projects once they're stable.
For instance:
I have a OBS home project for open2300. It has very few users and I would not be shocked to find out no one but me has downloaded it, but to my knowledge it is the only place to download a installable package, instead of source.
(ie. The home page for the project used to only reference the source. Its a wiki, so I built the package via OBS in my home directory and edited the wiki page to refer to it.)
Is something with that small an audience really supposed to be pushed into a more formal repo? If so, which one in my case?
fyi: open2300 is a program for reading the data records of a LaCrosse Weather Station via rs-232 port.
Greg
I don't think this proposal is about stopping people from distributing packages via home projects altogether. Instead it is about ensuring users do not unintentionally stumble on a home project via search.oo or similar.
yes.
This will make it safer to say "just go search for it on search.oo", which right now it is not, because there are development and broken versions visible, and a malicious packager can easily trick the unsuspecting into using bad packages by recreating popular packages in their home project.
If you are linking to the home project on external wikis etc. this will do nothing to change that AFAIK.
Exactly. If some upstream project is recommending any project and you trust this upstream project it should be save to use it. -- Adrian Schroeter SUSE Linux Products GmbH email: adrian@suse.de -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org
participants (10)
-
Adrian Schröter -
Dominique Leuenberger -
Greg Freemyer -
Lars Müller -
Lubos Lunak -
Pavol Rusnak -
Robert Schweikert -
Stefan Dirsch -
Tejas Guruswamy -
Will Stephenson