[kea-dev] OMAPI like feature in KEA
tomasz at isc.org
Tue Aug 23 20:40:10 UTC 2016
W dniu 23.08.2016 o 06:58, phirince philip pisze:
> We hope to start internal discussion (in 2 weeks maybe?) about the scope
> for Kea 1.2, which will be our next release after 1.1 goes out. We
> haven't made any decisions yet, but it seems likely that we'll pick
> major parts of the API and will start implementing it when 1.2 milestone
> Cool. So should I stop the development work for now?
It depends on what your timelines are. We should ship 1.1 beta by end of
August (but don't quote me on that. If anything unexpected comes in the
next couple days we may move the date a bit), then we'll start internal
discussion about the scope of work for 1.2. A list of new tickets will
be created shortly after that and assigned to Kea1.2 milestone. We
typically do the requirements (1 ticket), then the design (1 ticket) and
finally the implementation (many tickets). Since we have the
requirements, we'll go straight to the design. The actual implementation
will be split into reasonably small tickets and we'll start assigning
them one by one.
Couple times non-ISC people expressed interest in developing certain
things, we assigned tickets to them and they participated in the normal
review process. One thing that complicates it a bit is that you won't be
able to commit anything to our repo, but we can work around that by
using pull requests on github. You'd need to create an account on kea
website, but that's easy to do.
> Will I be able to contribute?
By all means yes!
> How does it work? Do you open tickets and assign it among yourself? Or
> will I be able to pick up tickets which are more important to us?
We will put all the tickets in http://kea.isc.org/milestone/Kea1.2.
There are a handful of random (previously deferred) ticket there
already. We will decide which of those will actually be done in 1.2 and
then create maybe 30-50 tickets for the API implementation. Some of them
will have high priority, but most will be mediums. ISC engineers will
start working on those high ones, assigning the one they're working on.
The medium ones will remain unassigned. If you want to work on any of
them, feel free to assign it to yourself.
> In particular, we will not be able to merge a patch that comes without
> unit-tests. If we receive a patch that looks good, but does not have
> unit-tests, we will have to write them on our own, but that may take a
> lot of time until we get around to it.
> I understand. I'm a big fan of TDD myself. I'll make sure I submit unit
> tests along with code.
Cool. We have our own jenkins farm here: https://jenkins.isc.org/
You may take a look at the systems we run the tests on (various flavours
of Fedoras, RedHats, Ubuntus, Free/Net/OpenBSDs) with various
configuration options. I'm mentioning that because people are sometimes
surprised. They submitted a patch and it worked for them on Ubuntu, but
the code fails to compile or some unit-tests break down on OpenBSD.
That's still a deal-breaker and we can't merge it until the issue is fixed.
> I think you have already covered much more than I expected.
> But the most important calls to me would be "add-reservation",
> "delete-reservation" and "get-reservation". "update-reservation" would
> be useful, but not absolutely required.
Understood. We have the same perception on this. If needed, update can
be done as delete+add with new values. It's not optimal, but
I'll ping you once we have the tickets sorted out.
Thanks a lot for your offer to help Kea code to grow.
More information about the kea-dev