Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [omr-dev] OMR web site

+ 1 to Robert's position.
 
I don't recall ever wanting to download another project's website when checking out their code.  Websites often come with binary artifacts that can bloat the repo.  By keeping the website in the gh-pages branch, it's easy to not clone that branch.
 
Is it possible to have the eclipse.org omr page redirect to the github.io page?  It seems like it would be easier to keep the website up to date if it could be handled completely in the gh-pages branch....
 
--Dan
 
----- Original message -----
From: Robert <rwy0717@xxxxxxxxx>
Sent by: omr-dev-bounces@xxxxxxxxxxx
To: omr developer discussions <omr-dev@xxxxxxxxxxx>
Cc:
Subject: Re: [omr-dev] OMR web site
Date: Tue, Aug 16, 2016 1:07 PM
 
"Mark Stoodley" <mstoodle@xxxxxxxxxx> writes:
> I see a couple of main options here:
>
> 1) put all the web site materials, including documentation, into a directory
> (website?) in our master branch
> - do not use gh-pages branch
>
> 2) put everything into the gh-pages branch
> - github.io site renders our documentation
> - main web site rendered at Eclipse, linking to our github.io site for docs
>
> My vote is for #1 because we will then get a versioned web site automatically
> (when we ship a release, the documentation and web site will be automatically
> versioned along with the code) and we can more easily maintain documentation
> updates at the same time as code checkins in the same pull requests.
>

I have concerns with how #1 will work when/if OMR begins versioned
releases. Each release would have a completely unique website. I believe
we will want one website that supports and documents multiple releases
of OMR simultaneously.

I agree that as much as possible, documentation should be versioned with
the code. However, I feel there is a component of the OMR website that
should be versioned seperately.

Ultimately, I don't see my concerns being a problem today, or
particularly difficult to address in the future. I support moving
forward with #1.

> #2 would allow us to leverage more of the GitHub infrastructure that other open
> source projects are using. Most of our updates will be to documentation rather
> than the web site, I would expect, but it's still a second location where the
> documentation resides compared to where the code resides. Even if we do #2, we
> still need to have our web site at the www.eclipse.organd maintain it.
>
> I think the benefits in #1 far outweigh what we lose in not doing #2, but maybe
> I haven't imagined all the benefit to #2. Thoughts?
>
> I'll leave this open until Monday August 22 unless the discussion is still
> progressing effectively.
>

- Robert
_______________________________________________
omr-dev mailing list
omr-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/omr-dev

 
 


Back to the top