Community
Participate
Working Groups
For historical reasons, projects have to describe their newsgroups and mailing lists in two places: once in the project-info.xml file and once in the maillist or newsgroup file. We should use a single file (project-info.xml) and we should do it in a backward compatible way, i.e., support both schemes for a while and then slowly convert the projects to the single way.
Created attachment 38621 [details] widget to generate an "unified" project-info.xml file So, how about this: Currently there's a tool http://www.eclipse.org/projects/web-api/project-info-xml.php?project=<key> that generates a valid project-info.xml file, it was ment as transition from .dates.txt, or startup for those who didnt even had .dates.txt. Right now, it does the following (given a project key): a) if project-info.xml exists, it reads the file and just outputs the XML. b) if the .dates.txt, exists, it reads the file and generates a project-info.xml from there, wich is mostly empty since .dates.txt only includes releases information. c) if there's no .dates.txt nor project-info, it generates an empty anotated example, so the project leader fills in all the blanks. The idea would be to modify project-info-xml.php to make it read the information from all valid sources (.dates.txt, maillist, newsgroup, database, et al.) and generate a valid project-info.xml file from that information. What do you guys think? Here's an example of what it does righ now: having a project-info.xml: http://www.eclipse.org/projects/web-api/project-info-xml.php?project=technology.ptp having .dates.txt only: http://www.eclipse.org/projects/web-api/project-info-xml.php?project=tools.ve having nothign: http://www.eclipse.org/projects/web-api/project-info-xml.php?project=tools.hyades
Accepting the Bug
Pretty cool. Of course we (you) will need to link it into the documentation and to the bottom of the Timeline page so that people can find and use the tool.
(In reply to comment #3) > Pretty cool. > Of course we (you) will need to link it into the documentation and to the > bottom of the Timeline page so that people can find and use the tool. > So, i was looking at the bug, but came into this http://www.eclipse.org/vep/project-info/maillist In this file the comment spans several lines, the other files i checked didn't, so the real question here is, What's the format for project-info/maillist and project-info/newsgroup? Also, i'm taggin newsgroups and mailing-lists comming from those files with a source="" attribute, like this: <mailing-lists> <list name="wtp-jst-dev" source="maillist"/> <list name="wtp-wst-dev" source="maillist"/> <list name="wtp-releng" source="maillist"/> <list name="wtp-jsf-dev" source="maillist"/> <list name="wtp-dev"/> <list name="wtp-pmc"/> <list name="wtp-requirements"/> <list name="wtp-jst"/> <list name="wtp-wst"/> <list name="wtp-jsf"/> </mailing-lists> Is this fine? It shouldn't break nothing, but maybe we don't need to know where the mailinglists/newsgroups came from.
The maillist and newsgroup files share the same format. Basically it's ::list title::desc The seperator is :: and you can have n lines between one :: and the next. It's up to the groups how long the descriptions are. -M.
Why do you need the source? I think something like: <list name="wtp-jst-dev">This is a list where the web tools platform Java team hangs out and discusses J2EE issues.</list> would be a fine combination of the project-info.xml and the maillist data.
Created attachment 39734 [details] project-info-xml.php + mailinglist + newsgroups project-info-xml merges project-info.xml and /project-info/maillist and /project-info/newsgroup. If no project-info.xml is .dates.txt is used, to generate an empty XML with releases information, newsgroups and maillist If no .dates.txt is avaliable, the XMl will only include newsgroups and maillists. This patch also includes fixes for the following bugs: 109222 106559 113716 137437
Marking fixed to trigger the review A few examples: /projects/web-api/project-info-xml.php?project=webtools input: xml, newsgroup - adds Newsgroups (at the bottom, no newsgroups on XML) /projects/web-api/project-info-xml.php?project=technology input: xml, newsgroup, maillist - adds newsgroups (at the bottom, no newsgroups on XML) - adds a mail-list /projects/web-api/project-info-xml.php?project=technology.alf input: maillist, newsgroup - generates a brand new XML (empty, with comments) - adds mail-list - adds newsgroups /projects/web-api/project-info-xml.php?project=birt inputs: xml - does nothing exceptional, just outputs the XML =)
Created attachment 39737 [details] project-info-xml.php + mailinglist + newsgroups + db error handling project-info-xml.php + mailinglist + newsgroups project-info-xml merges project-info.xml and /project-info/maillist and /project-info/newsgroup. If no project-info.xml is .dates.txt is used, to generate an empty XML with releases information, newsgroups and maillist If no .dates.txt is avaliable, the XMl will only include newsgroups and maillists. This patch also includes fixes for the following bugs: 109222 106559 113716 137437
Created attachment 39796 [details] Same patch as last with a bug fix.
Created attachment 40448 [details] Cumulative patch from last week and this week
The latest patch includes fixes for bugs: 109222 137441 138534 106559 113716 137437
bug 109222 bug 137441 bug 138534 bug 106559 bug 113716 bug 137437
Patch applied.
The documentation (http://www.eclipse.org/projects/dev_process/project-status-infrastructure-page2.php) is not updated.
Patch from bug 140952 applied.
Here's the URL: http://eclipse.org/projects/web-api/project-info-xml.php It's called "Project-Info Generator" in http://www.eclipse.org/projects/dev_process/project-status-infrastructure-page2.php
Reopening.
Old title: Merge the maillist and newsgroup files with the project-info.xml file New plan: convert the text and xml files containing project meta-data into a database table that is accessed via the portal. On the positive side, this will make it easier to write tools and read and use this data. On the negative side, the information will no longer be version controlled in the CVS directory. (Thus the new database table should have a second history stable like the Foundation database has.) On another positive side, this allows the provisioning system to automatically populate this data (for example, when a new newsgroup is created, it can be added to the data without waiting for the project to update it). 1. create the database tables 1.1 the data table (project, key, value) 1.2 a keys-descriptions table to remind us what the keys are 1.3 a history-of-changes table 2. create the portal component for modifying the tables 3. use a script to load all the existing project-info meta-data into the database 4. change the uses of the metadata (especially the project-specific left menu generator) to use the database 5. notify all committers of the switch in storage 6. a weekly script that looks for changes to the old files; if it finds a change, it sends email to the project committers telling them "that change is not being used; you need to update the data via the portal"
See current project-info text file format here: http://www.eclipse.org/projects/dev_process/project-status-infrastructure-page2.php
*** Bug 194307 has been marked as a duplicate of this bug. ***
Targetting this for Q3 and moving to Phoenix. Two elements of project-info that I want closer control over are the newsgroups and mailing lists, as I want the list of both of those resources to be the database. I'll then write tools that will create new newsgroups and mailing lists automatically from the database information, while still allowing committers to update descriptions etc. from the portal. This will also allow us to automate the creation of archives, mail aliases, etc. Nathan and I will come up with a plan and workflow to have all this happen.
Here are my requirements for the project-info database: project name (but it probably comes from the master database) project home page url cvs/svn source code location download page url documentation url ip log url update site url main wiki page url main newsgroup other newsgroups main dev mailing list other mailing lists main blog url other blog urls descriptive paragraph project plan url getting started url bugzilla product and component releases (name, status, date/estimated date, download url, description/plan url) - see current project-info.xml documentation other things I see as necessary, but are not directly used by any of my (/project) code: for each newsgroup, a description for each mailing list, a description
(In reply to comment #23) > Here are my requirements for the project-info database: > Great List Bjorn, this covers all the things I would need in order to migrate the Category pages.
Gosh I wish I knew about the existence of Eduardo's script merging all the files into a single XML before Matt and Nathan had to import their data themselves. From XML my script could have loaded all of it. :( In any case I don't see anything in comment #23 that is missing now. I am updating the DB with the project url now.
Sorry guys, looks like I had this information and didn't notice it. :(
Denis, Karl, and Myself have written two new classes for accessing the ProjectInfo data on Phoenix. /eclipse.org-common/classes/projects/projectInfo.class.php /eclipse.org-common/classes/projects/projectInfoList.class.php These new files provide the accessor classes for the data to be leveraged quickly and easily. class ProjectInfo(projectID); This class takes a projectID as a parameter and will retrieve all data associated with that project upon creation. class ProjectInfoList(); This class takes no paramaters upon creation. The most valuable function in this class is function selectProjectInfoList($_projectID , $_mainKey , $_subKey , $_value, $_projectInfoID , $_order_by) All paramaters are defaulted to NULL to allow the user to sort / filter out the values that they want to return. This function returns an array of projectInfo classes for consumption Since this is a change to eclipse.org-common it will require 3 +1's to be accepted.
(In reply to comment #27) > Since this is a change to eclipse.org-common it will require 3 +1's to be > accepted. > Of course, this looks good to me. +1 FWIW, we designed the API with ease-of use in mind, so committers can easily use the project info like this in their own pages: $App->useProjectInfo(); $ProjectInfo = new ProjectInfo("technology.phoenix"); $project_name = $ProjectInfo->getValue("projectname"); # contains "Phoenix" echo "Download page: " . $ProjectInfo->getValue("downloadurl"); Once this is committed, we'll need to: - document the API in our docs - document the key names (such as projectname, downloadurl, etc) - provide code examples via the Phoenix website
+1
Implemented and rolled out. Yahoo!
Verified. Closing.
