Community
Participate
Working Groups
I think it would be a good thing to migrate the www.eclipse.org CVS repository to Git. A quality team provider is an obvious pre-requisite.
*** Bug 326588 has been marked as a duplicate of this bug. ***
From bug 293192 comment 10: (In reply to comment #9) > > Since EGit 0.9.3 is out now, are we "adequate" enough? > > > > Can we at least start transitioning some pieces like the website infrastructure > > at Eclipse to Git? There is also a resourcing issue. Denis, do you have any sense for what kind of effort this will take to change over? I think moving www.eclipse.org over to git will be trivial if we only keep one big repo. If we split it into one repo per project that could be tedious. The other thing we'll need to do is hack the checkout mechanism so that new commits/pushed content gets published to www as quickly as possible. The first step would be (for us) to add the org.eclipse/www CVS repo into the Git mirror on dev.eclipse.org. I agree that moving the website repo would be a great way to get us all using EGit.
One big repo means that everybody who does work on any part of the website has to have every part of the website (in their local clone of the repo). My workspace, which has only a portion of the website, is huge. I think that we may need to be more selective.
How are permissions configured in one single repo? I thought that commit permissions apply to a whole repo but not to a subset of the repo tree.
> How are permissions configured in one single repo? I thought that commit > permissions apply to a whole repo but not to a subset of the repo tree. Gah, you're right, I was forgetting that -- each project has their own space. I guess we could create one repo for the EMO stuff, and one repo per project?
We need to start prepping the committer community for this eventuality. All committers who maintain a project website at eclipse.org have to monitor this bug. I'll include a reference to it in my next note to the committers. In the meantime, we should start blogging/tweeting/communicating this. I don't think that we're quite ready to specify a timeframe. Denis, given that we're probably going to have to make multiple Git repos to make this work, how likely is it that we can do this piecemeal? (i.e. migrate projects in groups). I'm thinking hard/unlikely. Is there anything else that we need to be thinking about to "Do this right"?
> I don't think that we're quite ready to specify a timeframe. I think we need to set a timeframe. Otherwise, it will never be done (see: deprecate CVS) If we are in agreement that the team provider is adequate, I can start a proof of concept sandbox repo so that we can all play around in. > Denis, given that we're probably going to have to make multiple Git repos to > make this work, how likely is it that we can do this piecemeal? (i.e. migrate > projects in groups). I'm thinking hard/unlikely. The current group ownership for each top-level directory of www clearly defines what belongs together in one repo. I can easily see how scripting an import routing is feasible. I'll get to work on a preliminary import.
Very cool guys. +1 from me. If you want to use the cdt space as an early customer, I'd be happy to volunteer.
Created attachment 179990 [details] Import Script Here's a script which will import each website top-level directory into its own Git repo, setting correct permissions as it goes along. You can start seeing some appear on the CGit page: http://git.eclipse.org/c/ That page will become cluttered -- we're tracking that in bug 320443
There's a few project website repos up there -- they all begin with www.eclipse.orgTEST. CDT is one of them. http://git.eclipse.org/ They should be fully pushable by the appropriate groups. Those repos are all just temporary -- I'll delete them before the actual move, and the commits are not published to www.eclipse.org.
Is this migration being done by the Eclipse Foundation or is it up to each project to migrate their web site content?
> Is this migration being done by the Eclipse Foundation or is it up to each > project to migrate their web site content? My guess if that the EMO will do this.
Hey cool, this means we can fork the entire Eclipse website!
Can we set a date for this? The date, IMHO, should be well in advance of the suggested December 21/2012 CVS retirement date. Is this something we can stage? Can we, for example, put the pieces in place to let a handful of projects do the migration voluntarily before the end of 2011?
> Can we set a date for this? Sure. > Is this something we can stage? I tried that almost exactly one year ago, and I received zero feedback. Please advise on how to better proceed.
(In reply to comment #15) > > Can we set a date for this? > > Sure. > > > > Is this something we can stage? > > I tried that almost exactly one year ago, and I received zero feedback. Please > advise on how to better proceed. Correct me if I'm wrong, but we only go as far as creating copies of the repository to encourage experimentation: we didn't do the next step of actually driving website content from the Git repository. How about we set a date to start moving the EF stuff? I can commit some cycles to moving over the Project management code, for example.
(In reply to comment #16) > (In reply to comment #15) > > > Can we set a date for this? +1 for this Also I think I've figured out the git checkout command, i got it running on the EconTest box. Can we use phoenix.eclipse.org as our 'git' version of the site?
You've probably gotten past this step, but just posting this link in case it helps.. http://philsturgeon.co.uk/news/2010/02/Deploying-websites-with-Git
Denis, Where are we on this? I would really like to move jetty's website over to use git asap, we want to leverage it for some documentation reworking we are doing.
> Where are we on this? Looks like I have two blockers: - bug 293192 Quality team provider and tooling for Git. Do committers feel that we're there? Can I close the bug as FIXED? - bug 359737 Migrate EF-maintained websites on www to Git. I'm waiting for an answer from Wayne.
ok, I poked on those issues would be great to get this morning and kiss off cvs once and for all :)
(In reply to comment #21) > ok, I poked on those issues > > would be great to get this morning and kiss off cvs once and for all :) Did you mean "moving" or "mourning"?
definite 'moving' :)
It would be helpful to establish a clear hierarchical policy. For instance each of www/atl www/m2m/atl www/modeling/m2m/atl exists. Which are correct? Which are incorrect?
(In reply to comment #24) > It would be helpful to establish a clear hierarchical policy. > > For instance each of > > www/atl > www/m2m/atl > www/modeling/m2m/atl > > exists. Which are correct? Which are incorrect? It depends on who you're asking. Officially, we prefer www/atl because it is the most resilient URL in the face of things like project moves and "container" project renames. We prefer to keep everything as flat as possible because it keeps the workload down and reduces the opportunity for surprises when things move around. But the Modeling PMC tends to like things nested hierarchically. You may want to check with them.
Where are we at with this issue? Can I get a status update? I am trying to sort out some timing for how we plan to deploy our new docbook documentation so we can migrate off of the bothersome wiki setup.
In case this needs saying... Please wait until after Juno so that we aren't fighting this while trying to update website for Juno release.
ok, juno is out... how about now? any status update on this?
Right now we're working on (amongst other things) bug 382758.
ok, thanks denis
I believe that we are ready to migrate project-specific websites to Git. At this point, we're looking for victims^H^H^H^H^H^Hvolunteers. Project leads can open a blocker bug on this to request migration of their project website.
I'll toss on that it was a painless transition for jetty :)
Um, our existing web site seems to be gone: http://www.eclipse.org/eclipse/ Do we have to migrate now to get it back? :)
(In reply to comment #33) > Um, our existing web site seems to be gone: > > http://www.eclipse.org/eclipse/ > > Do we have to migrate now to get it back? :) That would help :-) Migrating the eclipse.org-common directory in combination with some regular expression trouble caused this. Matt is working on it now.
Orion volunteers to migrate. Opened bug 387820.
(In reply to comment #34) > Migrating the eclipse.org-common directory in combination with some regular > expression trouble caused this. Matt is working on it now. The checkout script has been updated, and I've forced a checkout from cvs to restore /eclipse. -M.
Shameless plug: once your project migrates, you can edit your project web site entirely from your browser with orionhub.org. Orion has a decent HTML editor with syntax highlighting, validation, outline, content assist, etc. If you click "Get Plugins" at the top you can install the Code Mirror plugin which does syntax highlighting of PHP files as well. The Orion Git tools let you push/pull between your Orion workspace and git.eclipse.org.
(In reply to comment #37) > Shameless plug: once your project migrates, you can edit your project web > site entirely from your browser with orionhub.org. I would love to do this. Are the workflows documented anywhere? Do I have to use orionhub, or could I use a localhost install of Orion?
(In reply to comment #38) > (In reply to comment #37) > > Shameless plug: once your project migrates, you can edit your project web > > site entirely from your browser with orionhub.org. > > I would love to do this. Are the workflows documented anywhere? > > Do I have to use orionhub, or could I use a localhost install of Orion? +1 sign me up to use Orion for the web site work I do. Some documentation about be nice. :-)
(In reply to comment #37) > Shameless plug: once your project migrates, you can edit your project web > site entirely from your browser with orionhub.org. Orion has a decent HTML > editor with syntax highlighting, validation, outline, content assist, etc. > If you click "Get Plugins" at the top you can install the Code Mirror plugin > which does syntax highlighting of PHP files as well. The Orion Git tools let > you push/pull between your Orion workspace and git.eclipse.org. Testing PHP doesn't work. I guess that you need actual PHP support for that :-) I'm thinking that setting up an Orion instance on a server that does support PHP would be extremely useful... Or is there some way that we can leverage orionhub for this?
Most of the pages I edit have trivial PHP and I just test by pushing my changes, refresh the page, repeat if needed (same workflow as I had in Eclipse desktop). I'll try writing up a wiki page with more detailed instructions. Workflow would be the same with a localhost Orion server. Enabling PHP on orionhub is also a possibility. That would allow people to deploy to a test site within orion, although often with PHP you are going to have other server side requirements such as databases, etc.
(In reply to comment #41) > Enabling PHP on orionhub is also a possibility. That would allow people to > deploy to a test site within orion, although often with PHP you are going to > have other server side requirements such as databases, etc. Security is another concern. Anybody can write code on OrionHub. Letting everybody run arbitrary PHP scares me a bit...
(In reply to comment #42) > (In reply to comment #41) > > > Enabling PHP on orionhub is also a possibility. That would allow people to > > deploy to a test site within orion, although often with PHP you are going to > > have other server side requirements such as databases, etc. > > Security is another concern. Anybody can write code on OrionHub. Letting > everybody run arbitrary PHP scares me a bit... Wouldn't it make more sense to setup a test server for eclipse.org and we do the testing there, not at OrionHub? OrionHub isn't going to be able to deploy every single runtime environment for all the users, so I think we should set ourselves up as a standard use case.
(In reply to comment #43) > (In reply to comment #42) > > (In reply to comment #41) > > > > > Enabling PHP on orionhub is also a possibility. That would allow people to > > > deploy to a test site within orion, although often with PHP you are going to > > > have other server side requirements such as databases, etc. > > > > Security is another concern. Anybody can write code on OrionHub. Letting > > everybody run arbitrary PHP scares me a bit... > > Wouldn't it make more sense to setup a test server for eclipse.org and we do > the testing there, not at OrionHub? OrionHub isn't going to be able to > deploy every single runtime environment for all the users, so I think we > should set ourselves up as a standard use case. I've opened Bug 387922. Let's take this discussion there.
I've moved the downloads area.
Great, how can individual projects move? And what about Orbit? Sorry if there may be one of those Dozens or more related bugs, but I saw, Orbit guidelines mention uploading artefacts to the CVS repo so far. Thanks
(In reply to comment #46) > Great, how can individual projects move? http://wiki.eclipse.org/Git/Migrating_to_Git#Migrating_Your_Project_Website > And what about Orbit? Sorry if there may be one of those Dozens or more > related bugs, but I saw, Orbit guidelines mention uploading artefacts to the > CVS repo so far. Orbit has been given a special exception to keep its "source" repository in CVS for now. The website repository will still have to move.
(In reply to comment #38) > (In reply to comment #37) > > Shameless plug: once your project migrates, you can edit your project web > > site entirely from your browser with orionhub.org. > > I would love to do this. Are the workflows documented anywhere? > > Do I have to use orionhub, or could I use a localhost install of Orion? Here is a blog post I wrote with some directions to get started editing your site with OrionHub: http://planetorion.org/news/2012/11/editing-eclipse-org-web-sites-with-orionhub/
This bug was started 3 years ago, and I'd like to see us close it and it's dependent children. I suggest we either force move outstanding projects or simply remove them(with redirects possibly). After 3 years I don't want us to wait another one so I'd like to see something on the 6 months or less scale in terms of time. Comments? -M.
(In reply to Eclipse Webmaster from comment #49) > This bug was started 3 years ago, and I'd like to see us close it and it's > dependent children. > > I suggest we either force move outstanding projects or simply remove > them(with redirects possibly). > > After 3 years I don't want us to wait another one so I'd like to see > something on the 6 months or less scale in terms of time. Projects have had more than enough time to migrate their websites. I have several concerns: 1) If a project has not migrated their website to Git, then they have not been making regular updates to their website. Does this speak to the liveliness of a project? 2) In light of the recent spate of vulnerability reports, I am concerned that these apparently abandoned web directories represent a potential security concern. I'm in favour of setting a March deadline to migrate. After that, we archive the CVS repository and toast every part of the website that is not maintained in Git. Spring cleaning.
It's March and that means cleanup time. All CVS based content has been removed from www.eclipse.org. -M.
