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:
Agreed.
Please file a feature request / openFATE request so we can vote ? :-)
Vincent
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 projects that are not active maintained anymore. It does not make sense to increase the build load by adding new build targets but now one cares about the content.
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.
Later, Robert
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. Later, Robert -- Robert Schweikert MAY THE SOURCE BE WITH YOU SUSE-IBM Software Integration Center LINUX Tech Lead rjschwei@suse.com rschweik@ca.ibm.com 781-464-8147 -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-buildservice+owner@opensuse.org