> 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).
I think there is something in point #2. If we could make WIP sticky or initially settable, I'd be happy if WIP cleared the CI bits and didn't trigger running of CI. I think if it's not ready for human review, it's probably not ready for robot review either. -Sean +1 to not automatically running CI against a WIP patch, though I would still like to be able to issue a “recheck”-like comment and get CI to run against a WIP patch. The only concern with making WIP “sticky” is that the current “workflow” method of WIP would not be sufficient, as only the person marking the review as “WIP” could clear it (same as the -2 on Code Review). This would be an argument to go to the WIP plugin that works (ish) like our own WIP system. —Morgan
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
