On 03/18/16 13:43, David Woodhouse wrote: > On Fri, 2016-03-18 at 13:30 +0100, Laszlo Ersek wrote: >> >> Our workflow should not be centered on github pull requests in any case, >> so I don't see the point in testing them out. > > Well, thanks for destroying the test I spent this morning setting up, > because you don't believe it would have useful results.
I feel very bad about it. My main reason was that I found it too risky, setting a precedent. > I happen to disagree about using github pull requests. Every change > there triggers an email, Except my own actions. I'm already watching the github issue tracker and get emails of the actions of others. No emails about my own actions. It makes the email audit trail completely unusable. > and we can set things up so that email is also > copied to the mailing list. So it's just as well-archived as the other > list traffic, and we don't have to worry about github.com disappearing > in a puff of smoke any more than we already did. > >> workflow centered on pull requests that are sent to the mailing list >> should be tested out, and I'd like to work with you on that. > > That works for me, but doesn't seem to cover the criteria that Michael > set out for discoverability. I must have missed those discoverability criteria, apologies. In any case, I can hardly imagine anything more discoverable than a [PULL] on the mailing list. >> I understand that the PRs you created on github explicitly stated they >> weren't to be merged. It doesn't matter. One misclick from an edk2 >> maintainer who happens to be paying a bit less attention, and poof, we >> have mess in the git history. > > Which is fairly much true of *any* work, right? Any of those people > could 'accidentally' push stuff from their working tree out to the main > repository, at any time. We either revert it with a new commit, or we > quickly undo the commit and rewind the contents of the tree before too > many people update from it. It's hardly the end of the world. I disagree. It is costly. We've had two unintended merges thus far (from incorrect command line usage), and they took me personally hours to analyze and explain. Even without github pull requests, we frequently see build breakage too. Fixing them up is anything but fast. The fixup patch has to be mailed out, reviewed, committed. When the build fixup is trivial, I occasionally take the liberty and commit it without review (and them I'm super worried if I'll be called out for committing without review). The fact that these issues were introduced while using the git command line supports your point that such problems can occur "anyway". My point is that I would like to keep them as rare as possible, and github pull requests don't point in that direction. If you are volunteering to analyze and undo unintended or incorrectly resolved merges from github pull reqs -- I have no further comments then. > And the chances of the CRLF conversion one actually *applying* if > someone stupidly hits the button, after *one* more commit hits the > tree, are fairly much zero anyway. So you're defending against an > impossibility in that case. In this specific case, you are right. My point was to prevent building a precedent. > I don't know if I should be offended on behalf of the maintainers who > are mostly my colleagues, that you have such a low opinion of their > capabilities. I don't have a low opinion of the capabilities of other edk2 maintainers. It's a fact that they have just recently started using git. It is another fact that I personally mis-click a button (or mistype a shortcut) in this or that GUI application occasionally. Fixing build breakage (or functional breakage) in the edk2 repository is not exactly fun. I find myself analyzing and fixing up bugs from others (outside of OvmfPkg/) more and more. Simply because I tend to run into them with OVMF (and with Gerd's Jenkins instance) earlier than most other people. (I'm not always the first to find out, of course.) I think it's natural from me not wanting to ease the introduction of such issues. I'd like to invite other edk2 maintainers to chime in on a github PR centered workflow. If the consensus is to use them, I'll try to adapt the best I can, although I think it's a huge step backward. I will also stop analyzing and undoing problems introduced by others. I hope those in favor of github PRs will step up. Feel free to reopen the pull requests (if you don't have the credentials, I can reopen them for you). I'm not offering to help testing them out any longer; I disagree with the github workflow and won't be supporting it until I'm forced to, by maintainer consensus. Laszlo _______________________________________________ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
