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

What distrib should new developers run (was Re: Debian New Maintainer Guide 0.1)



To all: DNMG 0.11 is out. Changes: everything reported on this
list before my last post.
Version 0.12 should be out in a few hours (hopefully, because
tomorrow I have a big physics test, and have to learn :)

On 15.11.1998., at 05:20, Adam Di Carlo wrote:

>> When I read the Developers reference I didn't see that running
>> unstable is a muß (maybe it was old version)?
>
>First off, the developer's reference isn't the end-all of documents.
>There's many many gaps in it.

And we are here to correct that :)

>Secondly, it depends.  Suppose I'm doing documentation packages.  In
>that case, for instance, I don't really need my whole system to be
>fully up-to-date.  I only need debiandoc-sgml to be the newest one,
>and perhaps, lout/latex/nsgmls/gs.  Oh, and don't forget sgml-base.

BTW just done that ;)

>But if you're maintaining a C++ package, you need to have a *lot* of
>the newest stuff, definately.  All the newest dev libraries, compiler,
>etc.

Do you mean a program that is written in C++, or a package
like g++?

>No, compiler too, not to mention libc6-dev, of course, and any
>libraries you are linking with.

IMHO only the binary compatibility matters. If program was
compiled with libfoo 1.1, and works with libfoo 1.2 why
recompiling (before freeze)?

For example, gentoo. Only lib it explicitly requires is GTK+ 1.0.5.
But it also requires libc6 and xlib6g, of course.
So I must compile it with newer libgtk1 than the one in hamm.
So I download libgtk{1,-dev} v1.0.6, it installs without problems,
and gentoo compiles and runs without any problems. I don't know
why should I urge people to upgrade to the latest libc or xlib
because my little unimportant package requires it.
If someone finds a bug related to this, he'll contact me or file
a bug report, and I'll find a way to fix it. But if it works, why
to recompile before freeze?
Don't you Americans have that saying, "Don't fix if it ain't broken"?

>Finally, during freeze, it's every maintainer's duty to test their
>package on a fully updated frozen machine.
>> Yes, I know that appropriate dependencies must be met, but for
>> some packages it's just libc6.

I missed to write "... met before frozen becomes stable, but...".
We agree with that, frozen is a special case. In frozen every
incompatibility can be overriden because the *whole* system
will be set up to use the new libs (or anything else), at the
end of the freeze. All this is IMHO, of course.

>And you should always have the newest lintian.

Definitely agreed, but to have latest lintian you don't need to have the
latest libc or anything else (or at least you didn't have to in 0.92).

>But the fact is that developers are developing for unstable or frozen;
>not for stable.  If you don't have a local test environment for your
>package which is adequate, you cannot do adequate testing.  If you
>cannot test adequately (i.e., basic operational testing, in an
>environment basically like what you expect it to be installed in), you
>shouldn't upload.  That is stated in the developer's reference.

Environment that packages in 'unstable' are aimed at is 'unstable',
but many, many people (the real testers and users, around the globe)
don't upgrade their whole system to 'unstable', but only parts that
base system does not depend on - stuff that is 'optional' and 'extra',
and certainly not in 'essential' or 'important'.
In my experience, nobody that wants to be sure his system will
work won't install new libc6, gcc, make or something from 'unstable',
but he surely won't object to installing some new editor, window
manager, or game - because he'll always be able to return to old
programs with little or no fuss. And IMHO that is not the case
when you upgrade your libc especially if it breaks any compatibility.

>> And don't you think
>> this is just a little bit unreasonable, because of the vast amount
>> of files that have to be downloaded, since most of us don't have
>> ways to get current slink 'snapshots' on CDs?
>
>Still, them's the brakes.

I don't understand this sentence.

>Well, I realize that it can be expensive to call, i.e., in Germany.
>Find a way, or don't maintain it.

If you think that only Germany has expensive phone tolls, you
are wrong, because approx. half of the world hooks up to the
net just to get and send their e-mail. And I don't believe that in
America it's very cheap to download 350MB. Or is it?

>If you're very smart, and you know all of your packages dependancies,
>sure, I suppose you could have a hybrid unstable/stable box that
>covers all your package's dependancies.  I wouldn't recommend it as a
>rule, nor for newbies.

Every maintainer really should know his packages dependencies
(well, maybe not the versions but definitely names)!

For example, all three of my computers (well, two are not really mine
but I administer them) that I've installed Debian on, are modified hamms.
Only things I've upgraded that is important is sendmail, bash, and
tcsh, and that is for security reasons. But I do have newest versions
of netscape, windowmaker, kde, and xbill :)

>>  Maybe if there was some machine like master or va, and
>> running the most recent unstable, with lots of processor power - so
>> we could all recompile in less then hour, instead of getting
>> unstable?
>
>There is: va and master.  However, we're not about to give out root to
>every maintainer, so it hardly constitutes a proper testing
>environment, since you can't even install your package.

Aren't they hamm? I'll go and check out.

>> Yes, I know that upgrading to slink isn't so
>> time/phonecost consuming when you do it regularily, but you must
>> start upgrading from the start of every new unstable?
>
>No, I stick to frozen, i.e., right now, I'm not running unstable; I'm
>running frozen.

My point was that if I wanted do download whole unstable now, I
would get ~750MB. And until the release I would have to download
another ~100MB (because of bugfixes).
But, then I would ask myself, did I want do be a developer or
a beta tester?

>Certainly when we're frozen you should have a full frozen box.  And
>generally at the end of the unstable cycle, it's a very good idea.

I agree (but haven't got any packages in current frozen).

>Maybe I need to add a note in the developer's reference about all
>this...

Please do.

P.S. All this philosophy gives me a headache... :-)


/*- enJoy -*/\*- http://jagor.srce.hr/~jrodin/ -*/


Reply to: