[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[dsdp-pmc] mtj-dev thread
- From: "Gaff, Doug" <doug.gaff@xxxxxxxxxxxxx>
- Date: Wed, 13 Jun 2007 07:58:56 -0700
- Delivered-to: email@example.com
- Thread-index: Acetp3QF/JbnCY3VTRKIhXDaJvKnbgAACAowAAfDzyAAASS2IA==
- Thread-topic: mtj-dev thread
I know this is a bit of dirty laundry, but we need to do our job as the PMC and discuss this issue tomorrow. Mika, I trust that you are still able to attend the meeting?
From: Gaff, Doug
Sent: Wednesday, June 13, 2007 10:56 AM
To: Mobile Tools for The Java Platform mailing list
Subject: RE: [dsdp-mtj-dev] Latest Changes
I think it's time for me to weigh in here. Put simply, the MTJ project is not following the Eclipse Development Process, and it's a real problem that must not be ignored.
The progress that Nokia has made on this project with the limited commitment of developers is certainly impressive. I commend Nokia for that work. However, Eclipse projects aren't supposed to be run as internal development projects. The point of releasing technology in Eclipse is to create a community of developers, a community of users, and a community of companies that depend commercially on the project. To build these communities, a project must be transparent in project plan, architecture, development, check-ins, meetings, etc. Demonstrable proof of these communities is required to exit the incubation stage and have a 1.0 release. Closed projects die slowly and painfully.
Sadly, as far as I can tell from the outside, MTJ has virtually none of these three communities. The lack of transparency is certainly one of the root causes. Another appears to be the lack of commercial need for the project.
I am a big supporter of what MTJ is building. You are building a viable competitor to NetBeans in the device space. You are working towards a unification of Eclipse and EclipseME. You are filling a technology hole in Eclipse that is desperately needed. Yet, I am very concerned about the future of MTJ. I need you all to start sharing this concern and start recognizing that your project is in trouble. You will all have to decide whether or not you want to save it.
Tomorrow, the DSDP PMC meets. This will be one of our topics of conversation. Please get your feedback and comments to Mika.
DSDP PMC Lead
From: dsdp-mtj-dev-bounces@xxxxxxxxxxx [mailto:dsdp-mtj-dev-bounces@xxxxxxxxxxx] On Behalf Of Arto.Laurila@xxxxxxxxx
Sent: Wednesday, June 13, 2007 6:58 AM
Subject: RE: [dsdp-mtj-dev] Latest Changes
Yes, I agree.
Currently there are defined tasks which we are working on.
When reporting with bugzilla entry that what we have done, it should be enough.
The issue that if there is not enough bugzilla entries to all tasks, btw. has that
been agreed earlier on any of our telcos. Allthough this goes to Rauno & Mika.
Kind a thing that there are several things tha how we do differ from some standard
Eclipse project and as a question that in what terms we do see what are the standards
for a Eclipse project. How do we differ from that, should there be changes and if so , why.
If now we have worked so long and this working way has been able to produce results,
it's quite difficult to make changes to this just before the summer & autumns release plan.
I would understand this more in the projects earlier stage, where there are a lot of tasks
This way using bugzilla would be nice to take in use in the next development cycle.
>[mailto:dsdp-mtj-dev-bounces@xxxxxxxxxxx] On Behalf Of ext Craig Setera
>Sent: 13. kesäkuuta 2007 13:42
>To: Mobile Tools for The Java Platform mailing list
>Subject: Re: [dsdp-mtj-dev] Latest Changes
>I understand what you are saying, but please take a look at
>the standard for the other Eclipse projects. All projects
>translate their project plan items into one or more bugzilla
>entries. Each commit then references a bugzilla entry (which
>in turn references a plan entry). In that way, it is easy to
>look at CVS resource history and understand why a particular
>change was made.
>Although the community is small at this time, it will never
>grow if people can't see and *understand* what is going on
>within the project.
>PS - I know that we have discussed the process I just
>discussed in person within the core group and agreed it was
>the right approach.
>> As discussed about this in earlier, the development is done
>> against the agreed task contents.
>> On the active and priorized task list, please refer to the
>> During development, there will be commits on those task
>> implementations and also commits on while fixin some bugs.
>> As the MTJ community is rather small, the main development
>is done in
>> Nokia internally.
>> As there is actually only you Kevin from the MTJ community, that has
>> done during this release one plugin, I propose that our internal
>> development should not be taken in here.
>> As currently, there are Bugzilla bugs, which contains a
>> those tasks that are included that specific commit.
>> I'm not creating a new bugzilla entry on every commit, and I do not
>> believe that need for that.
>> Who ever that wan'ts to keep in sync to the development,
>must keep him
>> self in sync with the CVS sources.
>> If that person is not the component owner, this is actually the only
>> way to understand that whats going on.
>> The component owner will implement the component, provide needed
>> information about the functionality and a notice when the
>> As discussed in earlier, the development is targeting to do the
>> active, priorized tasks in the project plan.
>> If there are any open issues in the current work, that you wan't to
>> change, or take ownership, please open this issue a bit more.
>dsdp-mtj-dev mailing list
dsdp-mtj-dev mailing list