[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Debian-sf-devel] Package is split! Testers wanted!

From: Roland Mas
Subject: [Debian-sf-devel] Package is split! Testers wanted!
Date: Fri, 24 May 2002 21:55:22 +0200
User-agent: Gnus/5.090007 (Oort Gnus v0.07) Emacs/21.2 (i386-debian-linux-gnu)

Roland Mas (2002-05-21 14:25:19 +0200) :
>   The way I see it is this: I'm currently splitting the package.  To
> be frank, the current state of my local checkout of the CVS
> repository is "utterly broken, don't even think of installing it, it
> won't install anyway".  That's why you probably won't see many CVS
> commits from me in the next few days.

  Well, I just did a rather large commit.  This means the package as
of the current CVS is split, hopefully nicely.  I have inserted a bit
of magic in the build process.  Namely, DSF-Helper.  This is basically
a Perl script to replace #DSFHELPER:blah# tags by contents of files in
the debian/dsf-helper/ directory.  The goal is to keep in one place
the code for functions used throughout the packages.

> On the other hand, the current package (as of what's in CVS) seems
> to install fairly dependably, and be mostly working.  The problem is
> we don't know exactly what this "mostly" covers.  Therefore, we need
> more testing, more reporting of problems, and more fixing of those
> problems.  Therefore, we need more visibility.

  It seems my last commit installed smoothly on at least two systems,
although these were installations from scratch (as opposed to upgrades
from a 2.5 or a pre-split 2.6 package).

> 0. I'm currently trying to "design" how the packages will behave
> after the split (my previous attempts were coded rather than
> designed, and the result didn't work.  When the design is done, I'll
> probably post it and ask for comments.

  Well, read debian/README.Maintainer, it's in there.  It's not *all*
in there, but most of the important stuff is.  I'll try to add more
text to document how I think variants should be done (like,
sourceforge-db-remote, for instance).

> 1. I get to the point of making the sourceforge-* installable in
> some cases (preferably most cases, but maybe not);

  Done.  dpkg -i sourceforge*deb worked on both my test server and
Christian's.  Now it's your turn to try it out and give us your results.

> 2. We upload to experimental with a big "This doesn't work.  If it
> does, please tell us." warning.  We announce it here, on the
> Savannah webpage, on the debian-devel mailing list, everywhere.

  That's still a few days/weeks from now.

> 3. We collect lots and lots of bug reports.  We fix them.  When no
> more appear for a reasonable amount of time, we upload to unstable.

  The "collect bug reports" part can start now.  We'll probably upload
a 2.6-0+12 pre-release sometime, in the meantime feel free to make
your own package from CVS.

>   During all this period, we fix any grave bugs in the 2.5 series,
> if only as a recreation from the nightmare that is the split.  I
> think it will be necessary to upload a 2.5-30 sometime anyway, but I
> definitely expect 2.5 to be frozen.  No patches providing new
> features against 2.5 please, only bugfixes.

  I already fixed two bugs in 2.5 (one was on the Debian BTS, the
other wasn't but prevented the mailing-lists from working).

  Now for the interesting part: go on, test, crash-test, try to
install on previous versions, re-install, whatever.  Report
everything, be it success (preferably on this list) or failure (on the
Savannah BTS, but try to include the relevant information).  Work is
happening!  Be a part of it, or hold your peace for a few weeks ;-)

Roland Mas

La tradition orale, c'est comme un vieux fromage [...] -- Le Blaire
  -- Signatures à collectionner, série n°2, partie 1/3.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]