Request to bump Qt version requirements to 4.6.3 for KDE SC 4.5 (and above)

2010-07-08 Thread Maciej Mrozowski
Hello

From what I understand, Plasma in KDE4 Workspace 4.5 relies on notifications 
provided by libdbusmenu-qt to control what to draw in system tray. And 
apparently Qt = Qt-4.6.2 contains known bug that causes 'close application' 
notifications not to be delivered - as a result causing system tray 
regressions - application icons not disappearing.

https://bugs.kde.org/show_bug.cgi?id=232915
https://bugs.kde.org/show_bug.cgi?id=195998
https://bugs.kde.org/show_bug.cgi?id=241248

and similar reports.

Because it's quite visually exposed and obvious bug (confirmed to be solved 
with mentioned Qt upgrade), I propose bumping Qt requirements to 4.6.3 for 4.5 
branch and trunk for whole KDE SC release (currently it requires Qt 4.6.0).

-- 
regards
MM
___
release-team mailing list
release-team@kde.org
https://mail.kde.org/mailman/listinfo/release-team


Re: Request to bump Qt version requirements to 4.6.3 for KDE SC 4.5 (and above)

2010-07-08 Thread Andreas Pakulat
On 08.07.10 17:36:09, Maciej Mrozowski wrote:
 Hello
 
 From what I understand, Plasma in KDE4 Workspace 4.5 relies on notifications 
 provided by libdbusmenu-qt to control what to draw in system tray. And 
 apparently Qt = Qt-4.6.2 contains known bug that causes 'close application' 
 notifications not to be delivered - as a result causing system tray 
 regressions - application icons not disappearing.
 
 https://bugs.kde.org/show_bug.cgi?id=232915
 https://bugs.kde.org/show_bug.cgi?id=195998
 https://bugs.kde.org/show_bug.cgi?id=241248
 
 and similar reports.
 
 Because it's quite visually exposed and obvious bug (confirmed to be solved 
 with mentioned Qt upgrade), I propose bumping Qt requirements to 4.6.3 for 
 4.5 
 branch and trunk for whole KDE SC release (currently it requires Qt 4.6.0).

This has already been discussed and as a compile-time requirement doesn't
make a runtime-requirement its been dis-approved (in fact this exact bump
was made, discussed afterwards and reverted again (see r1135987 and
r1136437 in kdelibs). IIRC the discussion was on kde-core-devel.

Andreas

-- 
You will wish you hadn't.
___
release-team mailing list
release-team@kde.org
https://mail.kde.org/mailman/listinfo/release-team


Re: Request to bump Qt version requirements to 4.6.3 for KDE SC 4.5 (and above)

2010-07-08 Thread Maciej Mrozowski
On Thursday 08 of July 2010 17:51:31 Andreas Pakulat wrote:
 On 08.07.10 17:36:09, Maciej Mrozowski wrote:
  Hello
  
  From what I understand, Plasma in KDE4 Workspace 4.5 relies on
  notifications
  
  provided by libdbusmenu-qt to control what to draw in system tray. And
  apparently Qt = Qt-4.6.2 contains known bug that causes 'close
  application' notifications not to be delivered - as a result causing
  system tray regressions - application icons not disappearing.
  
  https://bugs.kde.org/show_bug.cgi?id=232915
  https://bugs.kde.org/show_bug.cgi?id=195998
  https://bugs.kde.org/show_bug.cgi?id=241248
  
  and similar reports.
  
  Because it's quite visually exposed and obvious bug (confirmed to be
  solved with mentioned Qt upgrade), I propose bumping Qt requirements to
  4.6.3 for 4.5 branch and trunk for whole KDE SC release (currently it
  requires Qt 4.6.0).
 
 This has already been discussed and as a compile-time requirement doesn't
 make a runtime-requirement its been dis-approved (in fact this exact bump
 was made, discussed afterwards and reverted again (see r1135987 and
 r1136437 in kdelibs). IIRC the discussion was on kde-core-devel.

Fair enough.
Bug wranglers at bugs.kde.org won't appreciate such explanation though:

Revert r1135987: the build-time dependency should only be a minor release of 
Qt (4.6) not a patch-level release (4.6.3).

Qt maintains forward and backward binary compatibility within minor releases, 
so the patch-level releases are completely interchangable at runtime.  People 
should aim to use the latest patch-level release anyway in order to get 
bugfixes.

The question is: who cares whether Qt minor releases are interchangeable or 
not so that we can just specify minimal required dependencies to ensure only 
that stuff compiles?

the build-time dependency should only be a minor release of Qt  - is this 
policy written anywhere? Why is it more important that code compiles than 
providing better user experience? I think it's fundamental question.

If one of goals of KDE community is striving to provide the best user 
experience by any means necessary and if bumping version of dependencies is 
guaranteed to help here for many users compiling KDE from source and actually 
giving a hint for packagers, maybe it should be doneTM.

Also, as a potential bug reporter, I couldn't really accept such bug reports 
being RESOLVED (doesn't matter whether UPSTREAM or WONTFIX), because what it 
actually means is dontcaregoaway. Such bugs reports are valid because 
they're filled against properly built package (with respect to its build 
dependencies). It helps alienating community.

cheers

-- 
regards
MM
___
release-team mailing list
release-team@kde.org
https://mail.kde.org/mailman/listinfo/release-team


Re: Request to bump Qt version requirements to 4.6.3 for KDE SC 4.5 (and above)

2010-07-08 Thread Maciej Mrozowski
On Thursday 08 of July 2010 19:28:01 Thiago Macieira wrote:
 On Thursday 8. July 2010 18.42.36 Maciej Mrozowski wrote:
  The question is: who cares whether Qt minor releases are interchangeable
  or  not so that we can just specify minimal required dependencies to
  ensure only that stuff compiles?
  
  the build-time dependency should only be a minor release of Qt  - is
  this  policy written anywhere? Why is it more important that code
  compiles than providing better user experience? I think it's fundamental
  question.
 
 The build-time requirement doesn't influence the run-time requirement of
 Qt. You can compile against 4.6.3 and then run against 4.6.0.
 
 So requiring 4.6.3 to compile will NOT get your bug solved.

I disagree but let me explain.

Someone fetches KDE tarballs. Tries to build them - then encounters build 
error stating that Qt dependencies are not met. Person in question upgrades 
Qt, then builds KDE and problem has been solved by avoiding it.

If person in question is distro packager, he does the same, but he also 
ensures that runtime dependencies of packages he's preparing are matching 
build time dependencies. So problem has been avoided as well (note that KDE SC 
4.5.0 is not out yet and number of bug reported already is significant).

If said person purposely hacks buildsystem to allow older Qt version - he 
should be ready to grab the pieces. The only case when bug is not solved.

 You need to convince your distro to upgrade. And all KDE has to do is to
 say that distros should upgrade.
 
 And that should go without saying that distros should always upgrade. And
 they do.
 
 So what are you complaining about?
 
 Bug reported - ceck
 Bug fixed - check
 Distros upgrading - check

Right. But those users who will go through this exact same procedure over and 
over AGAIN. Because:
- they weren't told Qt-4.6.2 is broken in this regard (why would they? they 
just grab packages and build from source against whatever Qt version they 
happen to have)
or
- packager who prepared packages for them was not told Qt-4.6.2 is broken in 
this regard.
So the only reliable way for them to find out is to personally experience bug, 
fill it (or seach bugzilla first), then be told to go away and complain 
elsewhere (usually distro).
And all of this could have been avoided if dependencies were raised in first 
place.

