--===============2457802185752346304==
Content-Type: multipart/signed; boundary="nextPart3773012.8y3LL9E8fd"; micalg="pgp-sha1"; protocol="application/pgp-signature"

--nextPart3773012.8y3LL9E8fd
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="iso-8859-1"

Hello,

On Thursday 25 June 2015 16:02:44 Christian Mollekopf wrote:
> On Wednesday 17 June 2015 23.01:41 Kevin Ottens wrote:
> > On Tuesday 16 June 2015 11:14:28 Christian Mollekopf wrote:
> > I don't think you've been disrespectful. I guess that was the limit=
 of my
> > metaphor which carried this feeling... turns out my footnote was be=
tter in
> > that regard. You've been obstinate though, but clearly you've not b=
een
> > alone with that trait. :-)
>=20
> Alright, that's fine then. I think I have to be a bit obstinate in th=
is
> situation, but I really don't want to piss people off, which is somet=
imes
> difficult to handle via email.

Tell me about it...
=20
> > BTW, I'd like to point out, because I think was not clear in that r=
egard
> > earlier. That personally I don't mind if we decide single version v=
s
> > multiple versions. I see pros and cons in both.
> >=20
> > What I'd like though is that either we go in one direction (differe=
nt
> > versions as the norm), or the other (status quo), but we don't go f=
or "A,
> > B and C do that while X, Y, Z does something else". It's what I tri=
ed to
> > point with "weird exceptions" earlier and failed.
>=20
> Ok, with that I can agree. I'm glad to hear you're opinion isn't set =
in
> stone on that topic, because that's what I (mistakenly) extracted fro=
m your
> previous responses.

Yeah, that's what I thought, and that's what I meant by it was probably=
=20
unclear. I realized late that when I beat the drum of "consistency" it =
could=20
be taken by mistake for "version numbers have to be consistent". For me=
 what's=20
important is that the rules we apply are consistent but they could resu=
lt in=20
different version numbers in the end, as long as everyone has the same=20=

treatment I'm fine.

That said seeing David's reply to my previous email it then opens the d=
oor to=20
the big fat cons which is "dependency hell" as he defines it.

> Since I'm currently swamped with work I'll have to put this on the
> back-burner for the moment, and as suggested we can pick this up duri=
ng
> akademy.

Yes, we've been dragging this topic far too long... to a point where Ak=
ademy=20
isn't that far anymore so it looks like a proper place to handle it now=
.
=20
> Until then I can also do some more preparation to explain the specifi=
c
> requirements better, and with that we can hopefully devise a solution=
 that
> works for everyone.

At least we get a chance of properly sharing where the pain points are =
and=20
what should be optimized or lived with. In any case it'll get us in a b=
etter=20
place than we're right now with that discussion.

Cheers.
=2D-=20
K=E9vin Ottens, http://ervin.ipsquad.net

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


--nextPart3773012.8y3LL9E8fd
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

iEYEABECAAYFAlWNbfsACgkQB0u7y43syeI2IACePYlFqdCGLwUiSqV+nzXR//nL
61cAoICapo5tvM/9f7EdD/2+K3K7PmeE
=Ns1V
-----END PGP SIGNATURE-----

--nextPart3773012.8y3LL9E8fd--


--===============2457802185752346304==
Content-Type: text/plain; charset="utf-8"
MIME-Version: 1.0
Content-Transfer-Encoding: base64
Content-Disposition: inline

X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KcmVsZWFzZS10
ZWFtIG1haWxpbmcgbGlzdApyZWxlYXNlLXRlYW1Aa2RlLm9yZwpodHRwczovL21haWwua2RlLm9y
Zy9tYWlsbWFuL2xpc3RpbmZvL3JlbGVhc2UtdGVhbQo=

--===============2457802185752346304==--