--===============0242230504357871341==
Content-Type: multipart/signed; boundary="nextPart3593428.y8fN4Hjgd9"; micalg="pgp-sha1"; protocol="application/pgp-signature"


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

On Tuesday 20 May 2014 08:00:43 Scott Kitterman wrote:
> On Tuesday, May 20, 2014 08:04:59 Kevin Ottens wrote:
> > On Monday 19 May 2014 22:28:27 Scott Kitterman wrote:
> > > Speaking as a packager for a distro that's in group #2, I don't s=
ee this
> > > as
> > > any change from your initial proposal.
> >=20
> > That's correct...
> >=20
> > > You're proposal moves us into group #1
> >=20
> > ... which is what I stated I think.
> >=20
> > Chosen extracts:
> > > > Going forward I see four options for addressing those packagers=
:
> > > >  1) Don't care, which means we're pushing them toward the case =
1,
> > > >  they'll
> > > >  release outdated versions with hand picked patches on top;
> > > >  2) Gain the necessary trust of our downstream to show that our=
 new
> > > >  releases are not less stable than our former bug fix releases;=

> > > >  3) Provide a yearly LTS branch as I've seen proposed;
> > > >  4) Provide release branches for which we commit backports.
> > > >=20
> > > > [...]
> > > > So, even though I understand why it wouldn't please packagers, =
I don't
> > > > think we should change course overall. So the tactic we'll foll=
ow is
> > > > (1)
> > > > hoping to get to (2).
> > > > Indeed, if we don't change course, I expect the distributions w=
ill all
> > > > move to a scheme of backporting. That's unfortunate, but hopefu=
lly,
> > > > we'll
> > > > manage to gain the required trust to prove that the releases ar=
e not
> > > > less
> > > > stable than the former bug fix releases
> >=20
> > So it's not that I don't understand, I completely see what will hap=
pen at
> > first.
> >=20
> > Now, I think we'll have to agree to disagree on something. You beli=
eve
> > there's some rule written in stone somewhere which will make the "e=
veryone
> > will pile up backports only" the new status quo forever, I say let'=
s try
> > and find out.
>=20
> I make no prediction about other distros, only mine.  You started thi=
s go at
> the topic by saying that packagers don't understand what developers d=
eal
> with and developers don't understand what packagers deal with and we =
had to
> try and cross that bridge.  Given that you're on the developer end of=
 that
> divide, why do you keep insisting you know better what will happen in=
 my
> distro that I do?

I never said I knew better, actually I'm pretty sure I don't. OTOH I'm =
sure=20
that polarizing the situation as much isn't going to help figure out th=
e real=20
outcome.

Also, I happen to have discussed with other packagers[*] before sending=
 the=20
email of yesterday who have a different opinion than you do, so it can'=
t be=20
labeled as our fate yet. Especially since we generally tend to do a bad=
 job at=20
predictions.

Regards.

[*] Some of them working on the same distribution than you.
=2D-=20
K=E9vin Ottens, http://ervin.ipsquad.net

KDAB - proud supporter of KDE, http://www.kdab.com


--nextPart3593428.y8fN4Hjgd9
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)

iEYEABECAAYFAlN7SjsACgkQB0u7y43syeIznACggk1TFsmfWP16+4nE9ugUVuNg
CnMAn30kbPsXkGZ/MY3xDlZ9G83l4L+m
=2BC8
-----END PGP SIGNATURE-----

--nextPart3593428.y8fN4Hjgd9--


--===============0242230504357871341==
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

--===============0242230504357871341==--