On Wed, May 24, 2017 at 6:21 PM, Jon Loeliger <j...@netgate.com> wrote:
> 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.
>
In the OpenDaylight community we have something called the "Weather" page
on the wiki [0], where information about potentially disruptive patches is
posted, then the link posted on one of the mailing list with "[WEATHER]" in
the subject so that it stands out and can be filtered. I would say it
worked reasonably well for us, maybe it's worth a try?
Then again, this approach was useful because we have many different
projects and tons of mailing lists, FD.io being more focused it may be
overkill.
HTH,
-Lori
[0] https://wiki.opendaylight.org/view/Weather
>
> > 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
>
_______________________________________________
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev
