Bugzilla – Full Text Bug Listing
| Summary: | Comments and Community Vote for 1.0 Release Review for PDT | ||
|---|---|---|---|
| Product: | Community | Reporter: | Anne Jacko <anne.jacko> |
| Component: | Process | Assignee: | Eclipse Management Organization <emo> |
| Status: | CLOSED FIXED | QA Contact: | |
| Severity: | normal | ||
| Priority: | P3 | CC: | alcapcom, david_williams, djo, dmondark, jduimovich, lucas.bigeardel, marcelop, yossi |
| Version: | unspecified | ||
| Target Milestone: | --- | ||
| Hardware: | Macintosh | ||
| OS: | All | ||
| URL: | http://www.eclipse.org/projects | ||
| Whiteboard: | |||
|
Description
Anne Jacko
My apologies--I got ahead of myself on the review dates. The review call will be held on Wednesday, August 29. The bug will remain open for voting and comments until at least Wednesday, Sept. 5. Sorry for any confusion. I am all in for the PHP Development Tool. I would just suggest a different project name. PDT is too close to PDE and may confuse people that are not used to Eclipse. Unfortunately I have to confess that I don't have any idea for an alternative name. Marcelo, It's true that the acronyms for Eclipse projects can get a bit confusing--many of them are very similar. But PDT recently changed the project name from PHP to PDT, so I am pretty sure they aren't interested in doing yet another name change. If you're referring just to the similarity of the acronyms (and not to the projects that the acronyms represent), then we also have ECF / EMF / EPF / EPS, and ATF / ALF, etc. I think this is just something that we will have to live with if we continue our heavy use of three-letter acronyms. Personally, I like using project nicknames just because they keep me from getting confused. --EMO (Anne) If I knew the project had already been renamed, I would not have said anything ;-) I am sure that was a major pain... The 3-letters project names you've mentioned reflect exactly the type of confusion I would like to avoid. Perhaps "Eclipse" should suggest new projects (after PDT ;-) to avoid such pattern. I notice you list "jFlex" as one of your third party dependencies. Does this mean you re-distribute jFlex? That is, do you generate parsers "on the fly". I've only seen jFlex used to generate parsers ahead of time, and then the parsers themselves are re-distributed, but not jFlex itself, so ... that's why I ask. And, the follow on ... where is your input (grammar) for jFlex (sorry, I haven't looked for it yet, but I assume it's in your CVS repository somewhere?). The reason I ask is I am wonder where that grammar comes from .... is that all your own original work? Or, part of some standard? +1 It's already a good project +1 As noted during the call, I think the committer list in the presentation is not quite accurate, and I understand the project is working to get that cleaned up. Please notify us when that is done. Thanks. As discussed on the call, JFlex (and I assume that CUP thing :) are not actually distributed with PDT, they are tools used to generate the parsers, and then the parsers distributed. I do not think tools used during the development process but not redistributed need to be listed as "third party code", only code that is required to run or be distributed with the project. (But, obviously, the projects needs to well document that it uses these tools, how to re-generate the parser from source, etc.). I guess there's no harm in listing them, having them reviewed, etc., but can be confusing. So, if they continue to be listed as the projects third party code, perhaps a big note that they are not re-distributed and not required to run would be helpful. (Adopters would care about that difference). During the call, the project also indicated they were still discussing whether or not to be part of Ganymede simultaneous release. I just thought I'd document my opinon here that they should. This is obviously not part of this release review, but in general, having predicable yearly releases is one thing that Eclipse projects are well known for, and the yearly release train is a good way to accomplish that and, in my opinon, a sign of project maturity and Eclipse Citizenship -- though, of course, not required. +1 +1 for document reviewed +1 Loving it. PHP coding is no longer the same! :) Thanks guys These votes were cast using Bugzilla voting. These will count as +1 votes on the bug. marc.miller@amd.com sang@parasoft.com vermersch+eclipse@gmail.com martijn@iodsesam.nl martin.eisengardt@fiducia.de yossi@zend.com +1 I look forward to the PDT community growing and PDT becoming part of the Ganymede release train. Congrats to all the PDT team. Voting is now closed for this review. Results: +1: 12 votes 0: no votes -1: no votes The +1 votes include each level of the project leadership chain. The EMO has declared this review to be successful. Thanks for voting. Closing the bug. |