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

List:       kde-frameworks-devel
Subject:    Re: How to promote less mature Frameworks?
From:       Aleix Pol <aleixpol () kde ! org>
Date:       2014-08-19 10:22:17
Message-ID: CACcA1Rpv16reiwrHeT8iQfm1zCoo+rof_30ZPrLtmwXF9r6gOA () mail ! gmail ! com
[Download RAW message or body]

[Attachment #2 (multipart/alternative)]


On Tue, Aug 19, 2014 at 9:33 AM, Kevin Ottens <ervin@kde.org> wrote:

> On Tuesday 19 August 2014 08:44:10 David Faure wrote:
> > On Friday 15 August 2014 12:51:58 Kevin Ottens wrote:
> > > And that's the problem if we release them. If it's released "with the
> > > rest" expect people to have wrong expectations about them.
> > >
> > > A possibility would be perhaps to produce nightly tarballs for those
> > > frameworks which don't have the "release: true" flag. This way they
> keep
> > > not being part of a release, and early adopters have something easy to
> > > grab.
> >
> > Wouldn't early adopters just checkout and build from git ?
>
> Well, I guess some of them might just want to grab something and run with
> it.
> Maybe not the majority indeed...
>
> > I don't know about you, but I almost never download a source tarball,
> > because a git checkout is just so much easier to update later.
> > We mostly make tarballs for packagers, and the non-mature frameworks
> we're
> > talking about should definitely NOT be packaged.
>
> Agreed.
>
> > IMHO the solution is just to publicize the upcoming frameworks somewhere.
>
> Which shouldn't be that hard, it's "only" about processing the yaml file
> and
> creating a page listing them. I think that's what makes most sense indeed.
>
> Regards.
>

Maybe we can show their API documentation as well, in a different category.
[1]

Aleix

[1] http://api.kde.org/

[Attachment #5 (text/html)]

<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Tue, Aug 19, 2014 \
at 9:33 AM, Kevin Ottens <span dir="ltr">&lt;<a href="mailto:ervin@kde.org" \
target="_blank">ervin@kde.org</a>&gt;</span> wrote:<br><blockquote \
class="gmail_quote" style="margin:0px 0px 0px \
0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">


<div class="">On Tuesday 19 August 2014 08:44:10 David Faure wrote:<br>
&gt; On Friday 15 August 2014 12:51:58 Kevin Ottens wrote:<br>
</div><div class="">&gt; &gt; And that&#39;s the problem if we release them. If \
it&#39;s released &quot;with the<br> &gt; &gt; rest&quot; expect people to have wrong \
expectations about them.<br> &gt; &gt;<br>
&gt; &gt; A possibility would be perhaps to produce nightly tarballs for those<br>
&gt; &gt; frameworks which don&#39;t have the &quot;release: true&quot; flag. This \
way they keep<br> &gt; &gt; not being part of a release, and early adopters have \
something easy to<br> &gt; &gt; grab.<br>
&gt;<br>
&gt; Wouldn&#39;t early adopters just checkout and build from git ?<br>
<br>
</div>Well, I guess some of them might just want to grab something and run with \
it.<br> Maybe not the majority indeed...<br>
<div class=""><br>
&gt; I don&#39;t know about you, but I almost never download a source tarball,<br>
&gt; because a git checkout is just so much easier to update later.<br>
&gt; We mostly make tarballs for packagers, and the non-mature frameworks \
we&#39;re<br> &gt; talking about should definitely NOT be packaged.<br>
<br>
</div>Agreed.<br>
<div class=""><br>
&gt; IMHO the solution is just to publicize the upcoming frameworks somewhere.<br>
<br>
</div>Which shouldn&#39;t be that hard, it&#39;s &quot;only&quot; about processing \
the yaml file and<br> creating a page listing them. I think that&#39;s what makes \
most sense indeed.<br> <div class=""><div class="h5"><br>
Regards.<br></div></div></blockquote><div><br></div><div>Maybe we can show their API \
documentation as well, in a different category. [1]</div><div><br></div><div>Aleix  \
</div><div><br></div><div>[1]  <a \
href="http://api.kde.org/">http://api.kde.org/</a></div>

</div></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]