On 17/08/18 15:30, Jean-Baptiste Onofré wrote: > Hi Robert, Hello JB,
> thanks for your feedback, and I fully agree with you. > > For the release, it's largely my fault for 4.2.1: I wanted to include > too much fixes, upgrades and new features. My bad, and apologize for > that. That's why I wanted to propose to reduce scope of the releases and > do it on a regular pace, much more predictable to users/devs like you. > > For the changes, we are now much more "strict" in the changes we are > doing. Any breaking changes is not allowed on a minor release. That is absolutely fantastic. > For the documentation, we started a huge work on this one. You can > already see the user guide is largely better than before IMHO. Now the > target is on the dev guide and related examples. Awesome, that will help us immensely. > I see your point the way you are "packaging" the features. Any reason > why you don't manage your features repository by hand ? There are couple of reasons for that, actually, some of which may be historical, but have gotten us where we are. Given the history, there is reluctance to do another big migration unless the outcome is guaranteed to work and be easier to use than we have now. The first problem comes from the fact that OpenDaylight is a collection of projects, each with its own release cycle and versioning. Each of them focuses on a problem area -- so to get OpenDaylight "core" you need to assemble 4 projects, for "platform" it is 6-8 projects and the Karaf distro available for download contains something like 16-20 projects. The end result needs to be version-converged, obviously. Hence we need to communicate versions between projects and retain strong version requirements. This is done through bill-of-material poms published by an upstream project and ingested by downstreams as a scope=import dependency. We therefore need to pick up versions used in features -- and use of properties is not an acceptable solution. To address this, we used to have hand-written feature.xml templates, which we processed with a rather arcane script (https://github.com/opendaylight/odlparent/blob/stable/lithium/features-parent/pom.xml#L75). The second problem is that the developers found it somewhere between unfriendly and downright hostile, as features did not "just work", but tended to fail on our SFT with a bundle resolution error of various complexity -- ranging from simple missing imports to rather arcane class mismatches, depending what sort of mistake the dev made. Normal folk get scared by these and if they cannot solve them easily they just walk away. When this is coupled with the unfamiliar paradigms used in OpenDaylight proper, this can easily lead to the perception that OpenDaylight/Karaf is not something mere mortals can use :( Our hope was that we could solve this usability problem by resorting to generated features during our migration to Karaf-4.0.x. This has the problem of massive over-inclusion, resulting in features which explicitly pull in bundles observed at compile-time, even when those bundles are provided in a feature somewhere else. The generated features are ugly, but 95-99% of the time they Just Work(tm). This allows people to get started quickly, with the features getting eventually cleaned up. Over the course of past of two years we (well, mostly Stephen Kitt) have contributed the missing bits to the karaf plugin and configured our build system in ways which make this work reasonably well. Now we are coming to complete the circle, where for some projects we are considering hand-written features, but to justify that migration, we need solid documentation on how to use features to their full extent. Even then, though, the main challenge remains: how can we on-board a developer, who has never heard of OSGi nor features, so she can work on their code rather than to going through a bootcamp of OSGi/Karaf pain :( > Anyway, 4.1.6 has been released and 4.2.1 will be on vote tonight. > Starting for there, I will send the release agenda with a release every > two months for both Karaf Container but also the subprojects. Great, we are targeting both those versions for inclusion in our current release trains. I am looking for those agenda emails! Thanks, Robert
signature.asc
Description: OpenPGP digital signature
