On Fri, 2016-03-18 at 17:08 +0100, Laszlo Ersek wrote: > On 03/18/16 14:59, David Woodhouse wrote: > > Sometimes, stuff just broke and you just fix it up and move on. Let the > > people who *did* it work it out for themselves and that actually forms > > a *better* learning experience for them. > > Yes, this is how it should work, but if the fix takes an inconveniently > long time, the problem will likely impede my own work.
If we can agree on a policy of "if it breaks, revert it", then such things *shouldn't* take an inconveniently long time. As long as history is preserved correctly and subsequent work hasn't been rebased on top of the offending commit(s), of course. If you have a full history, even if merges have happened, then it's not so hard to take out the offending commits as long as they're recent. Of course, CI on submissions helps to avoid the problem altogether. To a certain extent, at least. > > That's an > > oversight... the tools can run builds on various platforms and right > > there in the ticket it can show that it doesn't build in certain > > configurations. With a big red cross right above the 'merge' button :) > > I've never heard of this. Would github operate the CI, or would it be > some external CI, to be integrated with github? External, triggered by github. See https://github.com/openssl/openssl/pulls for example. Each PR has a green tick or a red cross by it, indicating whether the automatic builds succeeded. Although it's perhaps a bad example because OpenSSL has a lot of false failures at the moment. But still you get the idea. Go into one of the failed, and one of the succeeded, PRs and you'll see what it looks like in the ticket itself as you view it. > > > Feel free to reopen the pull requests (if you don't have the > > > credentials, I can reopen them for you). > > You didn't respond to this. Is it okay with you if we delay reopening > your pulls (#70 and #71) until we can disable the merge button (with > those two settings you discovered)? That was the intention implicit in the fact that I waited. I may reopen the CRLF one as soon as the commit *after* my Windows build fix (qv) goes into the tree, because that will be *guaranteed* not to merge even if someone does hit the button :) > I'll probably feel less threatened about github PRs once the merge > button is disabled, but I would nonetheless like all patches in a pull > request to be posted to the list, with the pull request details present > in the blurb. Yes, I think that's an important part of any process we come up with even when it includes github PRs. It doesn't *bypass* the mailing list. > > Perhaps if we can fix the CRLF thing then applying patches will get a > > little easier. > It should, yes. FWIW this seems to be working. I can do checkouts on Windows and if I have core.autocrlf set in my git config then I get CRLF line endings in all the checked out files just as before. And if I *don't* have that set, then I get LF but it works fine anywy., With core.autocrlf set, just pulling the commit which changes the *internal* representation from CRLF to LF basically does nothing to the checked-out files since they remain CRLF. I haven't worked out how to *automatically* set the core.autocrlf for the repository, similar to the way that .gitattributes works. But given that things work OK even without it, I think that's fine. I want to redo all my testing after that VS2008 build fix has landed, so I'm not perturbing all my tests. And obviously let some other people test it. But I'm fairly happy with it. -- David Woodhouse Open Source Technology Centre [email protected] Intel Corporation
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ edk2-devel mailing list [email protected] https://lists.01.org/mailman/listinfo/edk2-devel
