[LLVMdev] RFC: Binary format for instrumentation based profiling data

["C. Bergström"]

On 04/19/14 03:13 AM, Chandler Carruth wrote:
>
> On Fri, Apr 18, 2014 at 12:58 PM, "C. Bergström" 
> <cbergstrom at pathscale.com <mailto:cbergstrom at pathscale.com>> wrote:
>
>     On 04/19/14 02:47 AM, Chandler Carruth wrote:
>
>
>         On Fri, Apr 18, 2014 at 12:22 PM, Evan Cheng
>         <evan.cheng at apple.com <mailto:evan.cheng at apple.com>
>         <mailto:evan.cheng at apple.com <mailto:evan.cheng at apple.com>>>
>         wrote:
>
>             I agree the top priority should always be "getting it
>         right”. But
>             I can’t agree with this thinking completely. This has to be
>             balanced with pragmatism. If we completely disregard the
>         practical
>             concerns of commercial use, it makes LLVM hostile towards an
>             important group of users.
>
>
>         Clearly, I can't argue with that. =] We benefit from it as
>         well. And I don't think I'm arguing against a pragmatic
>         approach in this case, although I'm sorry if it comes off that
>         way.
>
>         Just so we're on the same page, the only real question in my
>         mind is: can we make breaking changes as we iterate on the design.
>
>         What I would like to do is figure out the right design first,
>         incrementally, trying one format, and seeing how it does, but
>         potentially with backwards incompatible changes. Once we have
>         the experience and know what the right format is, *then* we
>         should consider pragmatic concerns such as how to structure
>         support for reading legacy formats, or formats outside of the
>         control of the project. I think if we start off with a format
>         that we can't change because of external reasons (whatever
>         they may be), it will be much harder to incrementally get to
>         the right design. Does that seem reasonable (and hopefully
>         help explain the concrete suggestion I'm making)?
>
>     Why can't we have our cake and eat it too?
>
>     Off the cuff and flame away
>     ------------
>     What's wrong with a soft policy like - Feel free to do an
>     incremental improvement which breaks a change and then if someone
>     else wants to contribute a patch that allows the old
>     format/behavior - that's up to them (patches welcome). Both
>     changes would be accepted and allows the parallel paths - (putting
>     the burden of maintenance for backward compatibility on those
>     stakeholders). Wouldn't this solve the problem Right Now(tm)?
>
>
> I think its important that there remain incentives for the 
> contributors to address design feedback that comes up in review 
> essentially. Making it "patches welcome" right away, removes that 
> incentive IMO, and would be a shame. Sometimes, its unavoidable, but I 
> think the project is better when we hold that line.
/* last non-technical reply */

I empathize with one side in this case, but outside this thread and 
generally - Holding the line is great, but sometimes gotta break a few 
eggs to make an omelet.. (Or hold the line, but don't step on it) 
Especially if all the commit noise happens between releases and the 
"patches"/code churn pragmatically gets squashed for any end users.

/* Probably not the case this time - I'd hope passionate developers 
don't block ${serious_contributor} to the point of hard deadline 
decisions. It would be a larger foul for the community of users to miss 
out on a compatible solution */