Mailinglist Archive: opensuse-buildservice (137 mails)

< Previous Next >
Re: [opensuse-buildservice] Feature request
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.

To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@xxxxxxxxxxxx
To contact the owner, e-mail: opensuse-buildservice+owner@xxxxxxxxxxxx

< Previous Next >
Follow Ups