Mailinglist Archive: opensuse-buildservice (137 mails)

< Previous Next >
Re: [opensuse-buildservice] Feature request
On 12/08/2011 06:58 PM, Brian K. White wrote:
On 12/7/2011 10:12 AM, Robert Schweikert wrote:
On 12/07/2011 03:11 AM, Adrian Schröter wrote:
Am Mittwoch, 7. Dezember 2011, 07:55:31 schrieb Vincent Petry:

Please file a feature request / openFATE request so we can vote ? :-)


On 07/12/2011 00:02, Robert Schweikert wrote:
On 12/06/2011 05:39 PM, Lars Müller wrote:
On Tue, Dec 06, 2011 at 05:09:41PM -0500, Robert Schweikert wrote:
We should automatically enable the new release branch as a build
target for all projects that build against factory when we branch.

No, I do not want to do this. The reason is that there are quite some
that are not active maintained anymore. It does not make sense to
the build load by adding new build targets but now one cares about the

In the current way these projects do fade out and free the resources
to others

But the current system penalizes those that actively work on their
projects as the active maintainers have to manually turn on a new build
target. There must be a better heuristic for us to determine which
projects should fade away.

Penalizing those that do maintain their projects because others do not
doesn't appear to be the best approach to me.

I created: 313057

I understand your argument about old stuff, and people that have long
left the project, and that we do not want to keep their stuff around
forever, I agree. However, the current approach is a "poor man" approach
to solving this issue.

Interestingly enough, it appears that I just yesterday ran across such a
case. Take a look at the system:aoetools project.This has only one
maintainer and there does not appear to be any activity. Thus using your
theory, this will just fade away over time. However, this project also
builds for SLE, thus there's no fading away (or fading is excruciatingly
slow) and the project will live on for as long as SLE lives in OBS.

One would think that we can construct a "fade away" rule based on some
other heuristic, maybe activity. I realize that some code is slow to
change upstream and thus no activity is needed in OBS, thus creating a
time based heuristic may be rather difficult, is 2 years acceptable,
maybe 3 years. I have no idea.

Another option might be to send an e-mail to everyone listed as
maintainer once a year, only one e-mail per maintainer, not one e-mail
per maintainer per project. When the maintainer replies she/he is
considered active, nothing happens. If the e-mail bounces we'll try
again in a week. For e-mails that bounce a second time or that get no
response within a month we will automatically remove those maintainers
from all projects in OBS, projects that only have that one person as a
maintainer get removed.

From a maintainer point of view this is much easier than having to go
through and flip the new build target on manually every time we have a
new release. Getting an e-mail once a year where I just hit "Reply" and
"Send" is really not very bothersome.


No. A self maintaining system has to always be trimming off dead stuff
and require active action to keep active items alive. I don't see how
it's very much to ask. It doesn't "penalize" anyone. 3 times per year
you update each project you care about. It can be almost completely
automated even.

It's too easy for users to create projects and then abandon them without
actually removing them to have all of those projects automatically
acreting new build targets forever.

Then too, if you would have the new build targets added automatically,
would you also have the no-longer supported ones removed automatically?
I would highly object to that since those discontinued targets are 75%
of the reason I even use OBS at all in the first place.

But maybe that actually provides an answer for both of us.

The discontinued build targets DO in fact "fall off" all projects
automatically when they are renamed from foo to DISCONTINUED:foo

I have to go and manually update all my projects 3 times per year per
project to add the just-got-discontinued build targets back on.

So maybe a similar rule can be made, based on something simple like a
naming convention, that results in building for all currently supported
targets, or all currently supported targets meeting some other criteria
also like excluding, or only including, openSUSE*, SLE*, *86 + noarch,
other archs, etc..

But there should be no option that makes it possible for a project to
just grow more build targets automatically that never fall off.

Well, I did propose two approaches to address the "fall off problem". I even stated that I agree that we need a solution and cannot perpetuate unmaintained projects. Therefore, any specific comments on what might be unfeasible with the proposed approaches to get project to "fade away" would be a constructive contribution to the discussion. However, ignoring those proposals and stating that things with the proposed approach never "fall off" ignores a part of the proposal.


SUSE-IBM Software Integration Center LINUX
Tech Lead
To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@xxxxxxxxxxxx
To contact the owner, e-mail: opensuse-buildservice+owner@xxxxxxxxxxxx

< Previous Next >
Follow Ups