wstephenson at kde.org
Wed Dec 9 09:53:55 CET 2009
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
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
> + 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.
More information about the release-team