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

Re: Better brand recognition for new Debian (etch)

** Otavio Salvador ::

> >>>>> "humberto" == Humberto Massa Guimaraes 
> <humberto.massa@almg.gov.br> writes:
> humberto> IMHO, there is a series of (serious) problems in such a
> humberto> plan, such as:
> humberto> * testing and unstable are not installable by
> humberto> non-tech-folk, all the time, really. There can be times
> humberto> where they are, but there are some times they are
> humberto> not. They break.
> unstable really break sometimes but testing exist to be a always
> working version. This is why sometimes things have a so long delay
> to enters testing while it has something broken or with RC issues.

Not really. I explain: when a bug goes from unstable to testing (and
they do) and renders stuff uninstallable on testing, there is a
longer delay where things *will* be broken there, until the
corrected version goes there from unstable.
> humberto> * we should not really multiply (space, time, bandwidth)
> humberto> needed for our mirrors; right now, some archs are
> humberto> endangered because of such hefty requirements.
> we currently have support for partial mirroring using a lot of
> packaged tools like debmirror, rsync, mirror and
> debpartial-mirror.
> humberto> * we *do* have, after all, "tasks" to install desktops
> humberto> and (some, specialized?) servers, without having to
> humberto> resort to creating another 30G of repositories.
> I didn't understand what you mean here. Please explain.

The problem with Wiktor's proposal is not only mirroring, but
storing, building, and transferring (HD, CPU, bandwidth)
*separately* what he calls desktop-testing, desktop-stable, etc etc.
> humberto> * finally, the infrastructure necessary to do what you
> humberto> ask for is really a job better done by specialized
> humberto> derived distros (such as LinEx, Ubuntu, even Ian's own
> humberto> Progeny)
> Well yes and no. If we had a place to move the improvements we
> need on derivative distributions could be better since we have the
> possibility to merge more code and more effort and start to have
> more cooperation.
> Debian have all needed structure done. DAK support it very well
> and what is really need is only decide what is the rules for
> packages migrate to that releases from unstable.

No, after you decide that packages can migrate there is a lot of
things you should provide: more storage for the now-frozen package,
CPU to rebuild that specific version with the specific dependencies
in a point in time, bandwidth to transfer it back and forth and to
the mirrors. All this without giving anything more than
> I'm not sure if this is good or bad for Debian but is possible to
> have it working without so much effort.

We will have to agree in disagreeing.

HTH, Respectfully,

Reply to: