Message: previous - next
Month: December 2013

Re: [trinity-devel] tdelibs FTBFS: cmake 2.8.12: INTERFACE_LINK_LIBRARIES vs. LINK_INTERFACE_LIBRARIES

From: "Darrell Anderson" <darrella@...>
Date: Sun, 08 Dec 2013 13:04:36 -0600
>Part of me says push now, as there are several serious reports 
>still open
>regarding removable disk mounting and handling.  On the other hand 
>already starting to lose people to XFCE because the current stable 
>version requires HAL and does not work with the latest network-
>manager versions.

Regarding cmake 2.8.12, that is and should be a Blocker bug report -
-- but not a blocker for R14. We add a note in the release README 
(refer to etherpad) that we are aware of the issue and offer 
packagers a temporary work-around similar to that suggested by Fat-
Zer. At least two people should test a formal patch, then we attach 
the patch to the bug report and reference the bug report in the 

Regarding the delays with rebuilding Debian/Ubuntu packages. The 
presumption seems open to debate whether all of these package sets 
have to be built on the Trinity servers. At a pace of 18 days the 
realization is the servers lack the capacity.

Likewise the presumption that all of these package sets must be 
built --- and mirrored --- before announcing the release.

We have so few people participating in development and packaging. I 
don't know why package sets need to be built on the Trinity 
servers. Why not by individual participants and then uploaded?

Moreso, rather than one bulk release, why not offer package sets 
progressively as they are built and mirrored? Issue press releases 
as each package set becomes available --- a simple public relations 
strategy that keeps Trinity in the news, let alone relieves serious 
tension and pressure to have all package sets built at one time. 
The initial press release merely states that additional package 
sets are forthcoming.

If build scripts and tarballs are available in the official release 
announcement, then others can get involved.

Until then serious triage is needed of what to support.

Unlike previous releases, the sticky part of R14 is the significant 
number of renaming and branding changes. As the old adage goes, we 
only get one chance to create a first impression.

We never developed any kind of release test plan. We hobbled along 
only through feedback by the few of us participating. We've done 
okay, but for example, we have not performed largescale testing of 
the r14-xdg-update script. Slavek and I tested but we are only two 
people with two different usage perspectives. That one script has 
the potential to destroy first impressions.

My personal usage of R14 indicates no serious problems. Yet I don't 
use every single package nor do I use all apps every day. I'm sure 
there are hidden bugs as a result of the massive renaming and 
branding changes. I'm not worried about these types of bugs.

My primary concern is not bug reports like cmake 2.8.12, but 
fundamental desktop usability. The desktop is the sole location 
where users and reviewers form their first impressions. While long-
term Trinity users will tolerate bugs, reviewers and new users will 
not. Of those types of reports listed in the etherpad, I see the 
following that should be resolved immediately:

1761 tdevelop FTBFS with recent (t)qassistantclient patches
1759 R14 FTBFS with cmake 2.8.12 --- only test a formal patch 
providing a temporary work-around
1733 Launcher menu (T-Menu) takes a long time to appear the first 
time using Alt+F1
1729 KOffice: Applications crash on logout

Get those reports resolved and release R14.

Long term, as noted, we will never resolve all bug reports in a 
timely manner. That kind of focus is part of maintenance releases. 
We establish an etherpad wish list for each maintenance release 
period. The bugzilla supports voting. Nothing fancy needed here.

Short term we focus on triage and develop a reasonable release pace 
for various distro packages.

I believe that after we release R14.0.0, and users migrate from 
3.5.x to R14, the bulk of the effort is behind us. We then focus on 
a maintenance release schedule where we no longer are distracted by 
the pressure of big announcements and big pushes. With maintenance 
releases we are able to move along at a steady pace. We just need 
to get past the big hump now known as R14.0.0. :-)