[opensuse-buildservice] Feature request
Hi, We should automatically enable the new release branch as a build target for all projects that build against factory when we branch. Yes, one makes the assumption that a given project wants to support/build against the next release, but I think this may be more applicable than the assumption we make now, which is that people do not want to build against the new release. This avoids the hassle of maintainers having to go in and turning this on explicitly. My guess would be that there are fewer maintainers that do not want this behavior than there are maintainers that want this behavior. The other alternative would be to add yet another setting to the meta data of a project that says "build-new-target-on-release-branching" then maintainers can choose this depending on their preference. I don't think we need such a flag, but it gives control to project maintainers. 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
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.
How about doing so if openSUSE (oS) Factory and the new version -1 are enabled? If I had 11.4 oS 11.4 and Factory enabled an automatism to enable oS 12.1 builds as soon as it is available as target makes sense to me. If I have oS Factory enabled for builds but nothing else we should keep Factory alone.
Yes, one makes the assumption that a given project wants to support/build against the next release, but I think this may be more applicable than the assumption we make now, which is that people do not want to build against the new release.
This avoids the hassle of maintainers having to go in and turning this on explicitly. My guess would be that there are fewer maintainers that do not want this behavior than there are maintainers that want this behavior.
I guess so too.
The other alternative would be to add yet another setting to the meta data of a project that says "build-new-target-on-release-branching" then maintainers can choose this depending on their preference. I don't think we need such a flag, but it gives control to project maintainers.
You're right, we should try to keep it simple. Lars -- Lars Müller [ˈlaː(r)z ˈmʏlɐ] Samba Team SUSE Linux, Maxfeldstraße 5, 90409 Nürnberg, Germany
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.
How about doing so if openSUSE (oS) Factory and the new version -1 are enabled?
If I had 11.4 oS 11.4 and Factory enabled an automatism to enable oS 12.1 builds as soon as it is available as target makes sense to me.
If I have oS Factory enabled for builds but nothing else we should keep Factory alone.
Yes, this makes sense and is a better heuristic.
Yes, one makes the assumption that a given project wants to support/build against the next release, but I think this may be more applicable than the assumption we make now, which is that people do not want to build against the new release.
This avoids the hassle of maintainers having to go in and turning this on explicitly. My guess would be that there are fewer maintainers that do not want this behavior than there are maintainers that want this behavior.
I guess so too.
The other alternative would be to add yet another setting to the meta data of a project that says "build-new-target-on-release-branching" then maintainers can choose this depending on their preference. I don't think we need such a flag, but it gives control to project maintainers.
You're right, we should try to keep it simple.
Lars
-- 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
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.
How about doing so if openSUSE (oS) Factory and the new version -1 are enabled?
If I had 11.4 oS 11.4 and Factory enabled an automatism to enable oS 12.1 builds as soon as it is available as target makes sense to me.
If I have oS Factory enabled for builds but nothing else we should keep Factory alone.
Yes, this makes sense and is a better heuristic.
Yes, one makes the assumption that a given project wants to support/build against the next release, but I think this may be more applicable than the assumption we make now, which is that people do not want to build against the new release.
This avoids the hassle of maintainers having to go in and turning this on explicitly. My guess would be that there are fewer maintainers that do not want this behavior than there are maintainers that want this behavior.
I guess so too.
The other alternative would be to add yet another setting to the meta data of a project that says "build-new-target-on-release-branching" then maintainers can choose this depending on their preference. I don't think we need such a flag, but it gives control to project maintainers.
You're right, we should try to keep it simple.
Lars
-- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-buildservice+owner@opensuse.org
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 bye adrian
How about doing so if openSUSE (oS) Factory and the new version -1 are enabled?
If I had 11.4 oS 11.4 and Factory enabled an automatism to enable oS 12.1 builds as soon as it is available as target makes sense to me.
If I have oS Factory enabled for builds but nothing else we should keep Factory alone.
Yes, this makes sense and is a better heuristic.
Yes, one makes the assumption that a given project wants to support/build against the next release, but I think this may be more applicable than the assumption we make now, which is that people do not want to build against the new release.
This avoids the hassle of maintainers having to go in and turning this on explicitly. My guess would be that there are fewer maintainers that do not want this behavior than there are maintainers that want this behavior.
I guess so too.
The other alternative would be to add yet another setting to the meta data of a project that says "build-new-target-on-release-branching" then maintainers can choose this depending on their preference. I don't think we need such a flag, but it gives control to project maintainers.
You're right, we should try to keep it simple.
Lars -- Adrian Schroeter SUSE Linux Products GmbH email: adrian@suse.de
-- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-buildservice+owner@opensuse.org
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
On Wed, 2011-12-07 at 10:12 -0500, 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
+1 Yours sincerely, Roger Oberholtzer OPQ Systems / Ramböll RST Office: Int +46 10-615 60 20 Mobile: Int +46 70-815 1696 roger.oberholtzer@ramboll.se ________________________________________ Ramböll Sverige AB Krukmakargatan 21 P.O. Box 17009 SE-104 62 Stockholm, Sweden www.rambollrst.se -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-buildservice+owner@opensuse.org
On Wed, Dec 07, 2011 at 04:35:16PM +0100, Roger Oberholtzer wrote:
On Wed, 2011-12-07 at 10:12 -0500, Robert Schweikert wrote: [ 8< ]
I created: 313057
Good. Even better would have been to add pointers to the list archive cause people reading the feature request initally would be able to follow the discussion much easrier or in a better way.
+1
@Roger: Have you voted inside of fate too? Cause giving your +1 here doesn't matter at all. Lars -- Lars Müller [ˈlaː(r)z ˈmʏlɐ] Samba Team SUSE Linux, Maxfeldstraße 5, 90409 Nürnberg, Germany
Am 08.12.2011 14:08, schrieb Lars Müller:
On Wed, Dec 07, 2011 at 04:35:16PM +0100, Roger Oberholtzer wrote:
On Wed, 2011-12-07 at 10:12 -0500, Robert Schweikert wrote: [ 8< ]
I created: 313057 Good.
Even better would have been to add pointers to the list archive cause people reading the feature request initally would be able to follow the discussion much easrier or in a better way.
+1 @Roger: Have you voted inside of fate too? Cause giving your +1 here doesn't matter at all.
Lars +1
https://features.opensuse.org/313057 -- Christian ---------------------------------------------------- - Please do not 'CC' me on list mails. Just reply to the list :) ---------------------------------------------------- Der ultimative shop für Sportbekleidung und Zubehör http://www.sc24.de ---------------------------------------------------- -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-buildservice+owner@opensuse.org
On Thu, 2011-12-08 at 14:08 +0100, Lars Müller wrote:
+1
@Roger: Have you voted inside of fate too? Cause giving your +1 here doesn't matter at all.
Done. Yours sincerely, Roger Oberholtzer OPQ Systems / Ramböll RST Office: Int +46 10-615 60 20 Mobile: Int +46 70-815 1696 roger.oberholtzer@ramboll.se ________________________________________ Ramböll Sverige AB Krukmakargatan 21 P.O. Box 17009 SE-104 62 Stockholm, Sweden www.rambollrst.se -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-buildservice+owner@opensuse.org
On 12/08/2011 08:08 AM, Lars Müller wrote:
On Wed, Dec 07, 2011 at 04:35:16PM +0100, Roger Oberholtzer wrote:
On Wed, 2011-12-07 at 10:12 -0500, Robert Schweikert wrote: [ 8< ]
I created: 313057
Good.
Even better would have been to add pointers to the list archive cause people reading the feature request initally would be able to follow the discussion much easrier or in a better way.
link to the discussion added in openFate
+1
@Roger: Have you voted inside of fate too? Cause giving your +1 here doesn't matter at all.
Lars
-- 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
On Fri, Dec 09, 2011 at 08:38:38AM -0500, Robert Schweikert wrote:
On 12/08/2011 08:08 AM, Lars Müller wrote:
On Wed, Dec 07, 2011 at 04:35:16PM +0100, Roger Oberholtzer wrote:
On Wed, 2011-12-07 at 10:12 -0500, Robert Schweikert wrote: [ 8< ]
I created: 313057
Good.
Even better would have been to add pointers to the list archive cause people reading the feature request initally would be able to follow the discussion much easrier or in a better way.
link to the discussion added in openFate
Thanks! I thought I've did this before. But it looks like I'm too stupid to use a web based user interface. :/ Lars -- Lars Müller [ˈlaː(r)z ˈmʏlɐ] Samba Team SUSE Linux, Maxfeldstraße 5, 90409 Nürnberg, Germany
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. -- bkw -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-buildservice+owner@opensuse.org
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
On Fri, Dec 09, 2011 at 08:33:18AM -0500, Robert Schweikert wrote: [ 8< ]
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.
All this doesn't matter as Brian adds his comment here and not to https://features.opensuse.org/313057 As long as he doesn't vote on this nobody will care. ;) Unfortunately we'll miss his valued input. But life is hard ... Lars -- Lars Müller [ˈlaː(r)z ˈmʏlɐ] Samba Team SUSE Linux, Maxfeldstraße 5, 90409 Nürnberg, Germany
participants (7)
-
Adrian Schröter -
Brian K. White -
Christian -
Lars Müller -
Robert Schweikert -
Roger Oberholtzer -
Vincent Petry