On Sep 19, 2017 01:22, "Greg Sheremeta" <gsher...@redhat.com> wrote:
On Mon, Sep 18, 2017 at 3:42 PM, Roy Golan <rgo...@redhat.com> wrote: > > On Mon, 18 Sep 2017 at 22:30 Yaniv Kaul <yk...@redhat.com> wrote: > >> Here[1]: >> "Anyone can send a patch >> > That's no longer true. We have a whitelist. [2][3] Small correction, anyone can send a patch, only people from the whitelist can trigger CI jobs on it, for reasons discussed before, mostly security related. > Initially a patch should be sent as draft" >> > I think we should edit that to be more along the lines of "consider initially posting as a draft" with guidelines to assist the decision. > A draft is hidden from the public, why is it better to send as such? >> > I've sent draft patches for 2 reasons. 1. I made progress on something and want to preserve it, but it's so WIP that I wouldn't want anyone to see it. That might be because it could confuse people, or it might be that the code is a prototype and/or so terrible that I'd be embarrassed if anyone saw it :D Lately I'm more likely to 'git format-patch | gdrive upload -' if it's something in this category. 2. I don't want to waste CI resources on something. Sometimes related to 1. > I see few advantages and they all drawn from the assumption the initial > patchset is always some sort of work in progress in really most of the > cases: > 1. It doesn't invoke automation and waste resources. First the developer > should run it and be passed the checkstyle/pep/other errors locally. > 2. Default reviewers feature hopefully will put the reviewers in place > automatically so it not hidden. > Hmm, I believe the "hopefully" doesn't work. A few weeks ago I got a notification that I had a draft to look at [because I was a default reviewer], but when I followed the link, I received a "not found" error. Best wishes, Greg [2] http://lists.ovirt.org/pipermail/devel/2017-February/029633.html [3] https://ovirt-jira.atlassian.net/browse/OVIRT-1154 > 3. After the patch is bit more mature it is worth publishing to get more > reviews. Half baked or controversial patches may be costly to review. After > they are published the reviewer can expect higher quality and can estimate > better the effort in review > > IMHO we don't use this practice enough. > > TIA, >> Y. >> >> [1] https://www.ovirt.org/develop/dev-process/working-with-gerrit/ >> _______________________________________________ >> Devel mailing list >> Devel@ovirt.org >> http://lists.ovirt.org/mailman/listinfo/devel > > > > > _______________________________________________ > Devel mailing list > Devel@ovirt.org > http://lists.ovirt.org/mailman/listinfo/devel > _______________________________________________ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
_______________________________________________ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel