Re: kconfig_compiler (Re: KDE Frameworks 5.29.0)

[David Faure]

On lundi 12 décembre 2016 09:19:30 CET Kevin Funk wrote:
> On Saturday, 10 December 2016 17:17:10 CET Nicolás Alvarez wrote:
> > > El 10 dic 2016, a las 17:10, David Faure  escribió:
> > >> On samedi 10 décembre 2016 19:49:07 CET Martin Graesslin wrote:
> > >> So from my point of view breaking the incorrect behavior could be
> > >> acceptable here.
> > > 
> > > Yes, but after the next kdevplatform release, then, to avoid breaking
> > > compilation of released code.
> > > 
> > > Is the kdevplatform bugfix getting into the final 16.12 release?
> > > If I read
> > > https://community.kde.org/Schedules/Applications/16.12_Release_Schedule
> > > correctly, there's still time to sneak it in if needed, before Dec 15.
> > 
> > KDevPlatform and KDevelop are extragear ;)
> > 
> > The fix is already in the 5.0 branch, I guess we could release a v5.0.4
> > soon if needed.
> 
> +1
> 
> We could do this in 1-2 weeks (would fit our schedule). I don't think we
> want to rush and release v5.0.4 right now though. That would be an almost
> identical release to v5.0.3.

You have one month, even ;)

-- 
David Faure, fa...@kde.org, http://www.davidfaure.fr
Working on KDE Frameworks 5

Re: kconfig_compiler (Re: KDE Frameworks 5.29.0)

[Kevin Funk]

On Saturday, 10 December 2016 17:17:10 CET Nicolás Alvarez wrote:
> > El 10 dic 2016, a las 17:10, David Faure  escribió:
> >> On samedi 10 décembre 2016 19:49:07 CET Martin Graesslin wrote:
> >> So from my point of view breaking the incorrect behavior could be
> >> acceptable here.
> > 
> > Yes, but after the next kdevplatform release, then, to avoid breaking
> > compilation of released code.
> > 
> > Is the kdevplatform bugfix getting into the final 16.12 release?
> > If I read
> > https://community.kde.org/Schedules/Applications/16.12_Release_Schedule
> > correctly, there's still time to sneak it in if needed, before Dec 15.
> 
> KDevPlatform and KDevelop are extragear ;)
> 
> The fix is already in the 5.0 branch, I guess we could release a v5.0.4 soon
> if needed.

+1

We could do this in 1-2 weeks (would fit our schedule). I don't think we want 
to rush and release v5.0.4 right now though. That would be an almost identical 
release to v5.0.3.

Cheers,
Kevin


-- 
Kevin Funk | kf...@kde.org | http://kfunk.org

signature.asc
Description: This is a digitally signed message part.

Re: kconfig_compiler (Re: KDE Frameworks 5.29.0)

[Nicolás Alvarez]

> El 10 dic 2016, a las 17:10, David Faure  escribió:
> 
>> On samedi 10 décembre 2016 19:49:07 CET Martin Graesslin wrote:
>> So from my point of view breaking the incorrect behavior could be acceptable
>> here.
> 
> Yes, but after the next kdevplatform release, then, to avoid breaking 
> compilation of released code.
> 
> Is the kdevplatform bugfix getting into the final 16.12 release?
> If I read
> https://community.kde.org/Schedules/Applications/16.12_Release_Schedule
> correctly, there's still time to sneak it in if needed, before Dec 15.

KDevPlatform and KDevelop are extragear ;)

The fix is already in the 5.0 branch, I guess we could release a v5.0.4 soon if 
needed.

-- 
Nicolás

kconfig_compiler (Re: KDE Frameworks 5.29.0)

[David Faure]

On samedi 10 décembre 2016 19:49:07 CET Martin Graesslin wrote:
> To quote: "The \ tag may contain either the "name" attribute,
> which should be the name of the configuration file described, or the "arg"
> attribute, which, if set to "true", will allow you to pass the
> KSharedConfig::Ptr object to use."
> 
> We have here the condition of arg="true" and the generated code did not
> follow that. If Singleton=true was set in kcfgc an incorrect ctor taking a
> QString as argument is generated. That is what my change addresses.
> 
> So yes, anybody who used that was depending on a bug of kconfig compiler.

OK, then that's a good reason for a bugfix indeed, even SIC.

> One can argue that my change breaks SIC and I won't deny it. But the usage
> of the behavior was wrong.
> 
> I can do a special casing for the (incorrect) kdevelop case to provide SIC,
> but it will mean that we get another incorrect code compilation. The special
> casing would have to be:
> * arg=true
> * Singleton=true
> * Inherits=true
> -> preserve old behavior. I doubt that we win anything by that except of
> making the code more complex and the behavior seemingly more random.

Right, that doesn't sound good long term. 
 
> So from my point of view breaking the incorrect behavior could be acceptable
> here.

Yes, but after the next kdevplatform release, then, to avoid breaking 
compilation of released code.

