--===============2144775566==
Content-Type: multipart/signed;
  boundary="nextPart1548187.t7GXombmqQ";
  protocol="application/pgp-signature";
  micalg=pgp-sha1
Content-Transfer-Encoding: 7bit

--nextPart1548187.t7GXombmqQ
Content-Type: text/plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

On Tuesday 11 December 2007 14:10:36 Matt Rogers wrote:
> On Tuesday 11 December 2007 05:08:09 Tom Albers wrote:
> > Op Tuesday 11 December 2007 03:14 schreef u:
> > > If Kevin wants to take over maintenance, that's fine, but making
> > > Kompare ready for KDE 4.0 seems like a goal not reachable considering
> > > when the release is going to be.

> > Seeing the recent mail about the current state of Kompare from Kevin,
> > which basically tells us it is working and he seems to want to actively
> > maintain the app, do you still have the same opinion? I agree it's pret=
ty
> > late, but if there is an active maintainer and the current stat is ok, I
> > feel we should give Kevin the chance (and motivation) to work on it and
> > include it in four point oh.

> Yes, I still have the same opinion. It's too late. We've already tagged R=
C2
> and the full release is in less than a month. We need to quit making last
> minute changes like this. What happened to being in "release mode"?
>
> We quit adding new applications to KDE 4.0 months ago. I don't see how
> resurrecting old ones that were previously disabled is any different.

I prefer fixing above removing, if that can be done easily, it should be do=
ne.=20
As to the freeze, kompare has been shipped for the last releases, so it was=
=20
part of the release (IMO). Having kompare in is a low-risk decision as it=20
doesn't touch other components and is a pretty "end-of-the-food-chain"=20
application, and since the code to fix it has already been written, no dama=
ge=20
is done.

Another option would've been to move kompare into extragear, that means tha=
t=20
it would be released at the same time (most probably) and packagers won't=20
find it immediately.

> However, seeing as the change has already been made, it doesn't really
> matter anyways and I have no legs to stand on for an argument anymore. It
> would have been nice if there had been a 24 hour wait period for feedback
> after the initial mail that Allen sent. --

That would be good practise. We ended up doing the same 24 hours grace peri=
od=20
for decisions in the Marketing Team as well, it adds a bit of safety to tho=
se=20
taking decisions, which I think is a good thing.
=2D-=20
sebas

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

--nextPart1548187.t7GXombmqQ
Content-Type: application/pgp-signature; name=signature.asc 
Content-Description: This is a digitally signed message part.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iQEVAwUAR16noGdNh9WRGQ75AQJJdQgAxM6gywVrdMjngPaEPgGSsAxLyLJWwb3q
vPnA198KkWK7aGTwzfXa376x1O8PKhjeCj+VdMtswrQsbzWIegZ8vqZ4PrR9Mz85
4hAFjm6XzW4RsUbNqq/futdIgJyy+wM/6MMVkPVGuxh+VpLpZIxG4Xq/7xWymtnk
ZHRSoh2imxJQXpWNBtHodY0LElV6IXOhWnXghzFcBX7GwTOefzhj780wfT6jMr+X
5eq1+EPnUijV0YEqH+yIlvCZkNlEFlvIU3jnN+z3S/gj6dG7LhdDrQYSfOwoEwyF
uQIDZd1VKV6REX95VeYn6ITlk2NzG85nW4aAcZgwjYFVq7D8SE+q+w==
=w3UH
-----END PGP SIGNATURE-----

--nextPart1548187.t7GXombmqQ--

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

--===============2144775566==--