--===============0759000022==
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature"; boundary="ocvL5ZWDEAsQ5ck/"
Content-Disposition: inline


--ocvL5ZWDEAsQ5ck/
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Mon, Jan 05, 2004 at 01:50:29AM +0100, Marcin Pawlik wrote:
> On Mon, Jan 05 at 09:32, Daniel Stone wrote:
> > On Sun, Jan 04, 2004 at 03:20:26PM +0100, Marcin Pawlik wrote:
> >>=20
> >> I think CVS is a better place for untested actively developed
> >> packages and we should set up official repository for our developers.
> >> I'm not sure what to do with Subversion - I prefer it but don't know
> >> how mature are the tools to e.x. incorporate it into building system.
> >> And it would be better to have one repository than two...
> >=20
> > I agree that having CVS and SVN available is a good thing (I
> > personally use SVN for the XFree86 and apache2 packges that I
> > co-maintain), but that doesn't really solve the problem of a place to
> > dump *binary* .debs.  It's useful for source, but not really for
> > binary debs. Why can't we have both?
>=20
> We can. I just didn't know how we can use it. I thought it's only a
> place to put development versions and we will be able to replace it with
> official CVS. We could, but experimental distribution you can put into
> your sources.list is much more convenient when you want to place many
> debs and have other developers install them. At least I think so.

'experimental' is just a place to dump anything that isn't yet mature
enough for mainstream - for Debian, this means XFree86 4.3, as the
packaging still needs some work, as well as new apt. This means
packaging, as well as upstream.

> So the only thing I'd like to discuss here is the idea that we should
> start official "development toolchain" earlier than Debian currently
> does. The repository I was thinking about should IMO act as the place
> our packages start his life in to walk through unstable/testing/stable/.
> It allows better cooperation, coordination and offers more transparency
> for the users.

Fair enough - I'll kick this over to -devel and throw it open; my only
opinion on the subject is that while experimental is nice, the only
place I use it is in Debian, and that's significantly larger than our
repository ever will be, so it may be overkill for our needs.

> > Minor updates - nothing groundbreaking infrastructurally, but new
> > versions of software. Stuff like newer Apache, newer
> > XFree86/KDE/whatever (for the workstation tree), newer mySQL. Things
> > like that. Not stuff like a /usr/doc->/usr/share/doc transition, or
> > core changes.
>=20
> Well, maybe I'm not intelligent enough but I still don't understand the
> whole picture. What's the position of this minor releases? Something
> like "unofficial preview releases" I was talking about (the second link
> from the previous mail)? And if not then how should we support them?
> They are obviously more frequent than debian releases. Shall we provide
> QA and security not only for our "stable" but for each "minor" that is
> generated?

Minor releases are just like Debian revisions - small updates, rolling
up security updates, bug fixes, etc, as well as some new versions. I
think we should offer security updates for the last 2 or 3 minor
versions, dunno about QA. All depends on manpower, doesn't it?

--=20
Daniel Stone                                              <daniel@fooishbar=
.org>
"The programs are documented fully by _The Rise and Fall of a Fooish Bar_,
available by the Info system." -- debian/manpage.sgml.ex, dh_make template

--ocvL5ZWDEAsQ5ck/
Content-Type: application/pgp-signature
Content-Disposition: inline

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

iD8DBQE/+L64cPClnTztfv0RAs5nAKCQVFT7Zsi56+kg+uUawrHhBFRqOACeI51Q
PdXn5IYJdw4Q3iRH6JWVCgk=
=KKnZ
-----END PGP SIGNATURE-----

--ocvL5ZWDEAsQ5ck/--

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

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

--===============0759000022==--