[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.
--
Roland Mas
La tradition orale, c'est comme un vieux fromage [...] -- Le Blaire
-- Signatures à collectionner, série n°2, partie 1/3.