Re: Package maintenance ideas
On Fri, 12 Sep 1997 email@example.com wrote:
> I think the *best* solution---due to its simplicity and the fact that
> it won't require significant increases in communication and the
> associated latency in the common case---is for Debian to have machines
> available on the net that any maintainer can use for compiling on
> architectures to which he or she does not otherwise have ready access.
That's a good idea. It would solve alot of problems and streamline the
process quite a bit.
> Problems that couldn't be resolved by the primary maintainer could be
> brought up on appropriate architecture-specific lists (debian-alpha,
> debian-sparc) where people with a vested interest in the platform
> could take on responsibility for making things work---in cooperation
> with the primary developer.
Very true and another good point. It would allow for probably a faster
way for getting packages ported without having to deal with constant
communication and effort.
> fakeroot, if we can get it working, even makes this a fairly safe
> thing, but anyone hosting such a machine would be well advised to not
> be using it for mission-critical stuff at the same time.
I haven't tried fakeroot yet and won't until the problems are resolved (I
have been trying to keep up with the discussions on debian-devel regarding
this). If it ends up working well, then it would DEFINITELY be a great
help in such an effort. If it doesn't work, though, how else would we
manage this? sudo? It's not a great option, but it probably could work.
> I guess it comes down to laziness on my part---if you assume that
> there is some minimum level of effort necessary to deal with a
> package, and that each architecture requires an additional (but
> smaller) expenditure of effort, then it is obviously more efficient if
> to have the one person doing all bits, barring big cross-platform
Hmmm...well, I agree that it's a good idea. I think that a multiple
maintainer system may evolve eventually for the more difficult packages
(stuff like netatalk and other larger projects). Because of the large
amount of work that sometimes needs to be done on those packages, I can
just see how ugly it might get without such a system. Would it make sense
to have the bug tracking system modified for that purpose in advance
before such situations arise?
> I've tried to sound Bruce out about the possibility of using Debian
> funds to support this, without any response
Yeah, we've talked about this before. I agree that it suits the purposes
of the Debian "organisation" to fund such a project, but then again, I'm
not a policy guy, as you well know, so I tend not to bring up stuff like
that on my own. I think that we could probably find enough cooperation
out there, though, to make this a reality without spending the money.
Granted, we won't get access to much fantastic equipment, but you get what
you pay for :P
> ---so, in true DIY fashion,
> then, I am planning, once I get moved over to my new job, to put my
> Multia on the net for just this purpose. Not much of a machine, but
> it's something.
Once the effort levels out a bit more, my UDB may end up on the net for
the same purpose, so you won't be alone. I am just holding out since I
seem to be one of the most active and get far more work done for now since
my machine travels with me between home and office.
Eventually, if mine does go up on the net, a fresh installation will be
done to verify the distribution and then it will be made available after
FYI, for everyone to know, both Mike and I run UDB's with the 166MHz
processors, so if anyone who wants to participate and/or help the
Debian-Alpha effort and has a superiour machine to ours (which isn't
hard...the UDB's are pretty much rock-bottom on the Alpha ladder), please
let us know if you can put the machine on the net and open it for
development. I know that it would help me out GREATLY having access to
even a 300MHz Alpha since alot of the packages that I've built have taken
many hours apiece to make.
Christopher C. Chimelis firstname.lastname@example.org
Division of Biomedical Communications
University of Miami School of Medicine
--> finger email@example.com for PGP public key <--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
Trouble? e-mail to firstname.lastname@example.org .