On Fri, 2016-03-18 at 23:26 +0100, Laszlo Ersek wrote: > > Whenever you contribute to a project, do you always start with making a > huge noise, calling everyone around (or their rules) insane, "makes no > sense at all", and so on?
Not at all. Some weeks I'll work on as many as a dozen or so projects.
This week it's been EDK2, OpenSSL, Linux, MIT krb5, GSS-NTLMSSP, git,
NSS, and two or three GNOME projects. And possibly others; I distinctly
remember there being some python but I tend to blot out those memories
as quickly as I can.
Most projects are relatively easy to work with. If they have coding
styles that they adhere to, then they're obvious in the code you're
working on — and in the ideal case, encoded in the source files in a
form which emacs can automatically understand.
I can cope with 'this project suffers from supporting Microsoft tools
and thus we can't even use C99' — I've seen that enough times.
But what we have here is a particularly special combination — the
insistence on supporting crappy Microsoft tools with false warnings
about uninitialised variables, in conjunction with a rule that "we
don't initialise variables on declaration". That *combination* just
blows the mind, surely?
I have *never* dealt with projects that seem to be trying *so* hard to
do the wrong thing and make life hard, in so many ways. To the point
where one has to go and look up the special project-specific
instructions just to do something as trivial as applying a patch from
the mailing list.
And sure, you do that every day so you don't find it problematic. You
even *wrote* those instructions. But that's doesn't mean it's OK.
That's just Stockholm syndrome.
What's really frustrating is that that was a known issue, and it's
something that *could* have been handled before the final switch to
git. I had even worked on doing the Subversion → git conversion such
that the CRLF thing was fixed in all commits as they came across.
But it didn't get done, and now we still have the same issues for no
good reason — and a longer period of transition(s) before we finally
get to where we need to be.
The same goes for the half-measure of using git as if it was
subversion. Again it means *another* change before we get there.
So yes. I'm sorry. I get frustrated.
> CRLF has been working out for most people. Rebasing patches has been
> working out. Staying away from non-ASCII in commit messages ditto.
> Keeping full context when quoting patches ditto. You want edk2 to
> change its ways in all aspects at once. And since I seem to be the
> guy who talks to you the most, I'm the one you yell at the most. I've
> never experienced this before. I'm stunned.
CRLF works for *you* because you're doing it all the time, and can
remember all the magic you have to do to work around it. Throwing away
history works until you actually find you need to refer back to it. You
*aren't* staying away from non-ASCII in commit messages; your
configuration has led to pushing esoteric legacy charsets into the EDK2
git objects themselves, inviting all the labelling problems that we
used to have in the 20th century before we all started using UTF-8. And
you've shown an example of that happening already. The patch citation
you're picking on was clearly showing the i'f(x) {set} … if(x) {use}'
pattern which was triggering the warning, in a way that wouldn't have
been readable (I might as well have elided it completely) if I'd left
the full thing. Although you claim it made it hard to find the code in
question, the bit that said 'line 275' ought to have given it away.
And sure, I'm a whole lot better at dealing with computers than I am
with people, and I tend not to be very good at hiding my frustration.
I'm sorry if you interpret that as 'yelling', especially 'at you'. I
respect you greatly, and I keep telling you how much I appreciate the
help that you offer to me and to others.
It's not that I "want edk2 to change its way in all aspects at once".
All I wanted to do was due diligence on the OpenSSL 1.1 support that
I've been working on.
I wanted to pull in the HTTPS patches and actually get that working,
but it's just too painful. Sure, I probably *could* have done it, and
thanks again for giving me yet another magic incantation to work around
yet another aspect of the brokenness I had tried to avoid by pointing
it out before we set it in stone. But the moment has passed — the
additional time it would require has pushed it to "Someone Else's
Problem" status. I've thrown the 'hey, we can build the ssl/ directory
too' patch into the PR I submitted this morning, and that'll suffice.
But I at *least* wanted to test what I was doing on Windows. So I went
to the trouble of firing up a Windows VM and dealing with it (which
probably hasn't helped my frustration level right from the start, to be
honest), and found that the build had apparently been broken for 2
weeks without anyone noticing. Which makes me wonder why I'm
bothering... but OK, I'll not only track it down and report it but I'll
also attempt to submit a patch... to which I get a response of "we
don't initialise variables", and "I don't like your correct use of the
English language so please fix that even though we have no such
policy".... which in turn leads me to the joyful discovery that we
actually have ISO8859-2 objects in the git repository.
Is it time to quit working and start drinking yet? :)
But again, Laszlo, I'm not yelling at you. I'm frustrated with the
issues, and I'll debate technical stuff until the cows come home in a
genuine attempt to improve understanding and make things better for
everyone. But please don't for a minute think that I don't have a
*massive* appreciation of all that you're doing.
--
dwmw2
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ edk2-devel mailing list [email protected] https://lists.01.org/mailman/listinfo/edk2-devel
