Community
Participate
Working Groups
As part of the restructuring of DSDP, the Target Management Project (minus TCF) will be moved under the Tools PMC: http://wiki.eclipse.org/DSDP/Restructuring_Review#The_Rest_of_TM This bug is to track required actions and progress: - inform/get in touch with Tools PMC - move website from /dsdp/tm to /tm (with redirect) - move Wiki from /DSDP/TM to /TM (with redirect) - can this be done en bloc by Webmaster? There's lots of pages and refs - move Downloads from /dsdp/tm to /tm (with redirect) - change feature text and icons in CVS to remove DSDP reference - change product/component in ipzilla - change bugzilla classification - has implications on queries in websites - change projectid? Has implications on projectplanurl etc Open questions: - move CVS? Is it worth the effort? Is redirect possible, or would the old /dsdp CVS be changed to read-only for building old service releases? Or should we change to git while we're at it? - decommitterize TCF-only committers? (Eugene Tarassov, Felix Burton) - what to do with the vserver, dsdp.eclipse.org ? Currently serving TM help - mark DSDP homepage as archived?
Q: also change mailing list and newsgroup/forum names ?
(In reply to comment #0) > Open questions: > - move CVS? Is it worth the effort? Is redirect possible, or would the old > /dsdp CVS be changed to read-only for building old service releases? Or > should we change to git while we're at it? The object probably should be to remove the dsdp areas from CVS and SVN. However, since we're in the middle of development towards Indigo we might want to hold off until the summer or later. > - decommitterize TCF-only committers? (Eugene Tarassov, Felix Burton) This will likely fall out of your regular inactive committer clean-up. > - what to do with the vserver, dsdp.eclipse.org ? Currently serving TM help You can probably keep that or rename it. It's a little troubling that used the vserver for production use. But that's a different issue. > - mark DSDP homepage as archived? No opinion. It could also be simply removed.
(In reply to comment #1) > Q: also change mailing list and newsgroup/forum names ? Yes, this needs to be done as well. This biggest issue is making sure your community finds your new home. I'm not sure what the make-up is so you'll need to come up with the strategy that makes the most sense for you.
Are we ready to rock and roll here? I'm ready to verify legal paperwork, make committer changes (as identified) and align CQs to new top level project? Standing by... Thanks, Sharon
Well as for myself... given that DSDP no longer exists formally, I guess I'm kinda waiting for a "welcome, please join us" from Tools PMC...
(In reply to comment #5) > Well as for myself... given that DSDP no longer exists formally, I guess I'm > kinda waiting for a "welcome, please join us" from Tools PMC... Well in that case ... welcome, please join us! Moving TM to Tools was discussed and approved on tools pmc list some time ago. If there is anything more concretely needed from us, let us know.
Good! That ticks off item 1 from my list :) I guess the next thing I'd like is get some feedback from webmaster regarding the technical details (what to do when and how). Moving the website with redirect could be first since it's non-breaking; ProjectID could also change relatively easily with little adjustments. Not sure about other steps, input appreciated! From a legal point of view, Sharon I think we're good to go since the votes are all in from what I can tell.
PS one "kinda legal" question. TM has used the http://eclipse.org/dsdp/dsdp-charter.php as its project charter. As we move under tools, will we need a new charter? Wayne?
tools.tm has been created in the Foundation Database.
(In reply to comment #8) > PS one "kinda legal" question. TM has used the > http://eclipse.org/dsdp/dsdp-charter.php > as its project charter. As we move under tools, will we need a new charter? > Wayne? Only top level projects have a charter. TM requires only a scope as specified in the project proposal.
(In reply to comment #0) > - move Wiki from /DSDP/TM to /TM (with redirect) > - can this be done en bloc by Webmaster? There's lots of pages and refs Not really, it's a page by page thing. > - move Downloads from /dsdp/tm to /tm (with redirect) How long should this be in place? We do this via the apache config itself so it's nice to include a note about when a rule can be removed. > - change bugzilla classification - has implications on queries in websites I can do that. > - move CVS? Is it worth the effort? Is redirect possible, or would the old > /dsdp CVS be changed to read-only for building old service releases? Or > should we change to git while we're at it? Moving CVS should be pretty straight forward, or you can transition to Git. > - what to do with the vserver, dsdp.eclipse.org ? Currently serving TM help I'll check what the list of projects looking for a vserver is like. Is there a reason the help isn't included at help.eclipse.org? > - mark DSDP homepage as archived? When the whole project is 'archived' I'll drop a redirect to the archived page. -M.
(In reply to comment #11) > > - move Wiki from /DSDP/TM to /TM (with redirect) > > - can this be done en bloc by Webmaster? There's lots of pages and refs > Not really, it's a page by page thing. Ugh, that hurts! No way out, really? No smart python/find/sed scripts along with an mv on the file system? > > - move Downloads from /dsdp/tm to /tm (with redirect) > How long should this be in place? We do this via the apache config itself so > it's nice to include a note about when a rule can be removed. Shouldn't be long ... just to avoid disruption of service while the webpages get restructured and not all links have been migrated yet. I do not think people have bookmarks to download. I could probably also create the new structure on download and use symlinks to the old content while transitioning... that would avoid the need for apache config. Same for the webpages I guess... I could duplicate the current structure under /tm and then just delete the old ones + redirect when done. I'll just need to have the initial /tm page created and get CVS access to it. > I'll check what the list of projects looking for a vserver is like. Is > there a reason the help isn't included at help.eclipse.org? Help for released versions is served from help.eclipse.org -- but we use dsdp.eclipse.org to serve help for the nightlies. Quite helpful for checking final help rendering, and discussing the Javadocs for new APIs/features.
> > > - move Wiki from /DSDP/TM to /TM (with redirect) > > > - can this be done en bloc by Webmaster? There's lots of pages and refs > > Not really, it's a page by page thing. > > Ugh, that hurts! No way out, really? No smart python/find/sed scripts along > with an mv on the file system? LOL When in doubt, use sed. And awk. But unfortunately, the wiki pages are in a database. We hate mucking with the SQL backend since this often leads to more problems. FWIW, this is why we've been omitting the top-level project from the namespaces for new projects (newsgroups/forums, downloads paths, etc.) ... it makes moves so much simpler.
> Same for the webpages I guess... I could duplicate the current structure under > /tm and then just delete the old ones + redirect when done. I'll just need to > have the initial /tm page created and get CVS access to it. When we have a date for the actual move I can move the old pages to /tm and put a redirect in to point from dsdp/tm to the new location. -M.
I've moved all remaining Ipzilla CQs from dsdp.tm to tools.tm. I've verified all the remaining active dsdp.tm committer paperwork; there are no barriers to prevent any of the committers from moving to tools.tm. Webmaster: As usual, appreciate your help to script those changes in the DB. Please note I updated the DB to remove access to dsdp.tm for Eugene Tarassov and Felix Burton. Their access to tm will need to removed on the unix side as part of this exercise. Both Eugene and Felix remain tcf committers (access in place). I believe that completes things from my side. Regards, Sharon IP Team
Ok so when is a good time to finish this move? -M.
Before we fix a date, I would like to get a better feeling of what the move means for committers and adopters. Especially, how does the CVS move affect existing committers' workspaces... can the Repository be changed en block for multiple projects? Does it work while files are being checked out or should the workspace be clean? I do think I could handle bugzilla and webpages, I'm not happy at all about Wiki. Not sure about mailing list and newsgroup (I assume that the old group will be discontinued and new one started from scratch? Will mailing list subscribers remain subscribed? I assume E-Mail filters will need changing?) I think I'd like to send a note upfront to the mailing list informing about the change, what the change means for committers and how they need to act. Then, agree on a date with committers. I assume that other project which have been through a move have some experience here? Our Indigo M4 is on Dec 13, this date must not be jeopardized.
(In reply to comment #17) > Before we fix a date, I would like to get a better feeling of what the move > means for committers and adopters. Fair enough. > Especially, how does the CVS move affect existing committers' workspaces... can > the Repository be changed en block for multiple projects? I"m not sure what you're asking. While moving CVS isn't trivial, it's certainly fairly straight forward. > Does it work while files are being checked out or should the workspace be clean? On the move day we(Webmaster) will 'freeze' the source repositories and then copy them to the 'new' locations. You may be able to update your workspace settings to point at the new location, but it's probably 'safer' to just check them out again. > I'm not happy at all about Wiki. I understand. > Not sure about mailing list and newsgroup (I assume that the old group > will be discontinued and new one started from scratch? Yes. We keep the archives online, so you won't lose anything. > Will mailing list subscribers remain subscribed? I assume E-Mail filters will need changing?) Subscribed to the new list? No, we make every effort to avoid forcing people onto mailing lists. > I think I'd like to send a note upfront to the mailing list informing about the > change, what the change means for committers and how they need to act. Then, > agree on a date with committers. I assume that other project which have been > through a move have some experience here? Sure, you could touch base with the Sequoyah folks who recently moved and are moving again. > Our Indigo M4 is on Dec 13, this date must not be jeopardized. Ok, so we know the earliest date is Dec 14th. -M.
> I'm not happy at all about Wiki Let me think of something. Yes, it will likely involve sed. And curl.
Actually I think that we should have TCF moved into CDT before we finalize TM moving to tools ... so we depend on bug 327950. If we don't wait for TCF to move first, there is a risk of breaking some TCF work while the parent project moves.
(In reply to comment #20) > Actually I think that we should have TCF moved into CDT before we finalize TM > moving to tools ... so we depend on bug 327950. > > If we don't wait for TCF to move first, there is a risk of breaking some TCF > work while the parent project moves. TCF has it's own root in SVN. You don't need to wait for us.
(In reply to comment #19) > Let me think of something. Yes, it will likely involve sed. And curl. Denis, I'm going to wait for your feedback about auto-renaming Wiki before I proceed on other things. I'd like to transition all in one step, and Wiki is an important part. Thanks!
So... TM 3.3m4 has been released, and I'm ready to rock'n'roll here. I have already manually renamed some of the Wiki. I plan keeping old (archived) meeting minutes in the DSDP space, that way renaming is manageable manually. I'll need webmaster support for the next steps: - create new newsgroup - create new mailing lists (tm-dev, tm-cvs-commit) - copy webpage CVS to tools - create area on download that I can access via SSH on build.e.o Last steps should be moving CVS, changing bugzilla classification, and changing the projectid in foundation database. I'd like to know a time for this in advance, such that I can announce the migration date on the mailing list. All the rest is ready to go. For webpages, I'd like to have a COPY which I can modify. Same for the download area, newsgroups, mailinglist - keep old stuff in place until I'm done with the new ones. Thanks!
When do you want to get started with these last steps? I've queued the mailing lists and newsgroup so they should be ready by tomorrow. -M.
Hm, this depends a little on how well the first steps proceed :) Ideally, I'd send out a note about the migration this week, suggesting some time next week for moving CVS and Bugzilla. The actual date would be pending committer response, since there shouldn't be any pending checkouts in anybody's workspace at the time we move. In case updating the webpages takes longer than expected, I might have to postpone the CVS move to early next year, but I'd hope we can avoid that and start the new year under Tools.
The mailing lists and newsgroup have been created. Can we move do the CVS copy next tuesday(the 22nd)? -M.
Fine for me, I will announce on the newsgroup. But I'll want to create the webpages under their new home first. Can you copy the org.eclipse/www/dsdp/tm CVS repo --> org.eclipse/www/tm such that I can start working on it?
I'd also like to know whether the old DSDP-TM Newsgroup and mailing list archives will remain web accessible such that people can search older messages or quote them by URL? I'd like to put that into my Newsgroup Welcome Message. Thanks!
Ok, I've copied the website to org.eclipse/www/tm so you should be able to work on it. The dsdp-tm-dev mailing list archive will remain online here: https://dev.eclipse.org/mhonarc/lists/dsdp-tm-dev/ 'Older' newsgroup postings are here: https://dev.eclipse.org/mhonarc/newsLists/news.eclipse.dsdp.tm , but the newer archive should be available via the standard forums interface. -M.
Thanks, website update works. Could you now provision the download area, please, such that I can move our downloads: moberhuber@build:/home/data/httpd/download.eclipse.org/dsdp/tm> cd ../../tm -committer_shell: cd: ../../tm: No such file or directory
PS will we also have /shared/tools/tm on build.eclipse.org ?
Done. -M.
Ok, I've copied the CVS to cvsroot/tools . -M.
Thanks! Can you put the old /cvsroot/dsdp/ stuff to read-only mode? /cvsroot/dsdp/org.eclipse.tm.core /cvsroot/dsdp/org.eclipse.tm.rse
Thanks! We'll now need an area for signing, can you create this please, e.g. /home/data/httpd/downlad-staging.priv/tm
Also, what UNIX groups should I use now instead of "dsdp-tmadmin" and "dsdp-tm-rse" in my scripts ?
I've created /shared/download-staging.priv/tools/tm . The group is: tools.tm -M.
Thanks! Does having a single group mean that *all* files (including downloads and webpage) should be owned by tools.tm and thus be write-accessible for all committers ?
(In reply to comment #39) Yes. The one project = one group standard is something we've been pushing for the last couple of years. -M.
(In reply to comment #40) > (In reply to comment #39) > > Yes. The one project = one group standard is something we've been pushing for > the last couple of years. > > -M. For completeness, this policy reflects the EDP.
Fine for me. Thanks! I think the final step of the move will be changing bugzilla classification from "DSDP" to "Tools". This is just a heads up for now -- I'll want to finish the CVS, Build, Website and Wiki changes before doing Bugzilla.
TM CVS has all been migrated, builds are running off tools. Remaining tasks (for webmaster): - Install CVS triggers to send to the tm-cvs-commit mailing list for "org.eclipse.tm.core" and "org.eclipse.tm.rse" CVS modules in /tools - Change bugzilla classification from "DSDP" to "Tools" for the bugzilla "Target Management" project - Website Redirect /dsdp/tm --> /tm - Downloads Redirect /dsdp/tm --> /tm - Migrate/archive/delete dsdp.tm Portal data --> tools.tm - Archive/delete stuff under /dsdp (is there a value in keeping dsdp CVS for historical builds?) And finally, find a new home for the TM services on the dsdp.eclipse.org vserver.
Just to clarify, in the portal I don't have access to "tools.tm" metadata at the moment - only dsdp.tm. I'll need to get "tools.tm" access in order to fix some settings like downloads location, homepage, newsgroup etc in the Portal.
When finalizing the website move, I noticed that we'll also need to migrate the bugzilla inbox names: dsdp.tm.core-inbox dsdp.tm.rse-inbox I'm not sure how that's best done, some people might be watching these and/or have queries involving these.
(In reply to comment #43) Webmaster, any ETA on the outstanding tasks from comment 43 ? I think that I have done all I can do as a PL to complete this, now we need your help to finish off. Thanks!
Sorry about dropping the ball on this. I'll get started right now. -M.
(In reply to comment #43) > - Install CVS triggers to send to the tm-cvs-commit mailing list Done. > - Change bugzilla classification from "DSDP" to "Tools" Done. > - Website Redirect /dsdp/tm --> /tm Done. > - Downloads Redirect /dsdp/tm --> /tm I've added it to the config and will restart apache in the morning. > - Migrate/archive/delete dsdp.tm Portal data --> tools.tm I've moved the dsdp.tm data to tools.tm > - Archive/delete stuff under /dsdp > (is there a value in keeping dsdp CVS for historical builds?) Good question. > And finally, find a new home for the TM services on the dsdp.eclipse.org > vserver. I think this is going to require more discussion (in terms of where). (In reply to comment #45) > When finalizing the website move, I noticed that we'll also need to migrate the > bugzilla inbox names: > > dsdp.tm.core-inbox > dsdp.tm.rse-inbox > I don't think the watchers will be impacted if I 'update' the names, but the queries I don't think I can do anything about. -M.
(In reply to comment #48) > > (is there a value in keeping dsdp CVS for historical builds?) > Good question. Our legacy builders for Streams down to TM 3.0 now use the /cvsroot/tools repository, so I don't think anyone will need the DSDP repos. > > dsdp.tm.core-inbox > > dsdp.tm.rse-inbox > > > I don't think the watchers will be impacted if I 'update' the names, but the > queries I don't think I can do anything about. I can update the queries that we publish on our website, so I'm in favor of renaming. Please let me know what the new names will be. I guess the next steps are now for me: - edit the moved Portal Metadata to refer to the new mailinglist, newsgroup, downloads etc. - finalize website changes to refer to the new portal metadata - announce the new mailing lists, newsgroup and bugzilla classification - discuss what to do with dsdp.eclipse.org
- I also need to announce the move on cross-project and ask the Simultaneous Release Build and Tracker use the new name.
Matt, could you please check the Portal Metadata for consistency? It looks like something went wrong with the committer lists. As per http://eclipse.org/tm/development/contributors.php these committers should have been decommiterized a while back, but they show up for tools.tm at the moment: Javier Montalvo Orus Kushal Munir Ted Williams Checking the dsdp.tm committer list it also appears broken (no IBM committers there, should include David McKnight, David Dykstal, Xuan Chen, Kevin Doyle).
(In reply to comment #49) > I can update the queries that we publish on our website, so I'm in favor of > renaming. Please let me know what the new names will be. My choice would be: tm.core-inbox tm.rse-inbox (In reply to comment #51) > these committers should have been decommiterized a while back, but they show up > for tools.tm at the moment: > Javier Montalvo Orus > Kushal Munir > Ted Williams Sigh, looks like the automated move didn't notice the expiry date on these folks. I've removed them > Checking the dsdp.tm committer list it also appears broken (no IBM committers > there, should include David McKnight, David Dykstal, Xuan Chen, Kevin Doyle). Where are you seeing this? I see all of these folks as committers(inactive) on dsdp.tm . -M.
(In reply to comment #52) > tm.core-inbox > tm.rse-inbox Looks good, please move forward with this. > > Checking the dsdp.tm committer list it also appears broken Project Lead for: dsdp.tm -> Members of dsdp.tm Committers Anna Dushistova Martin Oberhuber Uwe Stieber Project Leads Martin Oberhuber It should either give an empty list, or a complete list including the IBM'ers.
Another issue: The IP Log shows no committers as active. Is this something that should fix itself automatically once a database is reloaded over night? http://www.eclipse.org/projects/ip_log.php?projectid=tools.tm
(In reply to comment #54) > Another issue: The IP Log shows no committers as active. Is this something that > should fix itself automatically once a database is reloaded over night? > > http://www.eclipse.org/projects/ip_log.php?projectid=tools.tm Matt, the committer active dates need to be set to the corresponding values from dsdp.tm.
Ok I've : -Renamed the bugzilla inboxes. -Reloaded the download apache server with the re-write rule in place and it seems to be working. -Cleaned up the 'ActiveDates' for the tools.tm project so the IPlog should generate correctly now. -Set an inactive date for all outstanding dsdp.tm committers so the list should now be empty. -Marked dsdp.tm as inactive and archived in the Foundations internal project database. -M.
(In reply to comment #54) Hm... on the IP log, still all committers show up as "never active". And, previous committers (like Javier Montalvo) are missing. I do think they need to be listed in the IP log since they made contributions to the repository. http://www.eclipse.org/projects/ip_log.php?projectid=tools.tm Other than that, it looks like we're almost done... remaining tasks for me: - find a solution for dsdp.eclipse.org - fix website links still pointing to the DSDP charter FWIW, on bug 334185 David Williams asked what to do with the dsdp.sequoyah.b3aggrcon dsdp.mtj.b3aggrcon Indigo contributions ?
(In reply to comment #57) > Hm... on the IP log, still all committers show up as "never active". And, > previous committers (like Javier Montalvo) are missing. I do think they need to > be listed in the IP log since they made contributions to the repository. The statistics gathering process runs once each week on Sunday. I gather that the project metadata wasn't updated in time for last Sunday's run; it should appear next Monday.
As per bug 334185 comment 2, I had to manually re-enter the simultaneous release tracker information. I'm not entirely sure I got everything right (ie as it was for Helios). It would have helped to have the old data still available ... but the old dspd link no longer works: http://eclipse.org/helios/planning/SimultaneousReleaseOverview.php?action=project&projectid=dsdp.tm
Hm... it's Monday, and on the TM IP Log still all committers show up as "Inactive", why? http://www.eclipse.org/projects/ip_log.php?projectid=tools.tm I double checked our project metadata for tools.tm and it looks all good.
(In reply to comment #60) > Hm... it's Monday, and on the TM IP Log still all committers show up as > "Inactive", why? > > http://www.eclipse.org/projects/ip_log.php?projectid=tools.tm > > I double checked our project metadata for tools.tm and it looks all good. Not sure. Everything does seem to be in place. I have opened Bug 334528 to separate that investigation from this bug. Feel free to add a dependency if you feel it's warranted.
(In reply to comment #60) > Hm... it's Monday, and on the TM IP Log still all committers show up as > "Inactive", why? > > http://www.eclipse.org/projects/ip_log.php?projectid=tools.tm > > I double checked our project metadata for tools.tm and it looks all good. All better now. I had to resolve some script "funniness". I manually invoked the updated scripts to update tools.tm and it appears to have fixed things. Please take a look on Monday after the master script runs to make sure that it "sticks" (it should, but without rerunning the whole thing it's hard to know for sure).
IP Log and Dash statistics look good now - thanks Wayne! One thing I find odd is that on our project summary page, all Wind River committers are listed twice. Is there some duplication in the database for WindRiver and Intel? Or is it because the project has 2 CVS repositories? http://www.eclipse.org/projects/project_summary.php?projectid=tools.tm Other than that, it looks like we're pretty much done with the move. Remaining tasks for me: - find a solution for dsdp.eclipse.org - fix website links still pointing to the DSDP charter
Here's one more action for Webmaster: - In the portal, I currently cannot add bugzilla milestones. I only have admin privileges for "dsdp.tm" but that project is closed for new bugs. Looks like I'll need bugzilla admin prvileges for "tools.tm".
Ok, you should be all set now. -M.
Looks good. Except when I "Edit bugzilla components, targets,..." from the Portal here: https://dev.eclipse.org/committers/bugs/edit_bugzilla_project.php there is a big note saying NOTE: This project has been closed to new bugs but I guess that's just cosmetic since I couldn't see any degradation.
D'oh. Looks like the bugzilla update a while ago changed a table row name. Fixed. -M.
I think that the TM move has pretty much completed successfully, so I'd like to eventually close this bug. I've looked through the comments about still outstanding work to do and here's what I found: - Fix TM Website links pointing to DSDP charter. I will fix this in the context of this bug. - Physically remove files under /shared/dsdp/tm Webmaster, is anything speaking against this? Are those files in a backup, just in case we find after the fact that we went too far? Going once... going twice... - Migrate or retire the dsdp.eclipse.org vserver. I filed bug 338635 for tracking this separately. - Why are all Wind River committers still listed twice? Comment 63. That should be it... starting to see the light at the end of the tunnel :)
(In reply to comment #68) > - Why are all Wind River committers still listed twice? > Comment 63. Because our database has them connected to more than one organization. In this case, the duplicates are connected to both Intel and WindRiver. Sharon, is this right? (Martin Oberhuber and Michael Scharf are two examples) I have opened Bug 338724 to address. I believe I have a fix already that I will commit momentarily.
(In reply to comment #68) > - Physically remove files under /shared/dsdp/tm > Webmaster, is anything speaking against this? Are those files in a backup, > just in case we find after the fact that we went too far? > Going once... going twice... We keep a 24h rolling snapshot of the /shared data, so once we remove the directory it'll disappear from the backup. (In reply to comment #69) > (In reply to comment #68) > > Sharon, is this right? (Martin Oberhuber and Michael Scharf are two examples) > I've talked to Sharon and Don and this seems to be correct. I think the fix your proposing should be just the thing. -M.
(In reply to comment #68) > - Why are all Wind River committers still listed twice? > Comment 63. This is fixed.
I believe that Bug 338635 is a blocker and have added it as such. Correct me if I'm wrong.
(In reply to comment #68) I have finally replaced all references to the DSDP charter by references to the Tools charter on the TM homepage. With this, I believe we can finally mark this as done. I'm using an M6 target milestone since that was when bulk of the work was done (except for the small charter fix on the homepage).
