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 _______________________________________________ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
