Building a new homepage for Gerrit Code Review

[Shawn Pearce]

I think the code.google.com/p/gerrit page is... boring and uninteresting. We have always wanted to highlight important features of Gerrit Code Review to users but never bothered to write content to get people excited about the project and try it out.

Now that Gitiles can render Markdown as a reasonable looking website I started trying to draft a new "homepage" for the project:

  https://gerrit.googlesource.com/homepage/+doc/HEAD/

To help accelerate authoring content I created a new homepage-authors group with +2 and submit permission, and added a number of active people in the community to it (Dariusz Łuksza, David Ostrovsky, Luca Milanesio). The group is self-managed, I hope it will grow.

With our online editing features it should be possible for anyone to create a change, write Markdown, preview it with the "(gitiles)" link on the change, and its easy to +2 and submit to make the change immediately live.

This homepage is far from complete. We have a lot of content at code.google.com/p/gerrit wiki that could move here. We have a lot of links that could move here. We could better organize the navbar to link to tutorials etc.

Right now I have no concrete plan on how we "transition" the project to use this content as a homepage. The URL of https://gerrit.googlesource.com/homepage/+doc/HEAD/ is not as easy to mention or link to as code.google.com/p/gerrit.

I am looking into registering a suitable domain name. Perhaps we can run up some sort of small redirector to point at https://gerrit.googlesource.com/homepage/+doc/HEAD/.

[Phil Hord]

Once this becomes the project homepage, remember to add a link from code.google.com/p/gerrit (and remove most everything else) so the old site does not continue to show stale info.

--
--
To unsubscribe, email repo-discuss...@googlegroups.com
More info at http://groups.google.com/group/repo-discuss?hl=en

---
You received this message because you are subscribed to the Google Groups "Repo and Gerrit Discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to repo-discuss...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Shawn Pearce]

On Thu, Mar 5, 2015 at 9:31 AM, Phil Hord <phil...@gmail.com> wrote:

Once this becomes the project homepage, remember to add a link from code.google.com/p/gerrit (and remove most everything else) so the old site does not continue to show stale info.

That is a good idea. I think we have a lot to move and organize before that happens.

[Brad Larson]

On Thursday, March 5, 2015 at 11:21:12 AM UTC-6, Shawn Pearce wrote:

I think the code.google.com/p/gerrit page is... boring and uninteresting. We have always wanted to highlight important features of Gerrit Code Review to users but never bothered to write content to get people excited about the project and try it out.

Great idea.  I would suggest maybe bragging about how users can self-manager their SSH keys / authentications. That has been one of the biggest surprises to new admins I've introduced to Gerrit - "Where is the text file of all the ssh keys I have to append to when new users email me their key?"  "Wait - they don't have to email me keys anymore??"

[Luca Milanesio]

Well done Shawn :-)

Are we able to apply custom CSS as well on the Markdown rendering done by Gitiles?

Luca.

[Shawn Pearce]

On Thu, Mar 5, 2015 at 10:26 AM, Luca Milanesio <luca.mi...@gmail.com> wrote:

Are we able to apply custom CSS as well on the Markdown rendering done by Gitiles?

Unfortunately no. Safe CSS is a difficult concept because you can use CSS to move elements around on the page, make things invisible, put things over other things, etc. So we have to stick with the markdown translation and CSS supported out of the box by Gitiles.

[Shawn Pearce]

Serving from Gitiles Markdown is just a suggestion. Its already there and working.

If we really want to have full control over the raw HTML and CSS then we need another location to serve content from. We could put rendered HTML onto a Google Storage for Developers bucket like we do for the release downloads, but getting from a code reviewed source doc set to there requires some sort of automation build process thing. Which is more work.

I am open to other suggestions.

FWIW, this morning I reserved gerritcodereview.com for a project homepage. Its currently unconnected to anything. We need to figure out what we are serving and from where, and then I can start pointing the domain records at that.

[Luca Milanesio]

I actually think that serving Markdown is a brilliant idea as allows to review & publish as a unique workflow :-)

