On Wed, May 24, 2017 at 2:00 AM, <otr...@employees.org> wrote:
> Hi Jon,
Hi Ole,
> Thanks for the poetry! ;-)
Most welcome.
> This is me in 01384fe
> Apologies for that. Next time I see you let me bring both band aid and
> whiskey.
Apology accepted!
> To my excuse, there has been this list of "broken" APIs maintained by the
> Python and Java language binding implementors.
See? Java is bad for you. :-)
> It's been on the todo list for a long time and I finally found some time to
> deal with them. Obviously not everyone was aware of those planned
> changes. I did include those I thought affected as code reviewers. #fail.
It's OK, really. I've been making a pretty systematic march
through many of the VPP API areas, so there's no telling what
or where I'll be poking next... :-)
> I feel your pain. How can we make this better?
> 1) Never change APIs, regardless the reason
> 2) Announce and discuss changes a priori. Separate mailing list for
> API changes?
> {vpp-users, vpp-api-announce}
> 3) ...
This is a really good question. I confess it is also a difficult one.
We certainly can't abide by 1) Never change APIs. That is just not
a realistic approach.
I follow the vpp-dev list pretty regularly these days, and I try
to watch the upcoming Gerrit patches and reviews. And I try
to keep our VPP repo up-to-date WRT the fd.io Git repo; I pull
maybe every couple days or so.
So for me, I am willing to suffer a bit of tip-of-tree development
pain and angst. Even fixing this API call removal wasn't that
difficult for our code.
I think the thing that was most troubling for me was getting it
pretty much without warning. So I think at the very least, it
would be good to make a statement on the vpp-dev list.
But when? Certainly it would be nice if it were in advance of
the patch being committed. I realize that may not always be
possible. But some indication on the list as it is being committed
would also be nice. Maybe even some indication from the patch
author on list like "Hey, I have a patch in review that removes
*this* API call. If you are using it you will need to change your
code like _this_."
The process of adding API calls, and even changing an existing
one is easier, of course. But still, some advance notice would
be appreciated.
How hard would it be to have a Jenkins nightly build job that
diff'ed yesterday's complete API list versus today's list and
generated sent that diff mail? Dunno. Just an idea.
> Do we reach everyone using vpp on vpp-dev and a heads-up there
> would suffice?
Quite possibly. I don't really have a feel for how many people
use each of the various APIs for active development these days.
It may very well justify a specific vpp-api-discussion list or so.
> Cheers,
> Ole
HTH,
jdl
_______________________________________________
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev
