KDevelop and Frameworks

[Sergey Kalinichev]

>> > > On Fri, Jul 4, 2014 at 10:59 AM, Milian Wolff <mail at milianw.de>
>> > > wrote:
>> > > > Finally, I want to know what our GSOC students think of this
>> > > > (CC'ed).
>> > > > Would it
>> > > > be OK for you to setup a KF5 toolchain and continue your work
>> > > > there?

Fine with me too. I've already set it up.

> Right, the thing is that 4.7 is string and feature frozen and thus we cannot
> merge the new functionality from Sergey there. So a legacy branch, or say -
> just a sergey-gsoc2014 branch or similar - would be required. I also have no
> intention of doing another KDE4 feature release, only 4.7 bug fix releases.

No problem. Still I think that my work in .7 already self-contained,
so imo it makes sense for me to implement new features in KF5 too.

--
Regards,
Sergey


On 7/4/14, Milian Wolff <mail at milianw.de> wrote:
> On Friday 04 July 2014 17:29:47 Aleix Pol wrote:
>> On Fri, Jul 4, 2014 at 4:36 PM, Kevin Funk <kfunk at kde.org> wrote:
>> > On Friday 04 July 2014 12:15:48 Aleix Pol wrote:
>> > > On Fri, Jul 4, 2014 at 10:59 AM, Milian Wolff <mail at milianw.de>
>> > > wrote:
>> > > > On Friday 04 July 2014 01:08:13 Aleix Pol wrote:
>> > > > > Hi,
>> > > > > I just saw Alexander Richardson review request about deprecated
>> > > >
>> > > > KSharedPtr
>> > > >
>> > > > > and first thing I thought "why didn't I do that already?". Well,
>> > > > > the
>> > > > > thinking behind was to do a minimalistic port [1] while features
>> > > > > were
>> > > > > developed in master, so we could merge back easily.
>> >
>> > Same intention here. Didn't want to do invasive changes as long as we
>> > keep
>> > merging back changes from master.
>> >
>> > > > > KDevelop 4.7 has been branched now, KF 5.0 has been released, so
>> >
>> > it's a
>> >
>> > > > > good moment to put it on the table.
>> > > > > How do you guys feel about a: git merge frameworks?
>> >
>> > +1
>> >
>> > > > Fine with me. I'll work on 1.7 until its released anyways and that
>> >
>> > should
>> >
>> > > > give
>> > > > me enough time to setup a kf5 toolchain.
>> > > >
>> > > > Speaking of which, we will have to update our wiki HowToCompile
>> > > > page,
>> >
>> > and
>> >
>> > > > at
>> > > > least announce it also on our user lists, the planet and our
>> > > > website.
>> > > > There
>> > > > are, after all, a lot of people who build kdev* from master.
>> >
>> > Furthermore,
>> >
>> > > > I
>> > > > would appreciate it, if either of those who successfully built
>> > > > KDevelop
>> > > > frameworks can document that in every detail. Paste your
>> > > > kdesrc-buildrc
>> > > > and
>> > > > dependent included configuration files. Create a list of frameworks
>> >
>> > that
>> >
>> > > > KDevelop requires.
>> > > >
>> > > > Also, I'm not sure how much master and 1.7 diverged. If there
>> > > > happened
>> >
>> > a
>> >
>> > > > lot,
>> > > > I vote for branching off master into a "legacy" branch just for
>> > > > people
>> > > > that
>> >
>> > Do we really need that? 4.7/1.7 *is* legacy and we should just try
>> > stabilizing
>> > that one, not yet another branch.
>> >
>> > > > stick to KDE 4 for now. Feature development will go to master/kf5
>> > > > of
>> > > > course.
>> > > > Finally, I want to know what our GSOC students think of this
>> > > > (CC'ed).
>> > > > Would it
>> > > > be OK for you to setup a KF5 toolchain and continue your work
>> > > > there?
>> > > > If
>> > > > not, I
>> > > > guess it would be fine if we go the "legacy" way proposed above,
>> > > > and
>> > > > you'll
>> > > > continue your work there. Once GSOC is over, we can merge/rebase it
>> > > > on
>> > > > frameworks.
>> > > >
>> > > > Bye
>> > >
>> > > That's a good point, maybe it would be interesting to wait until GSoC
>> > > is
>> > > over to release a 4.8 version, so users can take advantage of the
>> >
>> > on-going
>> >
>> > > GSoC projects.
>> > >
>> > > I don't think the GSoC students should change the platform they work
>> > > on
>> >
>> > in
>> >
>> > > the middle of the project.
>> > >
>> > > Aleix
>> >
>> > Personally I'm not to fond of another 4.8. We should just focus on KF5
>> > now
>> > for
>> > feature development and focus on 4.7/1.7 for stabilizing. I'd consider
>> > this
>> > the last KDE4 release. Otherwise we'll have to merge back changes which
>> > causes
>> > additional work-load (And we still could not do invasive changes to the
>> > frameworks branch, which is required to get rid off kdelibs4support and
>> > friends).
>> >
>> > Regarding GSoC: I think it depends on the GSoC project.
>> >
>> > For both Denis and me it probably makes sense to base our work directly
>> > on
>> > KF5. Personally, I think both projects would fit into a shiny KF5
>> > release
>> > announcement. So people also have a good reason to adopt the KF5
>> > version
>> > of
>> > KDevelop early.
>> >
>> > Sergey's work is already part of 4.7/1.7, hence he should continue
>> > working
>> > on
>> > these branches.
>> >
>> > Makes sense?
>> >
>> > Greets
>> >
>> > --
>> > Kevin Funk
>>
>> Well, we shouldn't be adding new features on .7, so if sergey, denis or
>> you
>> need to enhance something in kdevplatform or KDevelop you can and keep
>> the
>> plugins suitable for kdev4. It could be interesting that people could try
>> kdev-clang and kdev-qmljs after this summer on kdevelop 4.
>
> Right, the thing is that 4.7 is string and feature frozen and thus we cannot
>
> merge the new functionality from Sergey there. So a legacy branch, or say -
>
> just a sergey-gsoc2014 branch or similar - would be required. I also have no
>
> intention of doing another KDE4 feature release, only 4.7 bug fix releases.
>
>> But then that's given the premise that you want your work functional in
>> kdev4, which is especially interesting for clang and qmljs, although I'm
>> unaware of the status of the plugins.
>
> Yep, I think these two can decide on their own what they want to target.
>
> Bye
> --
> Milian Wolff
> mail at milianw.de
> http://milianw.de
> _______________________________________________
> KDevelop-devel mailing list
> KDevelop-devel at kde.org
> https://mail.kde.org/mailman/listinfo/kdevelop-devel
>