Ok. I am changing my vote to 0 (abstaining). I do not think that
proceeding to graduation in this case is in spirit of EDP, but I am
sympathetic to the impact that would likely be caused in this case
from being required to ship a 0.x release instead and I do recognize
that EDP is not perfect.
I have opened the following enhancement requests on the process in
hope that cases like this can be handled better in the future.
Bug 345755 - Consider eliminating 0.x versioning requirement for
incubating projects
https://bugs.eclipse.org/bugs/show_bug.cgi?id=345755
Bug 345757 - Consider adding informal graduation readiness review
https://bugs.eclipse.org/bugs/show_bug.cgi?id=345757
- Konstantin
*From:*technology-pmc-bounces@xxxxxxxxxxx
[mailto:technology-pmc-bounces@xxxxxxxxxxx] *On Behalf Of *Wayne Beaton
*Sent:* Friday, May 13, 2011 8:49 AM
*To:* technology-pmc@xxxxxxxxxxx
*Subject:* Re: [technology-pmc] Asking for Approval of Jubula 1.0.0
Graduation/Release review
I respectfully ask, Eric and Konstantin, that you change your minds
with regard to your -1 vote on graduation.
By my observation, the Jubula project is working in good faith and
doing the right sorts of things to demonstrate maturity in an open
source project. I believe that the project is set on the right path.
The project's newsgroup/forum is showing some signs of activity (there
are a couple of new questions there that need to be answered, BTW),
and there are a handful of bugs in the system that don't come from
project committers or Bredex employees. The Bugzilla record shows that
the project is working transparently. Alex and Achim are working
tirelessly to draw community, evidenced by the numerous speaking
engagements at conferences, Demo Camps, and more [1]. It's worth
noting that they've been building and maintaining this community for
years longer, and far more effectively than most Eclipse projects.
In an ideal world, the project would have done an incubation release
(e.g. 0.9) while in incubation, but that didn't happen. I probably
should have pushed for that.
The community behind Jubula is large and diverse. The problem is that
they are not large and diverse at Eclipse yet and they haven't been
trained to work within the open source framework (i.e. communication
via open forums, creating bugs, etc.). This leaves us with a "chicken
and egg" problem: as Markus pointed out, the existing community
regards moving to an earlier version with "incubating" code as a step
back and won't move. Graduating the project will provide the
conditions required to fully move the existing community to
eclipse.org and create the environment required to turn users from
that community into adopters and contributors.
In summary, I believe that the project meets the spirit of the
requirements for graduation, and that graduating in the Right Thing to Do.
On another note, Achim, there is no specific requirement to name your
first mature release 1.0.0. You can, for example, call it "6.0" or
"5.1" to follow on from the GUIDancer numbering scheme.
Wayne
FWIW, the Riena project had similar issues and pushed very quickly for
a 1.0 release. WindowBuilder is doing the same thing. Additionally,
[1] http://bredex.de/en/news/first.html
On 05/13/2011 02:33 AM, Achim Lörke wrote:
Well, there are to reasons we want to do a graduation. These
reasons have nothing to do with the EDP, but both are equally
important to us:
1) We deserve it! You might disagree, but the team has worked very
hard for the last 9 month to make Jubula a reality. We've rewritten
non-EPL-conform parts of the code (mostly moving from Hibernate to
EclipseLink), changed the complete build process to be compatible
with release train requirements, did lot's of IP stuff and
documents. But most important: we actually changed our development
process to an open and transparent model (from a more efficient
model we were using before). Not graduating would be very
anticlimactic.
2) We need it! (Okay, that is not completely true) We are spending
a considerable amount of money on the Jubula project. Since we are
not independently rich we have to earn this money by selling
professional services, i.e. consulting and software development. We
try to convince customers to use Eclipse technology, especially
Jubula in the testing domain. But there is one catch: a lot of
companies are reluctant to use OSS and most consider a 0.x release
beta software they won't use. Obviously that makes it harder for us
to sell services.
Of course there is room for improvement in communication. We're
working on this and value your help. We will start using the
mailing list (which we considered of minor importance) more and try
to convince our users to use more open communication. But that
changes none of the two statements above.
- Achim
On 12.05.2011, at 22:24, Konstantin Komissarchik wrote:
A negative vote on graduation should not be taken as implying
the project is
in bad shape. It is simply a statement that more work is required in
developing open source process maturity, which is what the
incubation phase
is for.
Is there a particular reason that rushing graduation is
warranted in this
case? A project can do releases while in incubation, it can
contribute to
the release train, etc. Rushing graduation simply to be able to do a 1.0
release does not seem to be in spirit of EDP.
- Konstantin
-----Original Message-----
From: technology-pmc-bounces@xxxxxxxxxxx
<mailto:technology-pmc-bounces@xxxxxxxxxxx>
[mailto:technology-pmc-bounces@xxxxxxxxxxx] On Behalf Of Gunnar
Wagenknecht
Sent: Thursday, May 12, 2011 1:06 PM
To: Technology PMC
Subject: Re: [technology-pmc] Asking for Approval of Jubula 1.0.0
Graduation/Release review
Hi All,
It seems that we are in the middle of a great discussion. I love to see
such an amount of activity on our list.
Frankly, I think there are many things to consider for making a
decision. Converting an existing commercial project into an open source
project is a tough but the right thing to do. From my experience it's a
tremendous amount of effort (if not impossible) to also convert an
existing community.
Judging project openness from the traffic on a dev list and newsgroups
isn't the right approach in this case. Eclipse is about community. But
Eclipse is also about commercial adoption. IMHO is just natural that any
user base which uses commercial support won't post to any open
forum/newsgroup but call/mail their support contact. Thus, I think it's
fair to say that the forum/newsgroup will likely represent only those
users which use the open source project (either converted from a
commercial version or really new users).
The dev list could likely need some love by sending regular meeting
minutes. I'm not sure that this has to be on a daily base. There are
many major Eclipse projects which don't publish regular meeting minutes.
BTW, there is a great article on community development here:
http://wiki.eclipse.org/Community_Development_for_Eclipse_Projects
Am 10.05.2011 14:01, schrieb Achim Lörke:
we are planning to release the 1.0.0 of Jubula (...) as part of
the Indigo release train. With this release we also want to
leave the Incubation state.
Reading through the article referenced above I don't think that Jubula
is in such a bad shape that it justifies a negative vote. Over time the
Jubula team has demonstrated some very good progress in understanding
and adopting the Eclipse processes. The amount of
information/documentation they have on the website, wiki and in Bugzilla
is quite good (IMHO).
Their code base definitely deserves a 1.0 release. The rules are that
this also requires graduation. Graduation does not, however, mean
project mentors are gone. Especially for graduating projects staying in
Technology we will be their to answer questions.
Oh and we'll also do project reviews. If in a year from now the silence
on the dev list still exists, then we can reconsider our options.
Thoughts?
-Gunnar
--
Gunnar Wagenknecht
gunnar@xxxxxxxxxxxxxxx <mailto:gunnar@xxxxxxxxxxxxxxx>
http://wagenknecht.org/
_______________________________________________
technology-pmc mailing list
technology-pmc@xxxxxxxxxxx <mailto:technology-pmc@xxxxxxxxxxx>
https://dev.eclipse.org/mailman/listinfo/technology-pmc
_______________________________________________
technology-pmc mailing list
technology-pmc@xxxxxxxxxxx <mailto:technology-pmc@xxxxxxxxxxx>
https://dev.eclipse.org/mailman/listinfo/technology-pmc
_______________________________________________
technology-pmc mailing list
technology-pmc@xxxxxxxxxxx <mailto:technology-pmc@xxxxxxxxxxx>
https://dev.eclipse.org/mailman/listinfo/technology-pmc
_______________________________________________
technology-pmc mailing list
technology-pmc@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/technology-pmc
