Re: Calendar and release schedule

[Nicolás Alvarez]

2017-04-16 14:18 GMT-03:00 Luigi Toscano :
> = Status of calendars
> The existing calendar page,  https://www.kde.org/events/month.php aggregates:
>
> - the calendar for KDE Applications, and previously KDE SC releases,
> authoritative source is http://www.kde.org/releaseschedule.ics (manually
> generated?);

The ics is generated "almost by hand" using this custom tool:
https://cgit.kde.org/sysadmin/release-tools.git/tree/tools/releaseschedule

-- 
Nicolás

Calendar and release schedule

[Luigi Toscano]

Hi,
(sending this to release-team@ as primary user)
the sysadmins kindly enabled the Calendar application on phabricator.kde.org.
It is still not stable, and marked in Phabricator documentation as "prototype":
https://secure.phabricator.com/book/phabricator/article/calendar/

Nevertheless, this is a good time to think about consolidating our various
calendars.

= Status of calendars
The existing calendar page,  https://www.kde.org/events/month.php aggregates:

- the calendar for KDE Applications, and previously KDE SC releases,
authoritative source is http://www.kde.org/releaseschedule.ics (manually
generated?);
- the calendar of other events (sprints/conferences?). I'm not sure where the
ICS is stored.

In addition, Plasma has its own (https://community.kde.org/Schedules/Plasma_5)
-
https://calendar.google.com/calendar/embed?src=031gkgqg1hjf8lcmj0em1d2sj8%40group.calendar.google.com=Europe/London


= Proposal
I tried as exercise to import http://www.kde.org/releaseschedule.ics inside
the Calendar application:
https://phabricator.kde.org/calendar/import/1/

But it seems that imported calendars are not so flexible (you can't associate
projects/tags to them).

So I'd suggest to go the other way round: define the events natively in
Calendar (so that we can associate them with the proper tag/project) and
export them if needed (as ICS).

We can change http://www.kde.org/releaseschedule.ics to redirect to the new
exported calendar for Applications, to not break existing users while they
migrate to the new URL.

The plan shouldn't pose any risk: in case of emergency (something really
broken with the application) we can always export all the events as ICS and
move away to another application.

Going forward, each project owner (or a subset of users, depending on the
choosen policy) could create the "release" event (or other important
milestones). The main problem was that, until not long time ago (see the
"Alternative proposal" below) there was no central place on *.kde.org where
users could easily define calendars accessible to everyone.

My dream is an reminder email to kde-i18n-doc@ with the upcoming releases, and
this should help (I have to check if it is possible to set specific reminder
for event subscribers, like kde-i18n-doc@, but there are other possible ways).

= Alternative proposal
Most of the points above applies also to the calendar integrated with
Nextcloud (which means the existing share.kde.org), which apparently finally
allows users to share  calendar without credentials:
https://help.nextcloud.com/t/shared-calendars-ics-format-available/8688
but I didn't test it so far.

Thoughts?

Ciao
-- 
Luigi

Re: KDE Applications 17.04.0 packages available for packagers

[Eric Hameleers]

On Fri, 14 Apr 2017, Albert Astals Cid wrote:


At the usual location.

Haven't had time to compile yet, will start now.

REVISIONS_AND_HASHES file at https://paste.kde.org/ptskor7sa

Public release next week thursday.

Cheers,
 Albert


After compiling marble, I end up with these library files and links:

$ ll /usr/lib64/libmarblewidget-qt5.so*
lrwxrwxrwx 1 root root  25 Apr 16 13:07 
/usr/lib64/libmarblewidget-qt5.so -> libmarblewidget-qt5.so.27*
-rwxr-xr-x 1 root root 7854768 Apr 16 12:56 
/usr/lib64/libmarblewidget-qt5.so.0.26.20*
lrwxrwxrwx 1 root root  30 Apr 16 13:07 
/usr/lib64/libmarblewidget-qt5.so.27 -> 
libmarblewidget-qt5.so.0.26.20*


Why the ".so.27"? As a result, digikam (compiled against marble 
16.12.3) complains with "error while loading shared libraries: 
libmarblewidget-qt5.so.26"


Looking at the library name "libmarblewidget-qt5.so.0.26.20" I would 
expect the symlink to end on 26, instead of 27.


Cheers, Eric

--
Eric Hameleers 
Home: http://alien.slackbook.org/blog/