Open Stack

I’ve had this question asked numerous times (by previous coworkers, people interested in contributing to OpenStack, etc). The general feeling has always been that the individual is concerned about 3 things when considering drafts in gerrit.

1. Patch is very much WIP and doesn’t need to be reviewed yet or is meant to be a collaboration between a couple individuals first
2. Since a patch is very much WIP, there is concern about consuming CI resources with needless testing.
3. The code is “example”, “toy”, or “exploratory” (not planning to submit to the project, but not private/proprietary)

The general advice I give to people is to post the patches (especially at checkpoints, e.g. taking a break for the night) and ensure that they are running the tests that they can locally. I also explain the WIP process for a patch. Usually the combination is good enough to convince them that a “Draft” isn’t really needed. If there is still concern about posting the patch to gerrit prematurely (option 3 above), I recommend using another system to collaborate on the initial patch such as what I use my GitHub account for (out-of-tree development / examples / playing with code that won’t ever be submitted to the main repositories).

I, for one am very pleased that Drafts are now disabled. I never liked the feature (it felt like it was missing a chunk of functionality to be really useful).

Cheers,
Morgan
—
Morgan Fainberg


From: Clark Boylan clark.boylan at gmail.com
Reply: OpenStack Development Mailing List (not for usage questions) openstack-dev at lists.openstack.org
Date: May 31, 2014 at 12:33:33
To: OpenStack Development Mailing List (not for usage questions) openstack-dev at lists.openstack.org
Subject:  Re: [openstack-dev] [All] Disabling Pushes of new Gerrit Draft Patchsets  

There isn't an option to push non public patches (and there really  
wasn't before either, drafts are not properly private and this false  
expectation is one of the reasons we have disabled them). Currently  
the recommended alternative is work in progress. The code cannot merge  
with a work in progress vote but it can otherwise be reviewed and  
tested. I think we would like to have changes tested even if they are  
marked as work in progress because it is useful feedback.  

Is there a specific use case where not running tests is desirable?  

Clark  

On Sat, May 31, 2014 at 6:45 AM, Eugene Nikanorov  
<enikanorov at mirantis.com> wrote:  
> Hi,  
>  
> I might be posting a question to a wrong thread, but what would be the  
> option to push a patch that I would like to share only with certain group of  
> people. In other words, is there still an option to push non-public patches?  
> I wouldn't like such patches to affect gerrit stream or trigger CIs, but  
> gerrit could still be used for regular reviewing process.  
>  
> Thanks,  
> Eugene.  
>  
>  
> On Sat, May 31, 2014 at 12:51 AM, Sergey Lukjanov <slukjanov at mirantis.com>  
> wrote:  
>>  
>> Yay!  
>>  
>> No more weird CR chains.  
>>  
>> On Fri, May 30, 2014 at 9:32 PM, Clark Boylan <clark.boylan at gmail.com>  
>> wrote:  
>> > On Wed, May 21, 2014 at 4:24 PM, Clark Boylan <clark.boylan at gmail.com>  
>> > wrote:  
>> >> Hello everyone,  
>> >>  
>> >> Gerrit has long supported "Draft" patchsets, and the infra team has  
>> >> long  
>> >> recommended against using them as they are a source of bugs and  
>> >> confusion (see below for specific details if you are curious). The  
>> >> newer  
>> >> version of Gerrit that we recently upgraded to allows us to prevent  
>> >> people from pushing new Draft patchsets. We will take advantage of this  
>> >> and disable pushes of new Drafts on Friday May 30, 2014.  
>> >>  
>> >> The impact of this change should be small. You can use the Work in  
>> >> Progress state instead of Drafts for new patchsets. Any existing  
>> >> Draft patchsets will remain in a Draft state until it is published.  
>> >>  
>> >> Now for the fun details on why drafts are broken.  
>> >>  
>> >> * Drafts appear to be "secure" but they offer no security. This is bad  
>> >> for user expectations and may expose data that shouldn't be exposed.  
>> >> * Draft patchsets pushed after published patchsets confuse reviewers as  
>> >> they cannot vote with a value because the latest patchset is hidden.  
>> >> * Draft patchsets confuse the Gerrit event stream output making it  
>> >> difficult for automated tooling to do the correct thing with Drafts.  
>> >> * Child changes of Drafts will fail to merge without explanation.  
>> >>  
>> >> Let us know if you have any questions,  
>> >>  
>> >> Clark (on behalf of the infra team)  
>> >  
>> > Heads up everyone, this is now in effect and pushes of new draft  
>> > patchsets have been disabled.  
>> >  
>> > Thanks,  
>> > Clark  
>> >  
>> > _______________________________________________  
>> > OpenStack-dev mailing list  
>> > OpenStack-dev at lists.openstack.org  
>> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev  
>>  
>>  
>>  
>> --  
>> Sincerely yours,  
>> Sergey Lukjanov  
>> Sahara Technical Lead  
>> (OpenStack Data Processing)  
>> Principal Software Engineer  
>> Mirantis Inc.  
>>  
>> _______________________________________________  
>> OpenStack-dev mailing list  
>> OpenStack-dev at lists.openstack.org  
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev  
>  
>  
>  
> _______________________________________________  
> OpenStack-dev mailing list  
> OpenStack-dev at lists.openstack.org  
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev  
>  

_______________________________________________  
OpenStack-dev mailing list  
OpenStack-dev at lists.openstack.org  
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140531/ce92da46/attachment.html>