Bugzilla – Full Text Bug Listing
| Summary: | Migrate EF-maintained websites on www to Git | ||
|---|---|---|---|
| Product: | Community | Reporter: | Wayne Beaton <wayne.beaton> |
| Component: | Website | Assignee: | phoenix.ui <phoenix.ui-inbox> |
| Status: | RESOLVED FIXED | QA Contact: | |
| Severity: | normal | ||
| Priority: | P3 | CC: | alex.panchenko, contact, david_williams, ed, jesse.mcconnell, overholt, pwebster, sbouchet, webmaster |
| Version: | unspecified | ||
| Target Milestone: | --- | ||
| Hardware: | PC | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Bug Depends on: | 341037, 359738, 359747, 359748, 359749, 359757, 359758, 359764, 375211, 382758, 382759, 387643, 389205, 389206, 389207, 389208, 389209, 389210, 389211, 389768, 389769, 389771, 389772, 389779, 389780, 389895, 390033, 390258, 390259, 390265, 390270, 390272, 390276, 390277 | ||
| Bug Blocks: | 324116 | ||
|
Description
Wayne Beaton
> Note that none of these subsites are aligned with an Eclipse project.
> I'll open a separate blocking bug for each of them.
While not directly related to this ... I don't think ... what is the strategy for moving project websites to Git? It should be easier for a project to move website to Git (as far as I know) that code, since no one (that I know of) "build" it, maintain branches, etc. But, some might have scripts that refer read from it or (semi-automatically) "feed" it; I'm not sure (I am not aware of any). But, might get some (few) committers used to using Git on their websites, before messing with their code repos. Seems it would not have to be done at same time as project's code ... but perhaps that's the assumption?
Just wondering.
(In reply to comment #1) > > Note that none of these subsites are aligned with an Eclipse project. > > I'll open a separate blocking bug for each of them. > > While not directly related to this ... I don't think ... what is the strategy > for moving project websites to Git? It should be easier for a project to move > website to Git (as far as I know) that code, since no one (that I know of) > "build" it, maintain branches, etc. But, some might have scripts that refer > read from it or (semi-automatically) "feed" it; I'm not sure (I am not aware of > any). But, might get some (few) committers used to using Git on their websites, > before messing with their code repos. Seems it would not have to be done at > same time as project's code ... but perhaps that's the assumption? > > Just wondering. We've already done some experimenting with this (Bug 324116). Our larger evil plan is to use our own migration as the starting point of a larger migration of project websites to Git. Our hope is to get as many of the EF-maintained sites over to Git as possible before the end of 2011 and then use the lessons learned to start encouraging other projects to move. My hope is that projects will move their websites either before or shortly after the Juno release. There are some questions that I think we need to answer before we can move ahead. Where do we put these repositories? Do they go alongside project code repositories, or do we make a special location for them? I'm in favour of putting them in a separate location to keep them distinct from code repositories (for one, it will allow us to automatically filter out website repositories when setting up GitHub clones, and running Dash queries). What will be the structure of the repositories? One repo/root directory? e.g. for Bug 359758, do we create a repository named "committers.git" and map the checkout of it to "/committers"? FWIW, I'm ready to move ahead with /committers (Bug 359758), /articles (Bug 359738). These are both pretty low activity; once we have them up and running, I can move ahead with /projects (I don't think I've created a bug for this yet). > Where do we put these repositories? Do they go alongside project code
> repositories, or do we make a special location for them?
They _were_ alongside the code before Phoenix. Since we were publishing the pages to a centralized location, we decided to create a dedicated repo for the website.
If we decide to store the repo with the project code, we'd likely need a good naming convention and a repo->directory mapping to make sure the right repos are published in the correct locations.
My vote was to create a container (like /gitroot/www.eclipse.org) and have each repository inside correspond to one top-level directory name (committers.git, articles.git, etc.)
My preference would be to have it sitting alongside our other repositories org.eclipse.jetty.website.git but i am open if you want to have a distinct project for this under the jetty project in our git repo would restrict users to just normal jetty committers which is fine I'd vote in favour of having the website repos alongside the code (preferably in one repo) but if that makes things difficult from an administration standpoint, I have no preference. Based on "overwhelming" feedback, I guess keeping these alongside project directories is what we should do. My preference is to use some kind of naming strategy to figure out what goes where (though I'm willing to defer to better judgement). I'm concerned that trying to maintain this information in a file or database introduces an opportunity to for things to get out of synch (and it's just one more thing that we have to think about). There is some variability in terms of where project websites sit in the www hierarchy. e.g. rt.gemini.naming => http://eclipse.org/gemini/naming/ technology.egit => http://eclipse.org/egit How does this bode for naming conventions? If we replace the slashes with underscores, maybe something like: e.g. website-gemini_naming.git => http://eclipse.org/gemini/naming/ website-egit.git => http://eclipse.org/egit Do we have any "root" directories with underscores in their name? How worried are we about projects erroneously creating extraneous "website" directories? I'm not particularly worried. Maybe we should just maintain a file with the mapping. Webmaster team would have to make sure it's up-to-date. Thoughts? I guess I don't understand the concrete benefit of having a web repo alongside a code repo. From Eclipse's point of view, it's still 2 separate projects. From the admin point of view, we're already discussing mappings via files or meta-data, the dangers of having content published to www.eclipse.org when it shouldn't be and the fact that data may be out of sync. Having one /gitroot/www.eclipse.org container removes all this ambiguity -- one git repo per top-level directory on www.eclipse.org makes it really easy for us to script deployment to the website. I'm not opposed to having the website along the code. But it sounds like a recipe for headaches and increased need for support with little to no benefit for committers. Actually, since I'm the one who will have to deploy and maintain this system, I'll put my big-boy hat on and forcibly decide that one container for all the www.eclipse.org content is the only way to do this right. I'll still let you folks decide what the container's name will be... I suggest /gitroot/www.eclipse.org but otherwise I don't care :) (In reply to comment #9) > Actually, since I'm the one who will have to deploy and maintain this system, > I'll put my big-boy hat on and forcibly decide that one container for all the > www.eclipse.org content is the only way to do this right. I put "overwhelming" in quotes for a reason. +1 > I'll still let you folks decide what the container's name will be... I > suggest /gitroot/www.eclipse.org but otherwise I don't care :) +1 So you really want all content or all project for the website in one git repository? I have been planning on publishing docbook generated output to our website as part of a nightly process and I really didn't want to have to bother much with making sure my git repo was all merged up every time someone decides to tweak a comma on their page...nor do I really relish having to clone the _entire_ website when I want to make a change... I don't see what the big deal is with multiple git repositories for this, it seems far more natural and gitish then one big uber git repository for the whole website. Great. I created /gitroot/www.eclipse.org My other recommendation is that each repo (which corresponds to a top-level directory on www) be named top-level-name.git. Again, this will help us maintain a natural mapping of repo_name -> www.eclipse.org/path I've already created /gitroot/www.eclipse.org/articles.git for /articles. Wayne, have at it if you want, or I can do the import for you. > So you really want all content or all project for the website in one git > repository? One git repo per top-level directory on www. Essentually, each of these directories in the current CVS repo would become its own Git repo: http://dev.eclipse.org/viewcvs/viewvc.cgi/www/?root=Eclipse_Website (In reply to comment #13) > > So you really want all content or all project for the website in one git > > repository? > > One git repo per top-level directory on www. > > Essentually, each of these directories in the current CVS repo would become its > own Git repo: > > http://dev.eclipse.org/viewcvs/viewvc.cgi/www/?root=Eclipse_Website Ok, as long as jetty gets it own git repo I am happy :) What is the status of this work? Are we close to being able to manage our websites with git? I now have git repositories /articles and /resources. I'm prepared to do all future work on those sites from these git repositories. I've asked a "now what" question on Bug 359738. I think we're done here. Please reopen if I'm wrong. -M. |