← Back to team overview

launchpad-dev team mailing list archive

Re: Who can create private bugs and branches?

 

On 06/27/2012 09:38 AM, Ted Gould wrote:
> On Wed, 2012-06-27 at 17:41 +1000, William Grant wrote:
>> Ideas? Cases that I haven't considered? Anything?
> 
> Yes :-)
> 
> So the use case that we have in Product Strategy is a little bit
> different.  We have generally public projects with public bugs and
> public branches, but occasionally we need to do private work on those
> projects.  For instance, if we had a new form factor coming out that we
> wanted to release with a partner (Ubuntu for Toasters with Whirlpool)
> that would need customization of an indicator.  So we'd want a private
> branch(s) of that indicator for that customization work.

We will allow projects with commercial subscriptions to make any branch
private (proprietary). We might get this change into production next week.

> That seems simple enough, where it gets a bit tricky as that we really
> what a private integration branch and the ability for developers to
> create private branches that'll be merged into that one.  This way we
> can continue with our code review policies and set up Jenkins to
> auto-land and do daily builds of that integration branch.

I think most of this case is solved with sharing.
1. The project must have a commercial subscription so that it can have
proprietary branches
2. Anyone that the project shares Proprietary information with can see
the existing branches and create new proprietary branches.
3. I think you want to link the integration branch to a series so that
stacking ensures the feature branches are proprietary...and ensure they
cannot accidentally be made public.

I think you are waiting for the read/write sharing beta with branches to
prove this. It is a few weeks away. You will want to share proprietary
with mainliners, drivers, and ~canonical, then setup the series.

> Ideally, but not required, we'd like to be able to make all of those
> branches/merges public as we're not interested in hiding them long term
> only to achieve certain time-based business/marketing goals.

Revisions merged into public branches would be public. the revision only
in the proprietary branch will remain private.



-- 
Curtis Hovey
http://launchpad.net/~sinzui



Attachment: signature.asc
Description: OpenPGP digital signature


References