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

List:       kde-release-team
Subject:    Re: KDE3 maintenance
From:       Sebastian =?iso-8859-1?q?K=FCgler?= <sebas () kde ! org>
Date:       2009-12-10 10:26:28
Message-ID: 200912101126.28502.sebas () 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:

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

I'd also exclude 3.6. A new substandtial release is just not going to fly given the 
amount of resources needed for a release. It'll just be badly tested and makes KDE 
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 

I think it makes sense then to have a 3.5 gatekeeper. Doesn't sound like fun, but if 
you guys (and I'm wearing my KDE hat here) have obligations to maintain KDE 3 
software, we should try to make this possible.

The kernel peeps are doing this with their 2.4.x.y releases, which seems to work. 
there are rare updates, with only a couple of very important fixes, but no new 
development. Not sure how we can adopt this scheme.

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

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

If we don't release, and we're not planning on getting our translation teams to 
translate it in all the languages KDE 3 supports, that's OK with me. I understand 
that for some stuff, where there are contractual obligations for KDE 3 maintainance 
with new features, it's necessary.

One final question. Do you (as those poor suckers who have to do KDE 3 maintainance) 
have any substantial problems that we need to address, or is it more a "we're working 
on this stuff which doesn't really fit into policies we've established earlier (when 
we basically wanted to concentrate development on KDE 4)"?

Not really solutions, but some food for thought, maybe.
-- 
sebas

http://www.kde.org | http://vizZzion.org | GPG Key ID: 9119 0EF9

["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]