On Thu, May 17, 2012 at 4:50 PM, Maciej Stachowiak <[email protected]> wrote:
> > On May 17, 2012, at 4:40 PM, Dirk Pranke <[email protected]> wrote: > > > On Thu, May 17, 2012 at 4:16 PM, Maciej Stachowiak <[email protected]> > wrote: > >> > >> Let's take an example. "TEXT" next to a test name apparently means that > the text fails. There is no way in the world I would guess that just from > reading an expectations file. This is only conceivably understandable to > someone who is an expert on the format. If someone used TEXT in code to > mean "fail", I would r- their patch for failure to use meaningful > identifiers. > >> > > > > I hardly think you have to be an expert on the format. I think you > > probably need it explained to you once, or you could just read > > http://trac.webkit.org/wiki/TestExpectations (which is linked to from > > (I think) all of the expectations files). > > If someone gave that kind of explanation for a variable in a patch to C++ > code, I would still r- their patch. The token's meaning should be apparent > without having to read out-of-line docs first. > > > > > At the risk of overly repeating myself, I am not wedded to any one > > format here, but I'm also not inclined to change things just because a > > couple of people have vocally objected. If there was a clear consensus > > that any change was preferred, that's fine by me. > > I feel like the people objecting to change, you included, are objecting > because mostly because they are already familiar and comfortable with the > current format. And not because it is genuinely better than another format > that people might be similarly experienced with in the future. It is > totally possible to be both newbie-friendly and experienced-friendly if you > do not limit "experienced" to only the people who already have experience > today. > All the proposals that are not just bikeshedding we seem to agree on and will happen (the half-dozen things I listed above). Sure TEXT, IMAGE, etc are not very clear, but noone has actually proposed something better. Ojan
_______________________________________________ webkit-dev mailing list [email protected] http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
