launchpad-dev team mailing list archive

["Francis J. Lacoste" <francis.lacoste@xxxxxxxxxxxxx>]

On November 25, 2009, Jonathan Lange wrote:
> On Fri, Nov 20, 2009 at 2:40 PM, Francis J. Lacoste
> 
> <francis.lacoste@xxxxxxxxxxxxx> 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
francis.lacoste@xxxxxxxxxxxxx

Attachment: signature.asc
Description: This is a digitally signed message part.