Re: [omr-dev] OMR web site

["Mark Stoodley" <mstoodle@xxxxxxxxxx>]

Come to think of it, I guess we already
have a separate repository, if we want to go that route: the repository
at eclipse.org itself. Let's call that Option 3.

I'm not a big fan of this approach because
it separates our source code (and across sites, even). Also, as I said
below, I like having all our source code in one place on equal footing.

Mark Stoodley		8200 Warden Avenue
Senior Software Developer		Markham, L6G 1C7
IBM Runtime Technologies		Canada
Phone:	+1-905-413-5831
e-mail:	mstoodle@xxxxxxxxxx
We cannot solve our problems with the same thinking we used when we created them - Albert Einstein

From:      
 Mark Stoodley/Toronto/IBM@IBMCA
To:      
 omr developer discussions
<omr-dev@xxxxxxxxxxx>
Date:      
 2016/08/16 07:04 PM
Subject:    
   Re: [omr-dev]
OMR web site
Sent by:    
   omr-dev-bounces@xxxxxxxxxxx

---

> 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.

You may not want to download it, but if it's a branch in the repository
then it will be downloaded when you clone anyway. It just won't show up
in your directory structure if you don't checkout that branch. The only
way to avoid downloading it would be for it to have its own repository,
which would be a third option I suppose, but I'm not sure it's warranted.
Note that web site updates are likely to be more rare than source code
updates, so I would hope that fetch times won't be affected much.

IMO the web site is just as much a part of this project as the source code
is, so it shouldn't be relegated to some secondary location just for that
reason.

But you're right, there are images and other binary things that will add
to the size of the repository and increase clone time which affects commit
testing etc. Any ideas for how we might get those things off our repo download
size but still be accessible when people want to change them? Dorraor someone more familiar with the web site: how much additional download
size are we talking about in binary files?


> 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....

The web site should have a home location, and Eclipse (reasonably, I think)
requires us to host that at the Eclipse web site.



Are there any other options I've missed? I will also solicit input from
the Eclipse incubators list, as Mike suggested (thanks, Mike!) and will
summarize their recommendations here, for those that aren't on that mailing
list.

Mark Stoodley		8200 Warden Avenue
Senior Software Developer		Markham, L6G 1C7
IBM Runtime Technologies		Canada
Phone:	+1-905-413-5831
e-mail:	mstoodle@xxxxxxxxxx
We cannot solve our problems with the same thinking we used when we created them - Albert Einstein

From:        Daniel
Heidinga/Ottawa/IBM@IBMCA
To:        omr-dev@xxxxxxxxxxx
Date:        2016/08/16
01:49 PM
Subject:        Re:
[omr-dev] OMR web site
Sent by:        omr-dev-bounces@xxxxxxxxxxx

---

+ 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.organdmaintain
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

 
_______________________________________________
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


_______________________________________________
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