accumulo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christopher <>
Subject Re: Ease of making release candidates (was: Javadocs in binary "release")
Date Thu, 21 May 2015 02:19:32 GMT
On Wed, May 20, 2015 at 10:08 PM, Christopher <> wrote:
> On Wed, May 20, 2015 at 7:39 PM, Josh Elser <> 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
>>>> > 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.

View raw message