Hi,
I'm not sure whether this has been given some thought yet.
But it seems that there's an awful lot of build power "wasted" to rebuild packages that don't have users (anymore), or a lot of _links around which are no longer used etc.
Is there possibly some way to prune them from blocking the rebuild power of the system?
Low-key solution: require that each "build & publish" bit is refreshed manually every N weeks?
Regards, Lars
Resend, to list this time, not just Lars.
On Tue, Aug 11, 2009 at 8:58 AM, Lars Marowsky-Breelmb@suse.de wrote:
Hi,
I'm not sure whether this has been given some thought yet.
But it seems that there's an awful lot of build power "wasted" to rebuild packages that don't have users (anymore), or a lot of _links around which are no longer used etc.
Is there possibly some way to prune them from blocking the rebuild power of the system?
Low-key solution: require that each "build & publish" bit is refreshed manually every N weeks?
Regards, Lars
Something similar was mentioned recently and I was one of several against it from a end-user perspective.
At a minimum it should be download activity that marks a project inactive, not packager activity. Even better a lack of both downloads and packager activity would be the best indicator.
ie. What if the project is stable and packager simply has nothing to do, but is useful and is getting downloaded. Why should the project no longer be built against the latest sources?
Also, is there a way to significantly drop the priority of these packages in the build sequence instead of totally shutting them down? Maybe have a "green" server that does not generate lots of heat just for compiling these low priority jobs?
Greg -- Greg Freemyer
On 2009-08-11T19:21:48, Greg Freemyer greg.freemyer@gmail.com wrote:
At a minimum it should be download activity that marks a project inactive, not packager activity. Even better a lack of both downloads and packager activity would be the best indicator.
The details of the method used to determine liveliness can be discussed further. Please don't argue about the color yet, lets first decide whether the bike shed gets build or not ;-)
The key issue which needs addressing here is that the outdated/unused projects hog build service resources, which makes it impossibly slow to use for more active projects - the turn-around times can measure days if your unlucky, which is just not acceptable.
Also, is there a way to significantly drop the priority of these packages in the build sequence instead of totally shutting them down? Maybe have a "green" server that does not generate lots of heat just for compiling these low priority jobs?
That would also work of course. Adjusting the priority based on the commit activity, with a sliding scale or something.
Just using the download frequency is not sufficient; that works for long-term trends and identifying projects which may be prunable, but the developer sitting there trying to build the next revision of a new project (which hasn't been downloaded much yet) is going to be throughly annoyed.
Regards, Lars
On Wed, Aug 12, 2009 at 7:18 AM, Lars Marowsky-Breelmb@suse.de wrote: <snip>
Also, is there a way to significantly drop the priority of these packages in the build sequence instead of totally shutting them down? Maybe have a "green" server that does not generate lots of heat just for compiling these low priority jobs?
That would also work of course. Adjusting the priority based on the commit activity, with a sliding scale or something.
Just using the download frequency is not sufficient; that works for long-term trends and identifying projects which may be prunable, but the developer sitting there trying to build the next revision of a new project (which hasn't been downloaded much yet) is going to be throughly annoyed.
For what it is worth (2 cents? less?), my high-level statement is:
I'm in favor of adjusting build priorities based on various packager / end-user activities. I'm not in favor of a boolean go / no go decision based on same.
Greg
Lars Marowsky-Bree wrote:
I'm not sure whether this has been given some thought yet.
But it seems that there's an awful lot of build power "wasted" to rebuild packages that don't have users (anymore), or a lot of _links around which are no longer used etc.
Is there possibly some way to prune them from blocking the rebuild power of the system?
I'd find that useful for devel projects that only serve as staging for another repo like Factory at least. Build could be disabled if the link specifies no patch in that case.
cu Ludwig
Am Donnerstag, 20. August 2009 14:29:28 schrieb Ludwig Nussel:
Lars Marowsky-Bree wrote:
I'm not sure whether this has been given some thought yet.
But it seems that there's an awful lot of build power "wasted" to rebuild packages that don't have users (anymore), or a lot of _links around which are no longer used etc.
Is there possibly some way to prune them from blocking the rebuild power of the system?
I'd find that useful for devel projects that only serve as staging for another repo like Factory at least. Build could be disabled if the link specifies no patch in that case.
not really, there is quite often the usecase to rebuild eg the Factory source against openSUSE 11.1 distribution.
But I am current build-disable all home: projects without any modification since 1 year (as announced here before).
Non home: projects get currently processed manually.
bye adrian
buildservice@lists.opensuse.org
-
Adrian Schröter -
Greg Freemyer -
Lars Marowsky-Bree -
Ludwig Nussel