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] 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
http://wagenknecht.org/
_______________________________________________
technology-pmc mailing list
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
_______________________________________________
technology-pmc mailing list
technology-pmc@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/technology-pmc
