From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pd0-f171.google.com (mail-pd0-f171.google.com [209.85.192.171]) by dpdk.org (Postfix) with ESMTP id 3FFAC678C for ; Fri, 26 Sep 2014 23:56:43 +0200 (CEST) Received: by mail-pd0-f171.google.com with SMTP id y13so13674556pdi.2 for ; Fri, 26 Sep 2014 15:03:06 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:to:cc:subject:message-id:in-reply-to :references:mime-version:content-type:content-transfer-encoding; bh=sqt1twptCsJVWd+1QQX2Cf/VBc4DPUQcbJ4hu0Vy7bg=; b=VcZYtUx0ldMOWnGVb0siI7cADWoU2r15WedBz+sfE6czGYAQCIJxWhXt0KSD0yuRCD LlX3g558C4E4MZ+INsiA+dvoDyuy2+XSB/YvXZKyzXH8Q+LgRrxurx7cwV4JSwS2FO2b ey2SWRwonSnb1UZtuXH2scK5g5b61EVTrbPbUS8cFJOP6DfL7h+IAOfnD3I+nni7sEp6 0mNhW1HASzldHRlKKWDpgFwEgeRh1Xi+6oLMyMuZYMblEPxMZ4hwXWQeqwjlUObi6CG2 wu3e124dkgBg3yOFnijrtP5xnBhX8sAY3fzrxKlqVIE1QlPL2szUomUC7BCTby16Hljy wYfQ== X-Gm-Message-State: ALoCoQliJ1IeKQW7N2E6nXsUtUDWibN1g7LXrFi9EZi7lGFVFKkQbVW5Zgrv/zNE+x5djKggTziW X-Received: by 10.70.90.39 with SMTP id bt7mr45623658pdb.121.1411768986328; Fri, 26 Sep 2014 15:03:06 -0700 (PDT) Received: from urahara (static-50-53-65-80.bvtn.or.frontiernet.net. [50.53.65.80]) by mx.google.com with ESMTPSA id s5sm5789796pdr.76.2014.09.26.15.03.03 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 26 Sep 2014 15:03:06 -0700 (PDT) Date: Fri, 26 Sep 2014 15:02:55 -0700 From: Stephen Hemminger To: Neil Horman Message-ID: <20140926150255.75ff6f45@urahara> In-Reply-To: <20140926144549.GA5619@hmsreliant.think-freely.org> References: <1410809031-19114-1-git-send-email-nhorman@tuxdriver.com> <20140918191401.GP20389@hmsreliant.think-freely.org> <20140924181940.GB4651@hmsreliant.think-freely.org> <1449997.vdXo3dW1jx@xps13> <20140926144549.GA5619@hmsreliant.think-freely.org> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: dev@dpdk.org Subject: Re: [dpdk-dev] [PATCH 0/4] Add DSO symbol versioning to support backwards compatibility X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Sep 2014 21:56:43 -0000 On Fri, 26 Sep 2014 10:45:49 -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 Isn't ABI stablity a distro responsibility not a project responsibility? I have lots more API/ABI changes, just been too busy trying to release a real product using DPDK to upstream all the changes.