On Wed, Oct 01, 2014 at 02:59:40PM -0400, Neil Horman wrote: > On Fri, Sep 26, 2014 at 10:45:49AM -0400, Neil Horman wrote: > > On Fri, Sep 26, 2014 at 12:41:33PM +0200, Thomas Monjalon wrote: > > > Hi Neil, > > > > > > 2014-09-24 14:19, Neil Horman: > > > > Ping Thomas. I know you're busy, but I would like this to not fall off > > > > anyones > > > > radar. You alluded to concerns regarding what, for lack of a better > > > > term, > > > > ABI/API lockin. I had asked you to enuumerate/elaborate on specifics, > > > > but never > > > > heard back. Are there further specifics you wish to discuss, or are you > > > > satisfied with the above answers? > > > > > > Sorry for not being very reactive on this thread. > > > All this discussion is very interesting but it's really not the proper > > > time to apply it. As you said, it requires an extra effort. I'm not saying > > > it will never be integrated. I'm just saying that we cannot change > > > everything at the same time. > > > > > > Let me sum up the situation. This community project has been very active > > > for few months now. First, we learnt how to make some releases together > > > and we are improving the process to be able to deliver a new major release > > > every 4 months while having some good quality process. > > > But these releases are still not complete because documentation is not > > > integrated yet. Then developers should have a role in documentation > > > updates. > > > We also need to integrate and learn how to use more tools to be more > > > efficient and improve quality. > > > > > > So the question is "when should we care about API compatibility"? > > > And the answer is: ASAP, but not now. I feel next year is a better target. > > > Because the most important priority is to move together at a pace which > > > allow most of us to stay in the race. > > > > > > > > > I'm sorry Thomas, I don't accept this. I asked you for details as to your > > concerns regarding this patch series, and you've provided more vague > > comments. > > I need details to address > > > > You say it requires extra effort, you're right it does. Any feature that > > you > > integreate requires some additional effort. How is this patch any different > > from adding the acl library or any other new API? Everything requires > > maintenence, thats how software works. What specfically about this patch > > series > > makes the effort insurmountable to you? > > > > You say you're improving your process. Great, this patch aids in that > > process > > by ensuring backwards compatibility for a period of time. Given that the > > API > > and ABI can still evolve within this framework, as I've described, how is > > this > > patch series not a significant step forward toward your goal of quality > > process. > > > > You say documentation isn't integrated. So, what does getting documentation > > integrated have to do with this patch set, or any other? I don't see you > > holding any other patches based on documentation. Again, nothing in this > > series > > prevents evolution of the API or ABI. If you're hope is to wait until > > everything is perfect, then apply some control to the public facing API, > > and get > > it all documented, none of thosse things will ever happen, I promise you. > > > > You say you also need to learn to use more tools to be more efficient and > > improve quality. Great! Thats exactly what this is. If we mandate even a > > short > > term commitment to ABI stability (1 single relese worth of time), we will > > quickly identify what API's change quickly and where we need to be cautious > > with > > our API design. If you just assume that developers will get better of > > their own > > volition, it will never happen. > > > > You say this should go in next year, but not now. When exactly? What > > event do > > you forsee occuring in the next 12-18 months that will change everything > > such > > that we can start supporing an ABI for more than just a few weeks at the > > head of > > the tree? > > > > To this end, I just did a quick search through the git history for dpdk to > > look > > at the histories of all the header files that are exposed via the makefile > > SYMLINK command (given that that provides a list of header files that > > applications can include, and embodies all the function symbols and data > > types > > applications have access to. > > > > There are 179 total commits in that list > > Of those, a bit of spot checking suggests that about 10-15% of them actually > > change ABI, and many of those came from Bruce's rework of the mbuf > > structure. > > That about 17-20 instances over the last 2 years where an ABI update would > > have > > been needed. That seems pretty reasonable to me. Where exactly is your > > concern > > here? > > > > Neil > > > > Ping Thomas, I'd like to continue this debate to a conclusion. Could you > please > provide specific details and/or concerns that you have with this patch series? > > Thanks > Neil > Ping again Thomas, please lets debate this to a reasonable consensus. Ignoring it won't help anything.
Regards Neil
