accumulo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Josh Elser <josh.el...@gmail.com>
Subject Re: Ease of making release candidates (was: Javadocs in binary "release")
Date Thu, 21 May 2015 02:44:19 GMT


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.

Mime
View raw message