[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-debian-devel
Subject:    [devel] Re: Archive status wrt 'experimental',
From:       Daniel Stone <daniel () fooishbar ! org>
Date:       2004-01-05 1:32:40
Message-ID: 20040105013240.GW12510 () trinity ! unimelb ! edu ! au
[Download RAW message or body]

[Attachment #2 (multipart/signed)]


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:
> >> 
> >> 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...
> > 
> > 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?
> 
> 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.
> 
> 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?

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

[Attachment #5 (application/pgp-signature)]

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


[prev in list] [next in list] [prev in thread] [next in thread]