One of the design goals in Conary's "promote" process is to rewrite all trove references as if they existed on the target label, where that makes sense, in order to avoid references that expose the development process. This was really designed for a small number of packages and proprietary OEM processes. It's not particularly valuable for Foresight.
With system model, since packages are found via groups, it really doesn't matter much where the packages live. I'd like to propose that in FL3, we have separate labels for groups and packages. When we promote groups, it will be quick because we will be promoting only the groups, not the packages. So what is right now a process that takes an hour or more (potentially delaying security updates and bug fixes), should take minutes at most. If we don't promote packages at all, what we would lose is the easy ability to rebuild packages on intermediary stages; for example, doing a quick security update on an older revision off the QA branch when development has moved on but isn't ready to release. There is a hybrid model, in which we also use separate labels for packages and groups, and we do promote packages when moving from Development to QA, but we do not when moving packages from QA to release. This would make promotes from Development to QA take on the order of an hour (as they do now) but allow quick releases of security updates from the QA stage if necessary. Concrete example: Groups built on @fl:3-devel, promoted to @fl:3-qa, promote to @fl:3 Packages built on @fl:3p-devel and promoted to @fl:3p when groups are promoted from @fl:3-devel to @fl:3-qa, and not promoted at all when groups are promoted from @fl:3-qa to @fl:3 We can rebuild packages on @fl:3p against @fl:3-qa or @fl:3 groups, and groups on @fl:3-qa, if we need to get an urgent security or critical bug fix out in minutes. Thoughts? _______________________________________________ Foresight-devel mailing list Foresight-devel@lists.rpath.org http://lists.rpath.org/mailman/listinfo/foresight-devel
