[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-core-devel
Subject:    Re: Plasma 5.2 bits for kdereview
From:       David Edmundson <david () davidedmundson ! co ! uk>
Date:       2015-01-08 21:05:45
Message-ID: CAGeFrHDxGjUqc3aQyHqGvGiapJnfYMx21ObVE6XO_pBKk+EU4Q () mail ! gmail ! com
[Download RAW message or body]

On Thu, Jan 8, 2015 at 5:54 PM, Luigi Toscano <luigi.toscano@tiscali.it>
wrote:

> Jonathan Riddell ha scritto:
> > On Thu, Jan 08, 2015 at 07:33:58AM -0200, Lamarque Souza wrote:
> >>    Regarding ModemManagerQt, libbluedevil, libkscreen and baloo, they
> are
> >>    supposed to be frameworks stuff (not sure about baloo) but they are
> not
> >>    ready yet. Why not created a frameworks-next group to include them
> there
> >>    until they are ready to move to frameworks (being it KF5 or even KF6
> in
> >>    the future)? The Linux kernel has such a thing and it seems to work
> for
> >>    them.
> >
> > It's doubtful if they'll ever be ready for Frameworks which has strict
> > quality requirements. Setting up yet another place to put them just
> > means yet another person has to work out the release management bits
> > and the distros need to package them separately.  I don't see any
> > problem it solves and I do see extra work by not just making them
> > officially part of Plasma.
>
> Yes, of course having a different place requires some changes to the
> release
> tools. Please note that having them in a different place does not mean they
> can't released _for now_ at the same time as another big package like
> Plasma
> (and go with a different release schedule when needed).
>
> I still think that having this kind of modules (libraries) formally
> separated
> is coherent with the vision of the post-kdelibs4 world.
>
> That said, there is no consensus here, as it seems I'm expressing I'm part
> of
> a minority view and I'm not in the release team, if no one else says
> anything
> else I would stop here for this specific case. If the problem surfaces
> again
> in future for more and more modules, I would raise it again.
>

FWIW, I think it's a good idea.
I  just don't think it's viable to be discussing it the day we tag a
release.

If it's something you want to push for, raise it before another problem
surfaces, as otherwise it'll just be too late to do anything again.

[Attachment #3 (text/html)]

<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Jan \
8, 2015 at 5:54 PM, Luigi Toscano <span dir="ltr">&lt;<a \
href="mailto:luigi.toscano@tiscali.it" \
target="_blank">luigi.toscano@tiscali.it</a>&gt;</span> wrote:<br><blockquote \
class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc \
solid;padding-left:1ex">Jonathan Riddell ha scritto:<br> <span class="">&gt; On Thu, \
Jan 08, 2015 at 07:33:58AM -0200, Lamarque Souza wrote:<br> &gt;&gt;      Regarding \
ModemManagerQt, libbluedevil, libkscreen and baloo, they are<br> &gt;&gt;      \
supposed to be frameworks stuff (not sure about baloo) but they are not<br> &gt;&gt;  \
ready yet. Why not created a frameworks-next group to include them there<br> &gt;&gt; \
until they are ready to move to frameworks (being it KF5 or even KF6 in<br> &gt;&gt;  \
the future)? The Linux kernel has such a thing and it seems to work for<br> &gt;&gt;  \
them.<br> &gt;<br>
&gt; It&#39;s doubtful if they&#39;ll ever be ready for Frameworks which has \
strict<br> &gt; quality requirements. Setting up yet another place to put them \
just<br> &gt; means yet another person has to work out the release management \
bits<br> &gt; and the distros need to package them separately.   I don&#39;t see \
any<br> &gt; problem it solves and I do see extra work by not just making them<br>
&gt; officially part of Plasma.<br>
<br>
</span>Yes, of course having a different place requires some changes to the \
release<br> tools. Please note that having them in a different place does not mean \
they<br> can&#39;t released _for now_ at the same time as another big package like \
Plasma<br> (and go with a different release schedule when needed).<br>
<br>
I still think that having this kind of modules (libraries) formally separated<br>
is coherent with the vision of the post-kdelibs4 world.<br>
<br>
That said, there is no consensus here, as it seems I&#39;m expressing I&#39;m part \
of<br> a minority view and I&#39;m not in the release team, if no one else says \
anything<br> else I would stop here for this specific case. If the problem surfaces \
again<br> in future for more and more modules, I would raise it \
again.<br></blockquote><div><br></div><div>FWIW, I think it&#39;s a good idea.  \
</div><div>I   just don&#39;t think it&#39;s viable to be discussing it the day we \
tag a release.</div><div><br></div><div>If it&#39;s something you want to push for, \
raise it before another problem surfaces, as otherwise it&#39;ll just be too late to \
do anything again.  </div><div><br></div></div></div></div>



[prev in list] [next in list] [prev in thread] [next in thread]