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

List:       kde-release-team
Subject:    Re: KDE3 maintenance
From:       Will Stephenson <wstephenson () kde ! org>
Date:       2009-12-09 8:53:55
Message-ID: 200912090953.56261.wstephenson () kde ! org
[Download RAW message or body]

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 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.  

>  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.

Will
_______________________________________________
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]