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

Re: Debian New Maintainer Guide 0.1

In article <[🔎] 199811142145370260.012B00CD@cibalia.gkvk.hr>, "Josip Rodin" <joy@cibalia.gkvk.hr> writes:
> On 14.11.1998., at 15:13, Adam Di Carlo wrote:
>> Well, you should be writing for slink anyhow, since any Debian
>> developer needs to be running it.  We're not really accepting
>> packages for hamm anymore.  See the Developer's Reference for why
>> not.

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

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.

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,

Finally, during freeze, it's every maintainer's duty to test their
package on a fully updated frozen machine.

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.

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

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

>  Yes, I know that
> appropriate dependencies must be met, but for some packages it's
> just libc6.

No, compiler too, not to mention libc6-dev, of course, and any
libraries you are linking with.  And you should always have the newest

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.

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

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

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.

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

.....Adam Di Carlo....adam@onShore.com.....<URL:http://www.onShore.com/>

Reply to: