launchpad-dev team mailing list archive
-
launchpad-dev team
-
Mailing list archive
-
Message #09511
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