Is the kdevplatform bugfix getting into the final 16.12 release?
If I read
https://community.kde.org/Schedules/Applications/16.12_Release_Schedule
correctly, there's still time to sneak it in if needed, before Dec 15.

Then we can re-apply the kconfig patch for KF 5.30 (January).

> I leave the decision to you.

At this point it's actually a decision for the kconfig maintainer, Matthew 
Dawson. My job is to ensure the KF5 releases are SC/BC, which in this case can 
be reduced to "a SIC bugfix is acceptable if we leave time for kdevplatform to 
get a new release which won't be hit by this".

-- 
David Faure, fa...@kde.org, http://www.davidfaure.fr
Working on KDE Frameworks 5

Re: KDE Frameworks 5.29.0

[Martin Graesslin]

On Saturday, December 10, 2016 3:47:56 PM CET David Faure wrote:
> On samedi 10 décembre 2016 09:52:06 CET Martin Graesslin wrote:
> > On Thursday, December 8, 2016 9:32:13 AM CET David Faure wrote:
> > > On mercredi 7 décembre 2016 21:06:11 CET Kevin Funk wrote:
> > > > On Wednesday, 7 December 2016 20:10:40 CET Albert Astals Cid wrote:
> > > > > El dimecres, 7 de desembre de 2016, a les 10:08:18 CET, David Faure
> > > > > va
> > > > > 
> > > > > escriure:
> > > > > > On lundi 5 décembre 2016 18:40:46 CET Martin Gräßlin wrote:
> > > > > > > Am 2016-12-05 09:20, schrieb David Faure:
> > > > > > > > On dimanche 4 décembre 2016 23:42:44 CET šumski wrote:
> > > > > > > >> On nedjelja, 4. prosinca 2016. 00:37:52 CET David Faure 
wrote:
> > > > > > > >> > Dear packagers,
> > > > > > > >> > 
> > > > > > > >> > KDE Frameworks 5.29.0 has been uploaded to the usual place.
> > > > > > > >> > 
> > > > > > > >> > New framework: prison
> > > > > > > >> > 
> > > > > > > >> > Public release next Saturday.
> > > > > > > >> > 
> > > > > > > >> > Thanks for the packaging work!
> > > > > > > >> 
> > > > > > > >> kconfig (r129382) breaks compilation of kdevplatform:
> > > > > > > >> http://paste.opensuse.org/82016854
> > > > > > > > 
> > > > > > > > Indeed (but it's not the change from RR 129382, it's commit
> > > > > > > > cd4e650
> > > > > > > > from
> > > > > > > > https://phabricator.kde.org/D3386
> > > > > > > > 
> > > > > > > > Seems to come from Inherits=BaseClass while BaseClass doesn't
> > > > > > > > use
> > > > > > > > arg="true".
> > > > > > > > 
> > > > > > > > Here's a testcase for the kconfig unittests. Martin, can you
> > > > > > > > take
> > > > > > > > a
> > > > > > > > look?
> > > > > > > 
> > > > > > > The earliest I can have a look is probably on Friday, I'm sorry.
> > > > > > > 
> > > > > > > My suggestion is to revert my two commits and I'll redo for next
> > > > > > > frameworks.
> > > > > > 
> > > > > > OK, done. New git tag and tarball:
> > > > > > 
> > > > > > kconfig v5.29.0-rc2
> > > > > > 47f7e954a58ba5538d055e2f75e483cade48ee8a
> > > > > > d6c12e0908de1b91529de15e75a52c9974685c91b423d5b5abeb06f261d0fa47
> > > > > > sources/kconfig-5.29.0.tar.xz
> > > > > 
> > > > > Acoording to kfunk the thing that broke kdevplatform wasn't really
> > > > > kconfigs
> > > > > fault but a side effect of kdevplatform code not being very good.
> > > > 
> > > > Heya,
> > > > 
> > > > the patch restoring the kdevplatform build with KF5 5.29:
> > > >   https://cgit.kde.org/kdevplatform.git/commit/?
> > > > 
> > > > id=e84645d1694bdad7f179cd41babce723fe07aa63
> > > > 
> > > > The code in kdevplatform is a bit special, it's probably the only
> > > > place
> > > > in
> > > > whole KDE which broke due to the recent changes in kconfig. I don't
> > > > see
> > > > an
> > > > easy migration path, even if you introduce said change in a later
> > > > kconfig
> > > > release.
> > > > 
> > > > I don't mind if you leave kconfig as-is. But that's probably something
> > > > for
> > > > dfaure to decide.
> > > 
> > > Well, the change to kdevplatform isn't released yet, so kconfig 5.29-rc1
> > > would break compilation of the current kdevplatform releases.
> > > 
> > > Also, the fact that I'm able to write a kconfig unittest that doesn't
> > > compile tells me that something isn't right with these kconfig changes
> > > ---
> > > unless it can be proven that what I'm doing in that new test is not
> > > meaningful and is (now) forbidden, in which case it should