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
_______________________________________________
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
