[maemo-developers] extras: promotion interface

[From: Graham Cobb]

On Wednesday 06 February 2008 14:47:07 Levi Bard wrote:
> > After quite some time of fighting with myself as well as getting
> > encouragement from certain members of this community, I'm humbly offer
> > to your attention a first {alpha,beta} release of a manual promotion
> > interface.

Today's emails prompted me to go and take a look at this as well.  Good start!

> Comments:
> * Is it necessary to separate each package into source/armel/i386/etc?
>  Why not just display the package name (e.g. xmaeme), perhaps with a
> link to click to view the contained files, and/or an asterisk if
> there's no source?  Is there any situation in which, say, the source
> component would be promoted, but the armel component wouldn't?

Maybe.  There is the question of different architectures and different 
packages, all built from the same source.  The status of them may be 
different (and some may only be of interest to developers).  

I quite like the idea of being able to control the promotion of individual 
packages.  On the other hand, if we ever implement an autobuilder I guess 
that will go away because once the source is promoted everything would get 
built.  So, it isn't critical to me.

I do think that if there is a source package available it should not be 
possible to promote any package built from that source without promoting the 
source as well.  The source should always be available in the same place.  
Maybe the GUI should only allow promotions to be requested on source 
packages -- to allow for the autobuilder in the future -- in the short term 
all packages built from that source would also be automatically promoted.

> * Ability to demote and/or rollback to a previous version (with comments)

I guess so, but demotion must be a very rare and exceptional case, because of 
the potential impact on existing users who have the package installed and on 
other packages which have been built against the latest version of the 
package (particularly important for libraries). I'm not sure a GUI is needed 
for that -- it could be a task done manually by someone.

> * A way to view a package's dependencies
>   - A way to verify whether all of a package's dependencies are either
> in extras or in the promotion queue
>   - A way to simultaneously promote a package and all of its dependencies

In addition to straight dependency management, it should be possible to group 
a set of packages which are treated together.  The GPE suite consists of 
about 29 packages with a complex set of dependencies and I would want to make 
sure that they are always promoted together.  A user might install any one or 
more of the 8 GPE applications but if they are using two of them I would 
prefer they had both been built against the (same) installed library version.

If necessary we could handle complex application suites separately (possibly 
with direct upload to extras), to avoid adding complexity to this interface 
in the short term.  I do think that for GPE I would want either direct access 
or a grouping feature in the GUI, to avoid mistakes.

> That's all I can think of for now.  Great work!

One requirement that I think is important is an archive mechanism.  When a 
package is promoted, the previous version should be archived somewhere.  It 
could remain in the repository or be placed in a special archive repository.  
It would be needed if a demotion rollback was needed but, also, the community 
might want/need access to it in the future.

It was not clear to me from the demo application whether multiple versions of 
the same package would be handled.  In fact, what is the current policy both 
for the extras and extras-devel repositories?  Do they store multiple 
versions at all?

Graham