drupal and releases

[Ben Cooksley]

On Fri, Mar 31, 2017 at 10:29 PM, Jonathan Riddell <jr at jriddell.org> wrote:
> My script for it is here
>  https://cgit.kde.org/releaseme.git/tree/plasma/plasma-webpages
> which takes this template and plonks it in svn
>  https://cgit.kde.org/releaseme.git/tree/plasma/templates/plasma_announce_template.php.erb
>
> Now it's not hard to copy and paste it from an editor into Drupal
> which is what I do for the Dot story, see line 54
>  https://cgit.kde.org/releaseme.git/tree/plasma/plasma-release
>
> But it's a bit more faff and a bit more error prone
>
> However it's also easy enough to have kde.org served from Drupal but
> keep kde.org/announcements served from PHP files same as currently
> which I'd prefer.

>From my perspective i'd prefer a full migration away from Capacity,
simply due to it's age bearing in mind the fact that PHP 5 will become
unavailable at some point in the nearish future. The probability of it
breaking in some form or another with PHP 7 is reasonably high i'd
say.

Also note that one would need to maintain two sets of themes as well,
not to mention the additional complexity of the server configuration -
which depending on the path uses two different PHP interpreters - and
Capacity is dependent on having full control over the /media path of a
given host as well, which creates an additional point of conflict with
the CMS.

>
> Jonathan

Regards,
Ben

>
>
>
> On 31 March 2017 at 04:17, Ken Vermette <vermette at gmail.com> wrote:
>> Can you give specific examples of where things are automated, or give a
>> run-down of the current workflow so I know the exact process as it is?
>>
>> Depending on what is done, we have options.
>>
>> The option I like the least would be to have a Drupal module which imports
>> PHP documents and simply acts as a "capacity emulator"; this is likely what
>> will be done for release archives, but it would likely "just work" with new
>> releases. In this case it would likely be easier than anything you do now,
>> as you would only create the announcement page and Drupal would handle
>> linking. However, this is not a good long-term solution as we lose out on
>> search, more robust translation tools, and the fact that it defeats the
>> whole purpose of Drupal.
>>
>> The option I prefer is to have a form in Drupal - probably via a module -
>> which would replace SVN entirely for announcements.
>>
>> We would not need to re-write whole announcements! I'll say that first! We
>> would instead use a module, and build boilerplate content into that module.
>> For some forms, such as KDE Applications announcements, it may be as few as
>> three fields (an optional free-form content area, the version, and release
>> date); from there it would link the announcement appropriately once it's the
>> release date, and we could also provide a preview link. We can add more
>> optional fields as well, such as links if you aren't comfortable
>> auto-generating them. Boilerplate would be automatically translated.
>>
>> Depending on what else / how else you automate, I'll have more answers for
>> things like change logs, which I'm curious to know if there's secret sauce
>> there. I'm in the process of finishing the template, so next is custom
>> modules we'll need, so this is actually a really great time to into your
>> requirements so we can (ideally) avoid disruption and make future admin
>> tasks better/faster/smarter/stronger.
>>
>> Thanks!
>>  - Ken
>>
>> On Mon, Mar 27, 2017 at 5:36 PM, Albert Astals Cid <aacid at kde.org> wrote:
>>>
>>> Riddell, Faure and me, do releases like almost every month (or more).
>>>
>>> How is drupal-based kde.org going to affect our workflow versus the
>>> current
>>> status in svn in which we can automate lots of things by just commiting to
>>> svn?
>>>
>>> Cheers,
>>>   Albert
>>
>>