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

List:       kde-release-team
Subject:    Re: Fwd: Re: Fwd: KDE Frameworks Release Cycle
From:       Å¡umski <hrvoje.senjan () gmail ! com>
Date:       2014-04-30 17:56:51
Message-ID: 5170872.kOsdHztMvP () shumarija
[Download RAW message or body]

[Attachment #2 (multipart/signed)]


On Wednesday 30 of April 2014 17:24:42 Àlex Fiestas wrote:
...
> So with frameworks I think we can compromise with something like "last 5
> releases" and turn off "auto reporting" for anything older than that (this
> is just an example).
This essentially means distros (non-rolling ones at least) would always be out 
of date. Since the distro freeze kicks, until the first update would be ready, 
it would already pass approximately time you mention. 
So distro's would be always catching up, at best 2 releases behind.

And this best case scenario is only under the condition that distro's could 
get policies bypassed for the sake of KF5. Which i doubt. At least in openSUSE 
case, and from what i read Debian and Kubuntu also. Libraries are not Web 
Browser.

While i understand what do you want and try to accomplish, and as Scott 
indicated, certainly distro's won't and can't say what you do with the 
software you write - i really think this release schedule is not suited at all 
for 'release' distro's and their users.

Distros will try their best, but i also wonder how will bugzilla situation 
look. If we pull down bugfixes, w/o version updates (which is atm most likely 
scenario), how will devs know which patches did specific distro add? 
(additionally, DrKonqi is currently lacking bugzilla integration, so it 
decreases the options to even report bugs)
Also, it would be possible that all the fixes between the version bumps are 
backported, but since the version is bellow accepted one, no dice for that 
user/report - users wont know which patches they have, they'll just see 
version number.

If we do version updates, we need to update whole of KF5. Then the question of 
external dependencies arises. I can hardly believe that those wont be changed 
for the lifetime of KF5. 
(and i also wouldn't want frozen libraries for 5,6,7 years!) 
Then we also need to make sure e.g. that latest KCoreAddons don't trigger 
strange behavior in older release of Plasma. (i doubt that master KF5 
user/contributor will use this combo)
This is concern now when we only have one 'external' alpha release, consisting 
of few repos, which depends on KF5. When the Apps port, and hopefully, KF5 
spreads more then kdelibs where spread, i can imagine even bigger headaches. 
Then we'll all really need to become rolling distros to have any relevance 
(even though i personally for my use-case wouldn't mind that ;-) our release 
managers would kick us out).
From all the suggestions, imho having LTS release every X months would make 
things much easier to cope with.

> Cheers.

Cheers,
Hrvoje
["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]