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

List:       kde-frameworks-devel
Subject:    Re: Status of the KDE Runtime module splitting
From:       Aleix Pol <aleixpol () kde ! org>
Date:       2014-04-07 18:52:04
Message-ID: CACcA1Ro3LsF5UOxzbzrExQZ0TLePASDdFLiLumd3ynMjtr-FBA () mail ! gmail ! com
[Download RAW message or body]

[Attachment #2 (multipart/alternative)]


On Mon, Apr 7, 2014 at 7:08 PM, Alex Merry <alex.merry@kde.org> wrote:

> On 07/04/14 17:57, Aleix Pol wrote:
> > - kioslaves, kioslaves-extra: I'm waiting to get the respositories, the
> > sysadmin team seems to have some concerns. Discussing it at the moment
> > (when the time zones let us).
>
> Question: why two?  This means kioslaves split across three repos: kio,
> kioslaves and kioslaves-extra.  I'd have thought that core ioslaves,
> like file and http, should go in kio, and others in another repo (called
> kioslaves or kioslaves-extra, it doesn't really matter).  In fact,
> that's what I thought the decision was on this list (although I may have
> missed something).
>
> Alex
> _______________________________________________
> Kde-frameworks-devel mailing list
> Kde-frameworks-devel@kde.org
> https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
>

I was hoping this would have been discussed the last time I proposed the
splitting plan.

Anyway, file, ftp, http, help and mailto are already in kio framework. The
reason we have 2 is that it seemed odd to be releasing together the sftp or
smb kioslaves together with cgi or finger. And yes, it's a subjective
distinction.
Now please, if there are further objections regarding the initial plan,
let's start a new thread about it. This is not what this e-mail was meant
to be about.

Aleix

[Attachment #5 (text/html)]

<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Mon, Apr 7, 2014 \
at 7:08 PM, Alex Merry <span dir="ltr">&lt;<a href="mailto:alex.merry@kde.org" \
target="_blank">alex.merry@kde.org</a>&gt;</span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc \
solid;padding-left:1ex"><div class="">On 07/04/14 17:57, Aleix Pol wrote:<br> &gt; - \
kioslaves, kioslaves-extra: I&#39;m waiting to get the respositories, the<br> &gt; \
sysadmin team seems to have some concerns. Discussing it at the moment<br> &gt; (when \
the time zones let us).<br> <br>
</div>Question: why two?   This means kioslaves split across three repos: kio,<br>
kioslaves and kioslaves-extra.   I&#39;d have thought that core ioslaves,<br>
like file and http, should go in kio, and others in another repo (called<br>
kioslaves or kioslaves-extra, it doesn&#39;t really matter).   In fact,<br>
that&#39;s what I thought the decision was on this list (although I may have<br>
missed something).<br>
<br>
Alex<br>
_______________________________________________<br>
Kde-frameworks-devel mailing list<br>
<a href="mailto:Kde-frameworks-devel@kde.org">Kde-frameworks-devel@kde.org</a><br>
<a href="https://mail.kde.org/mailman/listinfo/kde-frameworks-devel" \
target="_blank">https://mail.kde.org/mailman/listinfo/kde-frameworks-devel</a><br> \
</blockquote></div><br></div><div class="gmail_extra">I was hoping this would have \
been discussed the last time I proposed the splitting plan.</div><div \
class="gmail_extra"><br></div><div class="gmail_extra">Anyway, file, ftp, http, help \
and mailto are already in kio framework. The reason we have 2 is that it seemed odd \
to be releasing together the sftp or smb kioslaves together with cgi or finger. And \
yes, it&#39;s a subjective distinction.  </div>

<div class="gmail_extra">Now please, if there are further objections regarding the \
initial plan, let&#39;s start a new thread about it. This is not what this e-mail was \
meant to be about.</div><div class="gmail_extra"><br>

</div><div class="gmail_extra">Aleix</div></div>



_______________________________________________
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel


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