[LLVMdev] Question about changes to llvm::Argument::addAttr(AttributeSet AS) API

Óscar Fuentes ofv at wanadoo.es
Wed Feb 6 11:43:52 PST 2013


Bill Wendling <wendling at apple.com> writes:

>> In this case, the LLVM incremental style is counterproductive, for both
>> users and developers. Who is interested on watching your API going
>> through intermediate stages and (possibly) experimental points until it
>> stabilizes?
>> 
> People who are interested in catching errors quickly before they
> become expensive things to hunt down.

If I'm understanding what you say, you are interested on catching errors
on an experimental API by forcing it on everybody who works with ToT?
Hmmmm.

>>> Living on ToT isn't easy. No one ever said it would be.
>> 
>> This is no reason for ignoring practices that can improve the
>> experience.
>> 
> The most important thing is the health of the tree.

This seems to contradict what you wrote above. By going through several
iterations of the API development, you are putting the health of the
tree at risk multiple times, instead of just one if you merge to trunk
once you consider your API stable enough.

>>> And they're more stable day by day.
>> 
>> You are proving my point. It is a waste to use trunk for things that are
>> considered by the author to be on work-on-progress state. That only
>> creates noise for both developers and users, without any advantage for
>> the author. Work on a feature branch and merge the changes when you are
>> happy with your code.
>> 
> Are you new to LLVM or just haven't been paying attention? Developing
> features on trunk is what ALL developers do.

First, please tone down. This is not about you personally, but about
blindly applying the LLVM development guidelines when doing something
else would be better for achieving the ultimate goal of such guidelines.
After all, the guidelines are just a set of practices for (hopefully)
obtaining an effect.

Second, not all developers use trunk for experimental code. More and
more of them use git or keep private patches until they consider that
the code is ready for prime time. I think that just a minority would
commit changes to stable core components of LLVM (much less alter an
API) as a means for storing the current state of their work-on-progress,
knowing that such changes will impact other developers and/or users.




More information about the llvm-dev mailing list