On 05/23/2017 03:11 AM, ??? (Uze Choi) wrote:
> Hi Omar/Nathan
>
>
>
> Let?s these requirements for release kept from the next release.
>
> To cut the feature earlier, CTT also should align together, but practically
> this is not easy work.
>
> Anyway I felt that IoTivity and OCF need more communication and coordination.
>
>
>
> Practically September timeline is what we can think about for final CTT. (I
> expect one or two months delay)
> mbedtls version will be updated by consequence patch just after release which
> might not change any API change.
>
> interopable issue is from the spec view, I think.
>
>
>
> To avoid people get confused, Let me post the release context with
> non-certifiable wording.
>
> Any suggestion will be welcomed except giving up this release.
I'm not going to offer up an opinion for solving the present dilemma,
but I do want to assure everyone that there is nothing new here: every
large open source project has gone through some form of this discussion.
There is a good reason why many mature projects have chosen to go to
time-boxed releases rather than feature-boxed releases - the now
familiar "we will release every six months" model. It is very hard to
coordinate all the development in a volunteer project with worldwide
distribution of developers, and having a predictable release schedule
serves as such a coordination point for developers as well as for
consumers of the project ("it helps", not "it magically solves
everything"). Note that while most of the developers on IoTivity are
corporate-sponsored, a very useful definition is: if the release manager
does not have control over who works on what, it should be
classified as a volunteer project. I could go on about this, but there
is plenty of more reasoned argument out on the internet (Martin
Michlmayer and others have done some fairly formal research on the topics).
It is important to note, however that committing to time-based releases
means several preconditions have to be met, one of which is: "the
release rationale must not be driven by specific functionality". Similar
to what Omar noted, this iotivity release seems to want to (a) attempt
to implement a particular version of the OCF specifications and (b) have
a quality metric that the codebase, if suitably configured into a
"device" of the kind described by OCF specifications, can pass the
certification tests (CTT) for that version of the OCF specification.
That would make this a feature-boxed release.
