[maemo-developers] Autobuilder repository priority ?

From: Ed Bartosh bartosh at gmail.com
Date: Tue Nov 3 10:25:27 EET 2009
2009/11/3 Graham Cobb <g+770 at cobb.uk.net>:
> On Monday 02 November 2009 21:52:48 Jeremiah Foster wrote:
>> On Nov 2, 2009, at 10:27, Ed Bartosh wrote:
>> > 2009/11/2 Jeremiah Foster <jeremiah at jeremiahfoster.com>:
>> >> On Nov 1, 2009, at 18:05, Ed Bartosh wrote:
>> >>> Idea of having separate queue for Extras updates sounds more
>> >>> promising
>> >>> to me. Developers might become confused with all this set of
>> >>> repositories, queues and processes, but the idea is good. I support
>> >>> this.
>> >
>> > What about this? Can we have separate queue for updates? Any other
>> > ideas?
>> Can you explain how this might work and it's advantages? I am not
>> against it aside from the fact that I think another repo is confusing.
>> Is the proposal to create a repo called extras-updates which would
>> hold only updates to software that has already existed in the repos? I
>> don't see how that is different from just updating the existing
>> package with new software. If you want to pull in different version
>> numbers than what exists why would you need a separate repo?
> Sorry, like Jeremiah I am now a bit confused.  Can you, Ed, please summarise
> what this proposal is?  You mention separate queue but which queue are you
> referring to?  Does the suggestion involve additional repositories? And/or
> does it involve differnet rules for which repositories will be in scope
> during a build?  Or what.
As I understood Attila he proposed to create separate autobulder
incoming queue for Extras updates.
If packages are uploaded to this queue they're built using only Extras
and SDK repos and put into extras-devel.
As a result they won't depend on unstable packages from Extras-devel
and can go to extras-testing and then to Extras faster.

As I already mentioned I'm also a bit afraid of extra complexity and
possible confusion, but I think this idea at least worth to be

More information about the maemo-developers mailing list