[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [Newsgroup Home]
[news.eclipse.tools.pdt] Re: PDT (was Re: Dev2QA docs) 
Hi Roy,

Thanks for your comprehensive answer! I consider this a major step towards active community interaction, if followed up by facts.

Roy Ganor wrote:
Stabilizing PDT and improving its performance are absolutely in the center of our work toward PDT 1.0.3 and PDT 1.1, also we are working hard on defining a better API, which will be robust and adhere extensibility.
This is good news. I've seen all those open tickets in the queue that prepare switching functionality to the new API models.

Development is not slow, you can browse to http://www.ohloh.net/ and check out the contribution level which is very high.
Ohloh is a bit simplistic there. In the end, development speed can't be measured in quantitative numbers of commits.
Some projects develop complete features or API rehauls in terms of a patch rolling for months or even years and then commit it altogether (=1 commit). Other projects commit every little one-line-change (=1 commit) instantly.
The "number of developers" in comparison to other projects is also questionable, as Ohloh only knows about committers, not about those who really developed the code. As the development processes differ substantially, this says nothing, absolutely nothing about the real developer base.

- Bugs filed by users usually don't receive a response for months.
- Feature requests usually never ever get a response. Even if there is a chance that the proposed feature is taken into account, there is simply no feedback.

This section contradicts your first issue, we can't enhance it until the environment is stable and robust.

Can't see why this would contradict...
What I'm asking for is not that you'd throw in every new feature someone suggests. Rather I'm asking for some feedback on every ticket. That could be a short answer like:
"Great idea, would you please elaborate on the implementation!"
"Important stop-gap measure/round-up. Scheduled for nightly YYYYMMDD"
"Completely new feature. Scheduled for version x.y."
"Considered low priority. Left open to be reconsidered by 2008-12"
"Would be a duplication of xyz's functionality. Please use that."
"Bad idea. We don't want users to do that."
...

- Time schedules are not reliable at all (let's not talk about the Ganymede Simultaneous Release...).

We should deliver things on time - that's for sure. still when someone is popping out about a question about the road map we respond.
Would be so easy to remove the worng dates and state "It's ready when it's ready!"

- Apart from the uncertainty, Integration releases are not published regularly, and they are neither commented nor documented ("What's new" etc.)

I will try to set an automatic integration build which will deliver it each weekend. 
Wow!

- Code changes by the Zend team are not discussed in Bugzilla tickets but committed without further notice.

We use pdt-dev mailing list to keep our developers updated. In the near future we will expose the new API for adopters in the Eclipse corner site.
Cool! I'm looking forward to that! Documentation and/or code commenting is very much improvable.

This is the contrary to Open Source community-building. No one would complain if the product were really good, but not even that is the case.
I can't help but this looks like Zend doesn't really want PDT to be a major success.

You saved the most important thing to the end :) I think that this issue summarises all of your sayings.

Let's define the problem - in spite of the fact that we have a fabulous community of end-users, the code contribution made to Eclipse PDT is composed of 99% of Zend's stuff, and 1% from the outside world. This is not the diversity that open source project should have, but the fact is that there are no PHP developers that contribute to Eclipse PDT. For example, in the last EclipseCon I was amazed by the people contributing to JDT / WTP / EMF.
There are surely many reasons to this. Note that some other community projects are taking great efforts to attract developers to participate. Documentation and good APIs help, also a clear definition of the goals. But the crucial aspects IMHO are a) actively invite people to help with development and b) show them what they can do and how they can do it.

Please understand that my hard criticism does not mean that I don't see the potential power of the PDT project. And yes, I'm using PDT! If I wouldn't care, I would move on to PHPEclipse or use some dedicated PHP Editor. I'm just expecting you to come off your high horse and see us either as clients to compete for or as partners to work with.

Any criticism is welcomed in the open source world but you can't really say it forever without even trying to help the development. We welcome anyone in the community to contribute and once things are tested we will be more than happy to join the contributor.
Be assured that I will actively support a PHP IDE on Eclipse. Apart from some documentation, I'm planning to contribute a plugin for specific Drupal support. The next weeks will show whether I'll support PDT or PHPEclipse or (maybe) both.

I don't want to sound like braggart but Eclipse PDT overcomes PHPEclipse in many ways (and Yes I am aware of their good progress), the first thing that make us better is that we are based on WTP that is a great framework for web development environment, the second is that we aligned with the Eclipse way that is important when working with Eclipse.
Noone says that PHPEclipse was *better* than PDT. I'd just say it's coming close to PDT and has far more community potential. PDT on the other side has the better framework to build on.

Regards, Pancho

hope this answers your questions, you are more than welcome to resume criticise and ask more question :)
- Roy 
Sure. :)

- Pancho

P.S.: Note that the last three Nightlies didn't build for some reason...