← Back to team overview

launchpad-dev team mailing list archive

Re: Private Projects LEP


On Tue, Jul 31, 2012 at 8:06 AM, Aaron Bentley <aaron@xxxxxxxxxxxxx> wrote:
> Hash: SHA1
> On 12-07-30 03:10 PM, Robert Collins wrote:
>> error when a name is blacklisted identical to the error when the
>> name is already taken.
> We could certainly blacklist 'canonical*', etc without raising
> suspicion.  But would we blacklist arbitrary names in order to conceal
> the fact that some of those names belonged to private projects?

I don't think we need to - we don't need to publish the blacklist.

>> Another would be to have projects namespaced under their owners,
>> which is the approach github has taken, and that neatly resolves a
>> bunch of issues around namespace ownership - but raises as many as
>> it solves when you consider our goal around consolidating upstream
>> communities - bridging the gap.
> But surely, private projects don't want to participate in upstream
> communities?

They don't, but the system design - in particular how we identify
projects (a flat globally shared namespace) is optimised for a
different set of scenarios. => we have conflicting use cases. We can:
 - do different things for different use cases
 - do one thing and try to make that one thing something that
satisfies all the use cases

I'm not suggesting we do different things right now, I'm trying to
show that the situation we have today is a corollary of the choice to
have a flat global namespace, and that that choice was taken to
prevent fragmentation - there shall be only one 'Plone' in LP - but it
directly conflicts with 'I can have a project called Plone that is
invisible to everyone else' because of the guessability aspect, which
wouldn't exist if the structure were different. Depending on how
important it is, we could look at bringing in a structure for some or
all projects to support unguessability project names - e.g. user/team
scoped projects/distros. Thats /not/ trivial, nor is it a trivial
discussion to have :)


Follow ups