Re: [iot-pmc] Concierge 1.0 release review

[Kai Kreuzer <kai@xxxxxxxxxxx>]

Hi Jan,

If I get you right, your main argument is:
„Concierge passes the OSGi R5 TCK and therefore there won’t be any further work on its codebase necessary“ (besides adding some not-in-spec features and working on R6 compliance in future).

You are the OSGi expert, so you can probably answer this: Does passing the TCK mean that the implementation is bug-free and usable in the wild?

I remember you saying one year ago that Concierge passes almost all TCK tests (with only 5-8 minor ones failing). This sounded already as if the implementation is „how a good implementation should be“. During the past year though, this list had been created as well: https://github.com/JochenHiller/concierge-tests#closed-bugs-in-concierge
Were all the reported and fixed bugs in the context of the few failing TCK tests?

From my personal experience, the TCK is a hint that something might be usable, but not a guarantee. Especially, afaik it does not say much about performance and memory usage, right?
Do you have any real life statistics on these?

> Ultimately, I
> don't think Concierge will ever realistically be something that people
> download to play with it while waiting for the next bus so don't expect
> "viral" numbers.

I think you underestimate your work here. IF it is a replacement for Equinox, Felix, Knopflerfish, ProSyst mBS, etc, which is smaller, has a better performance and a modern architecture, I think you will see MANY people jumping on it. And this is what I fear: Only when these people start using it, you will find out about all the special tricky use cases that you might not have thought about yet and where you might need to adapt the implementation.
Therefore - and in your own interest - I think it is a much wiser move not to claim that everything is already perfect and cannot be improved anymore.

Just my 2 cents,
Kai