(and some people say it's distros that work like it compiles - release)

Now, it's been enough noise already so most distro packagers are probably 
aware that current Qt dependencies for 4.5 are not what's supposed to be used 
actually, but there will always be people building from source manually.

cheers

-- 
Maciej Mrozowski
Gentoo KDE release coordinator


signature.asc
Description: This is a digitally signed message part.
___
release-team mailing list
release-team@kde.org
https://mail.kde.org/mailman/listinfo/release-team


Re: Request to bump Qt version requirements to 4.6.3 for KDE SC 4.5 (and above)

2010-07-08 Thread Andreas Pakulat
On 08.07.10 20:14:47, Maciej Mrozowski wrote:
 On Thursday 08 of July 2010 19:28:01 Thiago Macieira wrote:
  On Thursday 8. July 2010 18.42.36 Maciej Mrozowski wrote:
   The question is: who cares whether Qt minor releases are interchangeable
   or  not so that we can just specify minimal required dependencies to
   ensure only that stuff compiles?
   
   the build-time dependency should only be a minor release of Qt  - is
   this  policy written anywhere? Why is it more important that code
   compiles than providing better user experience? I think it's fundamental
   question.
  
  The build-time requirement doesn't influence the run-time requirement of
  Qt. You can compile against 4.6.3 and then run against 4.6.0.
  
  So requiring 4.6.3 to compile will NOT get your bug solved.
 
 I disagree but let me explain.
 
 Someone fetches KDE tarballs. Tries to build them - then encounters build 
 error stating that Qt dependencies are not met. Person in question upgrades 
 Qt, then builds KDE and problem has been solved by avoiding it.
 
 If person in question is distro packager, he does the same, but he also 
 ensures that runtime dependencies of packages he's preparing are matching 
 build time dependencies. So problem has been avoided as well (note that KDE 
 SC 
 4.5.0 is not out yet and number of bug reported already is significant).
 
 If said person purposely hacks buildsystem to allow older Qt version - he 
 should be ready to grab the pieces. The only case when bug is not solved.

And right-fully so, the packagers need to take care about this and
upgrade their Qt packages. Thats their job and only theirs. Thats not
KDE's business'. 

  You need to convince your distro to upgrade. And all KDE has to do is to
  say that distros should upgrade.
  
  And that should go without saying that distros should always upgrade. And
  they do.
  
  So what are you complaining about?
  
  Bug reported - ceck
  Bug fixed - check
  Distros upgrading - check
 
 Right. But those users who will go through this exact same procedure over and 
 over AGAIN. Because:
 - they weren't told Qt-4.6.2 is broken in this regard (why would they? they 
 just grab packages and build from source against whatever Qt version they 
 happen to have)

People building from sources are expected to be able to follow upstream
updates for _everything_ they build themselves. $random_user doesn't
build stuff from sources (except very few things), they use packages at
which point packagers come into the game:

 or
 - packager who prepared packages for them was not told Qt-4.6.2 is broken in 
 this regard.

Then he shouldn't be a packager. Packagers are _expected_ to follow the
upstream of whatever they package and update the packages as soon as an
update is released (at least for bugfix releases). If they're not able
to do that they shouldn't create packages in the first place.

 So the only reliable way for them to find out is to personally experience 
 bug, 
 fill it (or seach bugzilla first), then be told to go away and complain 
 elsewhere (usually distro).

Uhm, packagers are distro-people in most of the cases. So in case they
do ship KDE 4.5.x packages with Qt4.6.2 (or earlier) they'll get
bugreports and rightfully so. At that point its their job to find out whats 
wrong,
this may include filing a KDE bug and getting told this is an upstream
problem, please report to Qt.

 And all of this could have been avoided if dependencies were raised in first 
 place.

