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

List:       kde-devel
Subject:    Re: KDE3 maintenance
From:       "Aaron J. Seigo" <aseigo () kde ! org>
Date:       2009-11-19 18:08:33
Message-ID: 200911191008.34027.aseigo () kde ! org
[Download RAW message or body]

[Attachment #2 (multipart/signed)]


On November 19, 2009, Tom Albers wrote:

(i think we mostly agree on these points, but i want to offer some 
clarifications for others)

> Op Thursday 19 November 2009 00:47 schreef u:
> > On November 18, 2009, Tom Albers wrote:
> > > KDE3 is not supported any more, although we might publish security
> > > issues, we - as in the release team - will not make a 3.5.11 release.
> > > The 3.5 branch in any case is closed for features and string changes,
> > > so you can not commit those.
> >
> > and if he created a new branch in svn?
> 
> Well, the problem is that if we allow those patches into svn, we actually
>  put our 'ok' on it. 

if those patches are in a separate branch it should be ok; we don't put our 
approval on anything in playground, either, so this isn't a new concept for 
us.

>  issues. Also to have some idea about what goes in, at least someone has to
>  monitor the commits, apart from the fact that I think no-one will be very
>  excited to do that for such old code, it takes away time from the normal
>  hacking someone is doing.

yes, which is why we can't and shouldn't do releases of that software with the 
KDE brand attached to it. let a new community grow around that effort and if 
it ever reaches the size and maturity required to do a good and proper job of 
releasing, then we can talk about it again. in the meantime, we don't need to 
keep an eye on what someone does in a separate branch on their own time which 
we don't provide endorsed releases of.
 
> Let alone if you would actually test the patches that goes in. For many of
>  us that would mean setting up a KDE3 development environment from scratch.
>  I don't think we can deal with that, so I don't think we can put our 'ok'
>  on it, so I think they should not be committed.

KDE is inclusive, not exclusive. that's why the bar to getting an svn account 
is low, that's why we have playground with no restrictions and extragear with 
just a few requirements. we can certainly not put our brand behind such a 
branch for the reasons you note here, but those commits should be allowed into 
svn, just not into the existing kde 3 branches.
 
> > > I think the best thing you could do, is just make a website which
> > > gathers the patches. If you don't want to and want to work on a new KDE
> > > version with your patches, you are pretty much on your own though,
> >
> > unless he gathers a community around those efforts. i don't think we need
> > to lend our own efforts, e.g. release team engineering, but i also don't
> > think we should stifle the efforts of others.
> 
> That was certainly not my intention. I want to make sure up front there are
>  no expectation of KDE releasing a 3.5.11 or 3.6.0 ever. That's highly

agreed.

> What if we created a /branches/XxxX (no idea how to name it) which is a
>  copy of the KDE 3.5 branch and allow all those commits to go there. The

i think that's the best idea. Timothy could come up with name perhaps. 
(trinity? three-continued?)

>  current release team won't release it, no tarballs, no security screening,
>  no translations, and when people make tarballs they have to chose another
>  name then 'KDE' ?

agreed

> I personally think that if you want those patches to go downstream to the
>  distro's a webpage with all the patches makes a lot more sense to me.

on the flip side, i hate the fact that i have to chase down distro packages 
for patches applied to my own software. i'd much rather see patches hosted 
upstream, even if not in mainline.

> > yes, i don't think we could call it "KDE 3.5.11" or even "KDE <anything>"
> > without more eyes on the branch.
> 
> Which won't happen from the current group of KDE developers.

agreed :)

-- 
Aaron J. Seigo
humru othro a kohnu se
GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA  EE75 D6B7 2EB1 A7F1 DB43

KDE core developer sponsored by Qt Development Frameworks

["signature.asc" (application/pgp-signature)]

>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<


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