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

List:       kde-release-team
Subject:    Re: KDE3 maintenance
From:       Volker Krause <vkrause () kde ! org>
Date:       2009-12-10 8:34:40
Message-ID: 200912100934.44441.vkrause () kde ! org
[Download RAW message or body]

[Attachment #2 (multipart/signed)]


On Wednesday 09 December 2009 09:53:55 Will Stephenson wrote:
> On Tuesday 24 November 2009 17:25:03 Allen Winter wrote:
> > On Wednesday 18 November 2009 1:48:01 pm Timothy Pearson wrote:
> > > I have been maintaining and improving KDE3 for Ubuntu for a while now,
> > > and have accumulated a massive set of patches that:
> > >  * Add lots of functionality
> > >  * Fix old bugs
> > >  * Allow compilation on new systems
> > >
> > > How would I go about including them into the KDE3 SVN/GIT, and then
> > > generating a new 3.5.11 release?
> >
> > I think we should put out a formal policy statement on 3.5.
>
> Fair enough, some of us have responsibilities regarding KDE 3 code.
>
> I suggest to neither discourage nor encourage further development beyond
> maintenance.  KDE 3 is Free Software too, so people (eg KDAB and Timothy)
> are free to contribute to it, but the KDE world has enough to do without
> devoting general resources (release team time, sysadmin time, i18n time,
> packager time) to KDE 3.
>
> > Here are some thoughts:
> >
> >  + 3.5 is done and finished. there will be no more 3.5 releases
>
> This thought does not exclude a KDE 3.6 :).  If people want to to continue
> to release KDE 3, we should let them, but perhaps under a different
> identity ('KDE 3 Legacy Project'?) so it's clear the KDE project has moved
> on and problems in inadequately-resourced KDE 3 releases don't make KDE as
> a whole look bad.
>
> Do you propose KDE 3 hackers like Timothy should commit new substantive new
> features into the KDE 3.5 branch or let them open up a KDE 3 trunk?  Is
> this fair, considering KDAB is putting new pim features into 3.5. branch
> already?

we (KDAB) don't do that, but work in the enterprise35 branch. On the contrary, 
we rely on a stable kdelibs from the 3.5 branch for that. Obviously, using 
another branch ("KDE3 trunk") would be preferably for further KDE 3 
development from our point of view

> >  + we will not allow commits into the 3.5 branch willy-nilly
>
> Agreed, I've got maintenance responsibilities here too and can't afford for
> it to become a playground.

same for us

> >  without the
> > normal process of maintainer and/or peer review
>
> However, KDE 3 module maintainers have moved on, we can't expect them to
> review KDE 3 stuff, therefore KDE 3 review will be necessarily less
> specialist and should be more conservative to prevent stuff getting in we
> don't understand.
>
> >  +  we could create a 3.5 group on reviewboard for 3.5 patches to be
> >  collected. If the patch creator wants their patch into 3.5 SVN, then
> > they need to work through normal maintainer/peer review channels to get
> > the patch accepted and committed.
> >
> >  + the kde-packagers mailing list will be notified if critical/security
> >  fixes for 3.5 become available.
>
> All good ideas.
>
> >  + perhaps we should tell kde-packagers about normal bugfixes and new
> >  features too??
>
> See if there's demand first before introducing a distraction.
>
> >  + I have no idea what we should do about new i18n strings or updated
> > docs that need translations.
>
> I'd let just let it happen.

We handle translations ourselves in the enterprise35 branch, obviously only 
for languages and applications our customers ask for. But this means it's 
generally possible to have the necessary i18n infrastructure set up for your 
own branches.

regards
Volker

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

_______________________________________________
release-team mailing list
release-team@kde.org
https://mail.kde.org/mailman/listinfo/release-team


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