--===============5345616307895352737==
Content-Type: multipart/signed; boundary="nextPart1433473.lC4lAdFJDa"; micalg="pgp-sha1"; protocol="application/pgp-signature"


--nextPart1433473.lC4lAdFJDa
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="iso-8859-1"

On Wednesday 30 of April 2014 17:24:42 =C0lex Fiestas wrote:
...
> So with frameworks I think we can compromise with something like "las=
t 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=20
of date. Since the distro freeze kicks, until the first update would be=
 ready,=20
it would already pass approximately time you mention.=20
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 c=
ould=20
get policies bypassed for the sake of KF5. Which i doubt. At least in o=
penSUSE=20
case, and from what i read Debian and Kubuntu also. Libraries are not W=
eb=20
Browser.

While i understand what do you want and try to accomplish, and as Scott=
=20
indicated, certainly distro's won't and can't say what you do with the=20=

software you write - i really think this release schedule is not suited=
 at all=20
for 'release' distro's and their users.

Distros will try their best, but i also wonder how will bugzilla situat=
ion=20
look. If we pull down bugfixes, w/o version updates (which is atm most =
likely=20
scenario), how will devs know which patches did specific distro add?=20=

(additionally, DrKonqi is currently lacking bugzilla integration, so it=
=20
decreases the options to even report bugs)
Also, it would be possible that all the fixes between the version bumps=
 are=20
backported, but since the version is bellow accepted one, no dice for t=
hat=20
user/report - users wont know which patches they have, they'll just see=
=20
version number.

If we do version updates, we need to update whole of KF5. Then the ques=
tion of=20
external dependencies arises. I can hardly believe that those wont be c=
hanged=20
for the lifetime of KF5.=20
(and i also wouldn't want frozen libraries for 5,6,7 years!)=20
Then we also need to make sure e.g. that latest KCoreAddons don't trigg=
er=20
strange behavior in older release of Plasma. (i doubt that master KF5=20=

user/contributor will use this combo)
This is concern now when we only have one 'external' alpha release, con=
sisting=20
of few repos, which depends on KF5. When the Apps port, and hopefully, =
KF5=20
spreads more then kdelibs where spread, i can imagine even bigger heada=
ches.=20
Then we'll all really need to become rolling distros to have any releva=
nce=20
(even though i personally for my use-case wouldn't mind that ;-) our re=
lease=20
managers would kick us out).
From=20all the suggestions, imho having LTS release every X months would =
make=20
things much easier to cope with.

> Cheers.

Cheers,
Hrvoje
--nextPart1433473.lC4lAdFJDa
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part.
Content-Transfer-Encoding: 7Bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)

iQIcBAABAgAGBQJTYTloAAoJEKQ7p22BD1iAubAP/1wgK1zyfNdk4Y35YMlFD3XQ
Y0QOOu4LC86HK9vPtGZD9Fjme3spsufENK4W+kYttc1uM6cDwKuUdUYURHdXI0Pq
mi7BMQWMOnU83beGO82llzGsAI36dRHS2AVe3EnOzW9pz9bOwC58zG5I5rixADKV
dFDsx5YK3P814uBL+aKL4ND2SnGbO91BAnJB+p7rw1zrkxYRCQ0bgvpSZlBb6C00
rqJml3G69Fy35gkl2uSTxNv9vpxEcCk3BsIFbTdbYJlN7E/mRhIs/jxtLgh3iWzs
InZzd9ucc4Z5sU6dcJuP6HC4spiJf2awqy/rBIotE+nvLmV7VYnI6FcQr6BTrxte
p4r1WpDBVV/wSLQdUZhDiyUPhXsNDFL6oC2tt6eiNdB6A3X/XeQAmnh5b3k++uuR
vGBglw06nhp614cClgVipBImB2IHnvcmtB7ae0R6/JqYrhu3SgwxfOeo8V7JaIDO
0f5tQ0Q/vWGGvKIWBk2mSZ5uRMtNBIPCfPUmAcR0yRq7l8FcchSl2CdOJDJRSGqd
Vh2T4W0WGSo+sR4Vz6VQPNE6dHVj0fo69jgoaaEsRcQsfufftSuYic3Rn7iyqq9f
uK16y7sSyZlXFDvEv+m9XsfRFOhuC9IM1m5su2+2INu12GcWzRA7u5Mo6JxIeFUU
QSc7F7pj2nu4fme4pWdV
=JzQI
-----END PGP SIGNATURE-----

--nextPart1433473.lC4lAdFJDa--


--===============5345616307895352737==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

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

--===============5345616307895352737==--