Mailing-List: contact dev-help@accumulo.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@accumulo.apache.org
Message-ID: <555D4683.4020105@gmail.com>
Date: Wed, 20 May 2015 22:44:19 -0400
From: Josh Elser <josh.elser@gmail.com>
User-Agent: Postbox 3.0.11 (Macintosh/20140602)
MIME-Version: 1.0
To: dev@accumulo.apache.org
Subject: Re: Ease of making release candidates (was: Javadocs in binary
 "release")
References: <555CBD0F.9000907@gmail.com>
 <CAL5zq9beK0p6KC+rjy74UgznOa_j1Ts7tHy1TMgTu7kMYny7Hw@mail.gmail.com>
 <555CD535.80007@gmail.com>
 <CAL5zq9bRz29nUv1qHLj_Q2EkKmK+_LfCjcTqODkMC9k9rhZFYQ@mail.gmail.com>
 <555D1B1D.9020904@gmail.com>
 <CAL5zq9ZzbkgQbTUorGMMy6f_eiAvh3JWGii+2EjpMGK71Eza3A@mail.gmail.com>
 <CAL5zq9aicbd=sO-FQSarOqnsQWHBQYY+dfOMjWXXdfVaWsqBgw@mail.gmail.com>
In-Reply-To: 
 <CAL5zq9aicbd=sO-FQSarOqnsQWHBQYY+dfOMjWXXdfVaWsqBgw@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit


Christopher wrote:
> On Wed, May 20, 2015 at 10:08 PM, Christopher<ctubbsii@apache.org>  wrote:
>> On Wed, May 20, 2015 at 7:39 PM, Josh Elser<josh.elser@gmail.com>  wrote:
>>> Christopher wrote:
>>>>> The other half of me wanting to fork off this convo is that there's also
>>>>>>   more to making a release than just making the release candidate. I
>>>>>> probably
>>>>>>   had 30+ commits to CMS over the past week (granted some of which were
>>>>>> me
>>>>>>   just editing content on CMS), but we have a lot of steps which are now
>>>>>> just
>>>>>>   copying files from the release, committing to the site repo. I'd love
>>>>>> to see
>>>>>>   more done for automation here that can reduce the pain for the post-RC
>>>>>> work.
>>>> [snip]
>>>>
>>>> +0.5 to that. I'm willing to help a bit here, but it's a bit daunting,
>>>> and it's not even clear to me where we can automate, especially with
>>>> CMS being involved as a middle-man.
>>>>
>>> Yeah, I have _no idea_ what this kind of automation would look like. Trying
>>> to keep it somewhat decoupled from CMS itself would be good (as it may go
>>> away in the future -- or at least look different). It was just a pain point
>>> that I noticed. I went back and forth picking files from the source release,
>>> putting them in CMS, verifying they rendered right, etc.
>> One thing you could have done is update all the files before clicking
>> "commit". CMS is basically a web interface for a local SVN checkout.
>> You can update many files in this local SVN checkout, examining each
>> preview render, before ultimately clicking "Commit" which initiates a
>> final rendering to the staging site. You definitely don't have to
>> commit one file at a time.
>
> Incidentally, one of the reasons I hate CMS is that I have no option
> to do a full local render to test the CSS, links, markdown rendering,
> etc.. There also isn't an option to publish some changes, but not
> others. It's either publish what's on "staging" or not. There's no
> half-way. So, if somebody fixed a link while we were staging changes
> for a release, they wouldn't be able to publish that fix without also
> including the other staged changes.

You can run the CMS locally to see changes. I did this in the past with 
success when we switched to the bootstrap-backed version of the site. 
The only problem is that all of our paths are relative so you have to 
host it at the root of a vhost.