I wouldn’t go to a second phase of publishing HTML / CSS … that is always risking to put the “extra element” that can simply fail :-(

My question was more on Gitiles if it allows an alternative Markdown/CSS for rendering a set of pages, but I mean one of the CSS that is designed to render a Markdown and nothing else fancy or exotic.

But for the time being, it is good enough to get started and then we can even make it better and nicer.

Luca.

[Mark Derricutt]

On 6 Mar 2015, at 10:53, Luca Milanesio wrote:

> I actually think that serving Markdown is a brilliant idea as allows to review & publish as a unique workflow :-)
> I wouldn’t go to a second phase of publishing HTML / CSS … that is always risking to put the “extra element” that can simply fail :-(

On a tangent question - wasn't there an idea/plan/thought to support Markdown in review comments/commit messages etc. some time ago?


--
Mark Derricutt
http://www.theoryinpractice.net
http://www.chaliceofblood.net
http://plus.google.com/+MarkDerricutt
http://twitter.com/talios
http://facebook.com/mderricutt

[Doug Kelly]

Crazy idea(s): use the replication plugin to push the homepage repo to (server?)... One half-baked idea I had was something like this:

RewriteEngine on
RewriteRule ^/(.)static/(.*) http://127.0.0.1:8080/$1static/$2 [P]
ProxyPassReverse /+static http://127.0.0.1:8080/+static
RewriteRule ^/gerrit(.*) http://127.0.0.1:8080/homepage/+doc/HEAD$1 [P]
ProxyPassReverse /gerrit http://127.0.0.1:8080/homepage/+doc/HEAD

This has some quirks, though... notably, a number of links will break (including the link back to the index).  The other possibility would be writing a much simpler servlet with pegdown that uses the same doc stylesheet (or any custom stylesheet we want, for that matter), since then we don't have to worry about the repo browsing features of gitiles.  Of course, if you wanted, you could still link to the Gitiles repo.

Just some ideas I was toying with...

--Doug

[lucamilanesio]

After yesterday's announcement [1] I guess we need to find another hosting for Issues as well.

What about redmine or bugzilla?

[1] http://google-opensource.blogspot.co.uk/2015/03/farewell-to-google-code.html

[Doug Kelly]

On Friday, March 13, 2015 at 3:00:22 AM UTC-5, lucamilanesio wrote:

After yesterday's announcement [1] I guess we need to find another hosting for Issues as well.

What about redmine or bugzilla?

[1] http://google-opensource.blogspot.co.uk/2015/03/farewell-to-google-code.html

Even using JIRA/Confluence is free for established open-source projects.  It would also be worth noting that github.io's hosting supports automatic generation from Markdown -- we may have to change it slightly to fit their syntax/layouts, but that seems pretty minor to me. Could probably even do read-only mirroring of the projects on Github, but the pain there would be reminding people they need a CLA on file and how to submit to Gerrit. 

[Luca Milanesio]

Hi Doug,

see my feedback below.

On 13 Mar 2015, at 13:04, Doug Kelly <doug...@gmail.com> wrote:

On Friday, March 13, 2015 at 3:00:22 AM UTC-5, lucamilanesio wrote:

After yesterday's announcement [1] I guess we need to find another hosting for Issues as well.

What about redmine or bugzilla?

[1] http://google-opensource.blogspot.co.uk/2015/03/farewell-to-google-code.html

Even using JIRA/Confluence is free for established open-source projects.

Jira and Confluence are historically slow and unstable … when you access a Jira issue of any Apache project you wait loooong looooong seconds :-(

I would like something faster and more opened to integrations, that’s why I proposed BugZilla as we already have plugins for it :-)

(we have the Jira one as well but I would be more keen to stay on the OpenSource front)

 It would also be worth noting that github.io's hosting supports automatic generation from Markdown -- we may have to change it slightly to fit their syntax/layouts, but that seems pretty minor to me. Could probably even do read-only mirroring of the projects on Github

So basically managing all the code-reviews in Gerrit and using GitHub just as read-only publish mirror?

Are you talking about the GerritHub.io use-case then ?

See https://www.youtube.com/watch?v=jeWTvDad6VM :o)

, but the pain there would be reminding people they need a CLA on file and how to submit to Gerrit. 

That is not a bit problem: I was planning to extend the GitHub plugin to include that part + automatic submission of Gerrit changes from GitHub Pull Requests.

However, I still think that just choosing an alternative issue-tracker would be good enough for us.

(please, NO-slow-jira :-) )

Luca.

[Doug Kelly]

On Friday, March 13, 2015 at 8:34:31 AM UTC-5, lucamilanesio wrote:

Hi Doug,

see my feedback below.

On 13 Mar 2015, at 13:04, Doug Kelly <doug...@gmail.com> wrote:

On Friday, March 13, 2015 at 3:00:22 AM UTC-5, lucamilanesio wrote:

After yesterday's announcement [1] I guess we need to find another hosting for Issues as well.

What about redmine or bugzilla?

[1] http://google-opensource.blogspot.co.uk/2015/03/farewell-to-google-code.html

Even using JIRA/Confluence is free for established open-source projects.

Jira and Confluence are historically slow and unstable … when you access a Jira issue of any Apache project you wait loooong looooong seconds :-(

I would like something faster and more opened to integrations, that’s why I proposed BugZilla as we already have plugins for it :-)

(we have the Jira one as well but I would be more keen to stay on the OpenSource front)

I agree.  JIRA is ... a hog, to say the least.  You pay for the eye candy.  Similarly, Bugzilla isn't much to look at out of the box, but it's stable and does the job well.  My one negative experience with Bugzilla was that it's somewhat obtuse to set up and configure -- the workflow was always clunky to me.  But I'll admit, I've not used it a whole lot. 

 It would also be worth noting that github.io's hosting supports automatic generation from Markdown -- we may have to change it slightly to fit their syntax/layouts, but that seems pretty minor to me. Could probably even do read-only mirroring of the projects on Github

So basically managing all the code-reviews in Gerrit and using GitHub just as read-only publish mirror?

Are you talking about the GerritHub.io use-case then ?

See https://www.youtube.com/watch?v=jeWTvDad6VM :o)

Hmm, maybe I was? ;) I was actually thinking about your GerritHub integration, which would certainly be nice, but even pure replication would be enough (also, there's the question if we ran the full GerritHub plugin set of how the auth plugins would cooperate with Google accounts).  Plus, Github does have their issue tracker built in, and it has a migration path from Google Code, as I recall?

, but the pain there would be reminding people they need a CLA on file and how to submit to Gerrit. 

That is not a bit problem: I was planning to extend the GitHub plugin to include that part + automatic submission of Gerrit changes from GitHub Pull Requests.

However, I still think that just choosing an alternative issue-tracker would be good enough for us.

(please, NO-slow-jira :-) )

Interesting.  Would be pretty cool!  I'm not going to force JIRA on anyone (as if I had any power in the project to begin with); I just happen to be comfortable with it is all.  I think we can make a lot of things work, though.

[Luca Milanesio]

With regards to BugZilla (should we choose to go for it), we could host in on GerritForge and point it from the new Gerrit Code Review home page.

Having our custom instance would allow us to synchronise the workflow between the tickets and reviews, which is quite nice :-)

Luca.