On November 25, 2009, Jonathan Lange wrote: > On Fri, Nov 20, 2009 at 2:40 PM, Francis J. Lacoste > > <[email protected]> wrote: > > On November 19, 2009, Michael Hudson wrote: > >> > * finding all of the recipes that are associated with a given source > >> > package * finding all of the recipes that are associated with a given > >> > branch * linking to past builds of recipes > >> > * creating recipes for things (esp. SPNs) that don't exist yet. > >> > > >> > There are many traversal paths that satisfy all of these constraints. > >> > https://launchpad.net/+recipe/$RECIPE_ID being the simplest. > >> > >> That seems pretty gross. > > I don't think it's gross. I think recipes need names, and so this > schema is unrealistic. > > (owner, distroseriessourcepackage, recipename) seems about right to > me. I guess there's some code in branchnamespace.py that can be > re-used. > > > And we have a policy in Launchpad (broken in at least one place - > > blueprint vocabulary) not to expose meaningless internal database > > identifiers to end users. > > Where's the policy?
It might one of those unwritten policy. It should probably be documented in the (UI)? Design Conventions, but we don't have such a page either. > > mpt was arguing for a while that merge proposals should be done like > this. Also, we expose database IDs for bugs. > The Bugs case is different in that it's a bug number (which happens to reuse the database identifier). The bug number is well-exposed in the UI. The reason it was used was also because a bug could live in many context and it is impractical to give a nickname to all bugs and try to manage a coherent namespace on top of that. -- Francis J. Lacoste [email protected]
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Mailing list: https://launchpad.net/~launchpad-dev Post to : [email protected] Unsubscribe : https://launchpad.net/~launchpad-dev More help : https://help.launchpad.net/ListHelp
