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 -- 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