> Am 08 Oct 2015 um 17:43 schrieb Jan S. Rellermeyer <rellermeyer@xxxxxxxxxxx>:
> 
> Well, OSGi has taught us many important things about software engineering,
> one of them being that version numbers should be technical (i.e., carry
> semantics) as opposed to being a marketing instrument or, as in this case,
> political. I think it is important to point out that since we are working
> against established standards there is just no way that we could further
> improve the code in any way that would justify going from a sub 1.0 version
> to 1.0. We just don't have real API outside the OSGi specifications (and
> trust me, this is how a good  implementation should be :-)) Quite frankly,
> besides potential bug fixes or adding one or two service bundles (which then
> might justify a 1.1 release) the next release of the framework is most
> likely going to be an OSGi core R6 implementation. At this point we are
> fully compliant with the core specifications so that there is just no
> logical next step. I think this is what makes our case different from the
> general case, we had a clear goal line in achieving compliance and we have
> crossed that. The only reason to not release 1.0 would be: "you did not
> release before so you need to do a prior release, sit out for a certain
> amount of time, and then go to 1.0". We could do that but would have to
> release pretty much the same code, which is why I would call this (without
> any intention of offending anybody) a purely political reason. 
> 
> Quite frankly, given that we already released 1.0.0 (as an R3
> implementation) on Sourceforge one could rather argue that we need to go to
> 2.0.0 do avoid confusion but my take so far was that the Eclipse move and
> going from core R3 to core R5 was a full relaunch of the project and
> something that our community was sufficiently aware of to not be confused.
> 
> In hindsight, should we have released a version on Eclipse before this one?
> The answer is: quite possibly yes. However, it did not make any sense to use
> recently since we were just too close to full compliance so we possibly
> should have release something in the very early days. 
> 
> Graduation might be a separate issue and I understand your concerns.
> However, I should also point out that Concierge has had a small but active
> community since 2006, something that not every incubation project can claim.
> Concierge ultimately is infrastructure and primarily caters to people
> interested in OSGi technology so the raw number of people who use it
> directly for building new stuff will never be tremendous (we have about 3000
> downloads for the latest R3 distro version on Sourceforge, though. For our
> snapshot builds on Eclipse, we unfortunately don't have meaningful stats
> since we were serving them directly off of Hudson). I hope that the number
> of people using it indirectly by consuming projects based on it is still
> going to be large but this is difficult for us to quantify. Ultimately, I
> don't think Concierge will ever realistically be something that people
> download to play with it while waiting for the next bus so don't expect
> "viral" numbers. However, I know of several active users and an even larger
> number users who have at least strongly considered using Concierge once it
> is mature enough or once major road blocks outside the scope of Concierge
> (e.g., critical bundles that unfortunately have hard-wired dependencies to
> Equinox) have been cleared. Some of them are on this mailing list:-)
> Maturity---the question that I believe graduation should be centered
> around---for an implementation of a specification is pretty much binary,
> it's all or nothing. It is not easy to achieve mainstream success before
> full compliance and I think that should be taken into account. However,
> after compliance has been reached it also does not make too much sense to me
> to tag a project as incubation, assuming that the other criteria are
> fulfilled at a level that is at least comparable to where the bar has been
> set in the past. 
> 
> That all said, I definitely owe you separate graduation review material in
> which I will try to make my case and I will send this to you as soon as I
> have it ready. 
> 
> Best regards, 
> 
> Jan. 
> 
>> -----Original Message-----
>> From: iot-pmc-bounces@xxxxxxxxxxx [mailto:iot-pmc-bounces@xxxxxxxxxxx]
>> On Behalf Of Kai Kreuzer
>> Sent: Thursday, October 8, 2015 7:46 AM
>> To: PMC list for IoT top level project
>> Subject: Re: [iot-pmc] Concierge 1.0 release review
>> 
>> All,
>> 
>> I fully share Jens view and arguments.
>> It does not have to be a 0.1.0 version though, I think anything below
> 1.0.0 is
>> acceptible for a start. Afaik, many projects start with a 0.6.0 or 0.7.0.
>> 
>> Best regards,
>> Kai
>> 
>>> Am 08 Oct 2015 um 14:31 schrieb Jens Reimann <jens.reimann@ibh-
>> systems.com>:
>>> 
>>> Hello Jan,
>>> 
>>> I just did have a a look at the review information you provided and
>>> have a few comments. You might already know them since they should not
>>> be that different to the e-mails we exchanged earlier with Kai.
>>> 
>>> For new Eclipse projects it is customary to start with a 0.1.0 release.
>>> There are exceptions for projects which have had releases before
>>> coming to the Eclipse Foundation, and which do have a community which
>>> would get confused by dropping the version. For example Eclipse
>>> SmartHome (correct me if I am wrong) started with 0.6.0 since openHAB
>>> did have earlier public releases for quite a while. openSCADA did have
>>> a 1.2 version and still released Eclipse SCADA as 0.1. In your case I
>>> would expect a 0.1 release.
>>> 
>>> For graduation I would refer to [1] and would like to understand how
>>> the project fulfills these criteria.
>>> 
>>> In my personal opinion I think it is too early for graduation. This is
>>> the first release ever of Concierge, and for "getting the Eclipse way"
>>> I think it needs at least a second release in the Eclipse community
>>> before thinking about graduation. In addition I don't see much
>>> community activity around the project. But I might just not see that.
>>> 
>>> Don't get me wrong, I think Concierge is a great project and you are
>>> doing a great job! And doing a 0.1 incubation release does not mean
>>> that the project is not ready for productive use. But I do think from
>>> an Eclipse open source project's perspective it is too early for 1.0
>>> and graduation.
>>> 
>>> Kind regards
>>> 
>>> Jens
>>> 
>>> [1]
>>> 
>> https://wiki.eclipse.org/Development_Resources/HOWTO/Criteria_for_Gra
>> d
>>> uating_from_Incubation_Phase_to_Mature_Phase
>>> 
>>> On 10/07/2015 06:40 PM, Jan S. Rellermeyer wrote:
>>>> Dear IOT PMC,
>>>> 
>>>> on behalf of the entire Concierge project I would kindly like to ask
>>>> you to review and approve our 1.0 release review documentation which
>>>> can be found embedded into the project metadata:
>>>> https://projects.eclipse.org/projects/iot.concierge/releases/1.0.
>>>> We would like to combine the 1.0 release with graduation.
>>>> 
>>>> Best regards,
>>>> 
>>>> Jan.
>>>> 
>>>> Concierge project lead
>>>> 
>>>> 
>>>> _______________________________________________
>>>> iot-pmc mailing list
>>>> iot-pmc@xxxxxxxxxxx
>>>> To change your delivery options, retrieve your password, or
>>>> unsubscribe from this list, visit
>>>> https://dev.eclipse.org/mailman/listinfo/iot-pmc
>>> 
>>> 
>>> --
>>> IBH SYSTEMS GmbH
>>> D-85235 Pfaffenhofen an der Glonn
>>> Läutenring 43
>>> Geschäftsführer / CEO: Dr. Thomas Heitzig
>>> 
>>> Amtsgericht München
>>> Handelsregister Nummer  HRB 197959
>>> USt ID: DE267945175
>>> 
>>> Office Munich
>>> D 80992 München
>>> Agnes-Pockels-Bogen 1
>>> T +49 89 18 9 17 49 0
>>> 
>>> The information transmitted is intended only for the person or entity
>>> to which it is addressed and may contain confidential and/or pivileged
>>> material. Any review, retransmission, dissemination or other use of,
>>> or taking of any action in reliance upon, this information by persons
>>> or entities other than the intended recipient is prohibited. If you
>>> received this in error, please contact the sender and delete the
>>> material from any computer.
>>> 
>>> 
>>> _______________________________________________
>>> iot-pmc mailing list
>>> iot-pmc@xxxxxxxxxxx
>>> To change your delivery options, retrieve your password, or
>>> unsubscribe from this list, visit
>>> https://dev.eclipse.org/mailman/listinfo/iot-pmc
>> 
>> _______________________________________________
>> iot-pmc mailing list
>> iot-pmc@xxxxxxxxxxx
>> To change your delivery options, retrieve your password, or unsubscribe
>> from this list, visit https://dev.eclipse.org/mailman/listinfo/iot-pmc
> 
> _______________________________________________
> iot-pmc mailing list
> iot-pmc@xxxxxxxxxxx
> To change your delivery options, retrieve your password, or unsubscribe from this list, visit
> https://dev.eclipse.org/mailman/listinfo/iot-pmc