<div dir="ltr">Thomas - thanks for the response. We will proceed with making the necessary changes for using v22.11.1.</div> <div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Dec 8, 2022 at 8:22 AM Thomas Monjalon <<a href="mailto:thomas@monjalon.net">thomas@monjalon.net</a>> wrote: </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">I'm sorry Patrick that it gives you more work. Your proposals below don't look possible because a tag is something fixed forever. We had an ABI issue in the initial tag so we cannot use the tag v22.11 as planned. I don't see how we can better plan except having more tests on release candidates. 07/12/2022 19:00, Patrick Robb: > Hello, > > Community Lab team members are wondering whether it is possible to bump > v22.11 to include at least this patch. We have an existing codebase which > relies on a vXX.XX scheme for producing ABI references. We parse that out > at different places in our code, so fixing this to handle vXX.XX.X will > require some changes on our end. We can do that, but it puts the timeline > on turning on ABI testing at the community lab back some. A v22.11 tagged > release with this patch would allow for us to turn on ABI testing > immediately. There was also a suggestion that having the "base" tag (like > the simple v22.11) point to the latest revision is a more standard version > naming approach and may be more intuitive than what is being used currently. > > If that is not possible, we will update our code to be able to refer to a > vXX.XX.X tag for producing the ABI reference. If we adopt this approach, we > would like to request that with future releases, a "vXX.XX.0" tag could > always be made available for us to produce ABI references from. That way, > we can prepare for turning on ABI testing knowing beforehand the tag name > we will be using. > > On Tue, Dec 6, 2022 at 7:25 AM Ferruh Yigit <<a href="mailto:ferruh.yigit@amd.com" target="_blank">ferruh.yigit@amd.com</a>> wrote: > > > On 12/6/2022 10:18 AM, David Marchand wrote: > > > On Tue, Dec 6, 2022 at 11:13 AM Ferruh Yigit <<a href="mailto:ferruh.yigit@amd.com" target="_blank">ferruh.yigit@amd.com</a>> > > wrote: > > >> On 12/5/2022 3:37 PM, Thomas Monjalon wrote: > > >>> 05/12/2022 14:47, Akhil Goyal: > > >>>> But adding a tag on same repo is more convenient from developer point > > of view. > > >>>> However, it is my personal view, others may differ. > > >>> > > >>> From developer point of view, you should use > > devtools/test-meson-builds.sh > > >>> which does the "git clone" for you. > > >>> > > >>> This is what I have in ~/.config/dpdk/devel.config > > >>> export DPDK_ABI_REF_DIR=$root/dpdk-build/abiref > > >>> export DPDK_ABI_REF_VERSION=v22.11.1 > > >>> > > >> > > >> Does it help to update 'test-meson-builds.sh' to use an environment > > >> variable to select which repo to clone? > > >> If so, I can send a patch for it. > > > > > > I was wondering too... > > > I would expect most maintainers have the stable repo in their config > > > but it would not hurt to handle the case when they don't for others. > > > > > > +1 > > > > Sent following if it helps: > > <a href="https://patches.dpdk.org/project/dpdk/list/?series=26015" rel="noreferrer" target="_blank">https://patches.dpdk.org/project/dpdk/list/?series=26015</a> </blockquote></div> <div> </div>-- <div dir="ltr" class="gmail_signature"><div dir="ltr">Patrick RobbTechnical Service ManagerUNH InterOperability Laboratory21 Madbury Rd, Suite 100, Durham, NH 03824<a href="http://www.iol.unh.edu/" style="color:rgb(17,85,204)" target="_blank">www.iol.unh.edu</a> <img src="https://lh4.googleusercontent.com/7sTY8VswXadak_YT0J13osh5ockNVRX2BuYaRsKoTTpkpilBokA0WlocYHLB4q7XUgXNHka6-ns47S8R_am0sOt7MYQQ1ILQ3S-P5aezsrjp3-IsJMmMrErHWmTARNgZhpAx06n2" width="150" height="37" style="border: none;"></div></div>