Re: [omr-dev] OMR web site

["Dorra Bouchiha" <dorrab@xxxxxxxxxx>]

The size of the website directory is 3.2M

The images sub directories are ~1M and the fonts dirs are ~1.2M

Regards,

Dorra Bouchiha, Ph.D.
OMR Project Manager
IBM Runtime Technologies
Eclipse OMR on github.com

Phone: 1-905-413-4475 | Mobile: 1-416-702-7440 E-mail: dorrab@xxxxxxxxxx Chat: dorrab Find me on: and within IBM on:	8200 Warden Ave Markham, ON L6G 1C7 Canada

Mark Stoodley---08/16/2016 07:04:27 PM---> I don't recall ever wanting to download another project's website when checking out their code.  W

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

---

> 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? Dorra or 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

Daniel Heidinga---2016/08/16 01:49:27 PM---+ 1 to Robert's position.

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