[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [technology-pmc] Asking for Approval of Jubula 1.0.0 Graduation/Release review
|
Mentors tend to work in different ways. Some mentors are very active in
the projects they are mentoring. Most tend to work as 'pull' resources,
answering questions when the are asked, but rarely initiating contact.
This is something that I've been working on improving with the AC.
Wayne
On 05/13/2011 01:40 PM, Achim Lörke wrote:
> Thanks for the show of confidence.
>
> Actually we've started mailing "mini minutes" to the mailing list
> (Well, actually two until now), but it is a change of process. We will
> use jubula-dev for all team communication (expect some really strange
> emails there).
>
> We are working on moving our community to eclipse.org (forum, email,
> downloads), but it will take some time. We really want this to happen
> because serving various communication channels puts unnecessary burden
> on the team.
>
> I'll bring the 2 bugs to the next Architecture Council's meeting.
> Actually I'm very much in favour of 345755 but I think 345757 is
> something a mentor could check. Maybe there are just to many projects
> for too few mentors?
>
> - Achim
>
> Quoting Wayne Beaton <wayne@xxxxxxxxxxx>:
>
>> I wonder how we might codify "Do the Right Thing"?
>>
>> I'm always hesitant to add more to the EDP. I'm always looking for ways
>> to make there be less process.
>>
>> Regardless of how this works out, we need to revisit Jubula in a couple
>> of months to make sure that all the good input provided in this thread
>> is having results.
>>
>> Wayne
>>
>> On 05/13/2011 01:09 PM, Konstantin Komissarchik wrote:
>>>
>>> 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
>>
>
>
>
> --------------------------------------------------------
> BREDEX GmbH
> Mauernstr. 33
> 38100 Braunschweig
>
> Tel.: +49-531-24330-0
> Fax: +49-531-24330-99
> http: www.bredex.de
>
> Geschäftsführer: Hans-J. Brede, Achim Lörke, Ulrich Obst
> Amtsgericht Braunschweig HRB 2450
>
