CI Requirements - Lessons Not Learnt?

[Henry Miller]

Having been paid to maintain a system that was a maze of #ifdef I
disagree with your statement that a professional should have no problem
with adding them. Sometimes a professional will add them, but not if
there is another choice. Every ifdef adds to the cost of maintenance,
and that is a very unprofessional thing to do to your company. 

Professional compiler writers tell us that the preprocessor is the
hardest part of supporting c++. Ide writers tell us that it is because
of the preprocessor they do not give us nearly as many tools for
refactoring as java has. The preprocessor is also why you find bugs in
the refactoring tools we get. 

Most of the work in KWin these days is Wayland. It is perfectly
reasonable for Martin to say that you must have the latest for Wayland,
it is a bleeding edge feature, distributions should not ship it without
a willingness to update as bugs in core components are fixed.  If they
don't like this, running KWin LTS on old fashioned X is what we should
point them to. 

This doesn't solve the ci problem that sparked this discussion, but your
proposal actually makes it worse. You are indirectly asking the ci
system to provide and build KDE with the old and the new xcbcommon. (not
just KWin, all of KDE needs to be tested in both configurations!) 
-- 
  Henry Miller
  hank at millerfarm.com

On Sun, Jan 15, 2017, at 03:58 PM, Alexander Neundorf wrote:
> Hi Martin,
> 
> just replying somewhere...
> 
> On 2017 M01 15, Sun 14:52:30 CET Martin Gräßlin wrote:
> > I think that is a reasonable suggestion. If distros patch our
> > dependencies we need to consider this as a fork. And a fork should be
> > called a fork. It needs to be clear that KDE is not responsible for any
> > issues caused by the fork and thus the complete product must be renamed.
> > 
> > Also if a component like KWin gets forked this means that the complete
> > product Plasma has to be considered as forked.
> 
> please excuse me, but I'd like to share some thoughts on the situation
> from a 
> non-technical POV. Maybe it can give you an impulse to think about the 
> situation. Ignore them if you think it is inappropriate.
> 
> You are maintaining kwin since several years now, and AFAIK the last
> years 
> more or less fulltime as your day job, right ?
> 
> If I'm right that this is the scenario, here are my thoughts
> - it would be good to have a second developer working on kwin, so you are
> a 
> (small) team. Then it is easier to discuss stuff and it would take some 
> pressure off of you.
> - is kwin more or less the only thing you're working on ? Doing that for 
> several years, and alone... it might have a relaxing effect if there was
> some 
> more variety in your job
> - OTOH, if you are maintaining kwin fulltime as paid job, I consider it 
> reasonable to expect that the maintainer is able to maintain necessary 
> #ifdefs, or apply pragmatic solutions, just to solve the problem for his 
> users... but that is not realistic to expect if the maintainer is quite 
> stressed out and all alone with this work.
> 
> All the best
> Alex
>