From kde-multimedia  Fri Jul 29 22:55:58 2005
From: Michael Pyne <pynm0001 () comcast ! net>
Date: Fri, 29 Jul 2005 22:55:58 +0000
To: kde-multimedia
Subject: Re: aRts in trunk
Message-Id: <200507291855.58730.pynm0001 () comcast ! net>
X-MARC-Message: https://marc.info/?l=kde-multimedia&m=112267765020907
MIME-Version: 1
Content-Type: multipart/mixed; boundary="--===============1004874100=="

--===============1004874100==
Content-Type: multipart/signed;
  boundary="nextPart1353170.szlBASm5d7";
  protocol="application/pgp-signature";
  micalg=pgp-sha1
Content-Transfer-Encoding: 7bit

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

On Friday 29 July 2005 10:14, Scott Wheeler wrote:
> Does anyone have an objection to aRts being removed from trunk?  If not
> I'll give him the "ok" in the next day or so.

I have no objections.  In fact I'd like it to be removed.  Although not for=
=20
the reasons that there was a big flamewar over.

I'd like it removed because if not we'd have two independent copies of arts=
 in=20
trunk.  Branch 1.5 (which will be released with KDE 3.5, no?), and /trunk. =
=20
Any fixes that get applied should get applied to both, and so it makes no =
=20
sense to have both, as it's likely that they'll get out of sync=20
unnecessarily.

svn will check out any URL you give to it, and if you're using kdesvn-build=
=20
you can just stick "branch 1.5" into your arts module config, re-checkout,=
=20
and be done with it.

The only issue is that branch 1.5 is supposed to be frozen for bugfixes but=
=20
since aRts is currently unmaintained I don't see that as a huge issue.

As a conclusion I can say after reading the thread that I don't see what th=
e=20
huge issue is with removing the /trunk copy of aRts.  aRts would still be i=
n=20
svn ,you'd just be checking out from a different URL (or if it's already=20
checked out you'd have to svn switch, not the end of the world).  So there'=
s=20
no technical reason that aRts must be in /trunk to develop apps against it.

So regardless of technical merits of competing sound systems (and I'll admi=
t,=20
aRts + aKode has treated me much, much better than gstreamer on my system),=
=20
the only thing that having aRts in /trunk would do is create an aRts fork.

If it turns out later that people are willing to actually add enough featur=
es=20
to aRts to warrant a development branch then we can do so then.  Until then=
,=20
code duplication is still teh suck.

Regards,
 - Michael Pyne

--nextPart1353170.szlBASm5d7
Content-Type: application/pgp-signature

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

iD8DBQBC6rP+qjQYp5Omm0oRAlaZAJ47gos59xUS6VAManvF1/yRAoQS0wCgs3g3
JqVaHjvdjc3BRCTpQuoQguk=
=8o1K
-----END PGP SIGNATURE-----

--nextPart1353170.szlBASm5d7--

--===============1004874100==
Content-Type: text/plain; charset="iso-8859-1"
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

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

--===============1004874100==--