The compile time dependency is nonsense, KDE 4.5.x doesn't _need_ 4.6.3
to compile, it needs 4.6.x (x=0). The problem is a pure _runtime_
problem and hence needs to be fixed at runtime. If KDE had a way of
requiring a certain Qt version during runtime, that requirement should
be changed. But changing a build-time requirement because of 1 bug that
occurs during runtime is just plain wrong.

 (and some people say it's distros that work like it compiles - release)

So? Thats broken distro's and broken packagers, we shouldn't need to
care about people not taking their job seriously.

Andreas

-- 
Of course you have a purpose -- to find a purpose.
___
release-team mailing list
release-team@kde.org
https://mail.kde.org/mailman/listinfo/release-team


Re: Request to bump Qt version requirements to 4.6.3 for KDE SC 4.5 (and above)

2010-07-08 Thread Loïc Corbasson
Hi,

2010/7/8 Maciej Mrozowski reave...@gmail.com

 On Thursday 08 of July 2010 19:28:01 Thiago Macieira wrote:
  On Thursday 8. July 2010 18.42.36 Maciej Mrozowski wrote:
   The question is: who cares whether Qt minor releases are
 interchangeable
   or  not so that we can just specify minimal required dependencies to
   ensure only that stuff compiles?
  
   the build-time dependency should only be a minor release of Qt  - is
   this  policy written anywhere? Why is it more important that code
   compiles than providing better user experience? I think it's
 fundamental
   question.
 
  The build-time requirement doesn't influence the run-time requirement of
  Qt. You can compile against 4.6.3 and then run against 4.6.0.
 
  So requiring 4.6.3 to compile will NOT get your bug solved.

 I disagree but let me explain.

 Someone fetches KDE tarballs. Tries to build them - then encounters build
 error stating that Qt dependencies are not met. Person in question upgrades
 Qt, then builds KDE and problem has been solved by avoiding it.

 If person in question is distro packager, he does the same, but he also
 ensures that runtime dependencies of packages he's preparing are matching
 build time dependencies.

 Distro packager should know that he should upgrade to the latest version of
Qt 4.6 to get the latest fixes...


 If said person purposely hacks buildsystem to allow older Qt version - he
 should be ready to grab the pieces. The only case when bug is not solved.

  You need to convince your distro to upgrade. And all KDE has to do is to
  say that distros should upgrade.
 
  And that should go without saying that distros should always upgrade. And
  they do.
 
  So what are you complaining about?
 
  Bug reported - ceck
  Bug fixed - check
  Distros upgrading - check

 Right. But those users who will go through this exact same procedure over
 and
 over AGAIN. Because:
 - they weren't told Qt-4.6.2 is broken in this regard (why would they? they
 just grab packages and build from source against whatever Qt version they
 happen to have)


I feel that these are quite specific users you're talking about. People not
upgrading Qt and building their software themselves. I suppose that if they
are in that specific combination they somehow know what they're doing -- no?


 or
 - packager who prepared packages for them was not told Qt-4.6.2 is broken
 in
 this regard.


... because it's a Qt bug and the Qt packager should upgrade its package as
he is following the changelogs of the software he packages -- no?


 So the only reliable way for them to find out is to personally experience
 bug,
 fill it (or seach bugzilla first), then be told to go away and complain
 elsewhere (usually distro).
 And all of this could have been avoided if dependencies were raised in
 first
 place.

 And some people don't care about bugs for system tray notifications,
because they don't use them. Each new 4.6 version of Qt will fix bugs,
should we make it mandatory to upgrade for anyone wanting to use KDE? I
don't feel so. People who want fixed bugs upgrade. Others probably don't
care, whatever the reason behind this might be (maybe just because they
don't want to recompile everything just for something they're not using?).
Compile-time is for compilation-related checks.


 (and some people say it's distros that work like it compiles - release)

 Now, it's been enough noise already so most distro packagers are probably
 aware that current Qt dependencies for 4.5 are not what's supposed to be
 used
 actually, but there will always be people building from source manually.

 And they probably (should) know what they're doing.


 cheers

 --
 Maciej Mrozowski
 Gentoo KDE release coordinator


 Loïc Corbasson
[loic.corbas...@gmail.com]
___
release-team mailing list
release-team@kde.org
https://mail.kde.org/mailman/listinfo/release-team