Mailinglist Archive: opensuse-buildservice (348 mails)
|< Previous||Next >|
Re: [opensuse-buildservice] Project classifications
- From: Robert Schweikert <rschweikert@xxxxxxxxxx>
- Date: Fri, 23 Apr 2010 07:16:10 -0400
- Message-id: <4BD1817A.10301@xxxxxxxxxx>
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:
the openSUSE booster teams has started to improve the
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 :
STABLE -- project is considered to be ready to use for End-Users
TESTING -- project should work from point of developer view, but needs
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,
are meanwhile in a complete broken state ...
Yes, but a handle for complete unmaintained projects need to be supported
This mechanism only gives the active developers a chance to flag their
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
Tagging a project with a given state is IMHO a convenience to mark all
packages in a given project with the same state.
However, default will be "DEVELOPMENT", so all the in-active home: projects
just not be visible in first place.
Robert Schweikert MAY THE SOURCE BE WITH YOU
Software Engineer Consultant LINUX
Making IT Work As One
To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@xxxxxxxxxxxx
For additional commands, e-mail: opensuse-buildservice+help@xxxxxxxxxxxx
|< Previous||Next >|