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

Re: RFC: Central version control for Debian

from devil's_advocate import *

(should really have been on the top of the last message too :)
and i've been awake for about 17hours, and am moving offices. I
may talk shit. (TM))
* Matt Zimmerman (mdz@debian.org) wrote :
> On Mon, Jan 29, 2001 at 10:59:14PM +0000, Thom May wrote:
> > The BSDs use CVS for their core system. Ie kernel, basic system requirements,
> > that sort of thing.  you'll see the package tree is (a) fairly separate (b)
> > not full of packages anyway, just Makefiles and patches.
> The base system is where the auditing is concentrated, and for good reason.
> am just suggesting ways in which Debian could benefit from similar tools and
> methodology.
I think the idea is more suited to - in the form being discussed
- to one of the BSDs. After all, they have "control" of the entire
operæting system.  
> I imagine that each area of the tree would be subject to its own access control
> policy.  Notification of changes is easy, as I noted later, as it can be
> automated.  A lot of coordination would be necessary to avoid conflicting
> changes and other such messes, though.  The scalable solution would be for each
> maintainer to determine the access control policy for his/her packages.
It would be a fairly massive investment of resources to get
working right. It would also be - relatively - a lot tougher to add
a new package - a new module would have to be added, decisions
on access control made, set up of who to mail changes too - a
list, a group of maintainers, just the developer, etc. While it
would be easy to automate this, it's another layer in front of a
developer wishing to add a new package.
> > > - Maintainers adopting orphaned packages would have access to the complete
> > > history of the package, to help avoid repeating old mistakes, and to help
> > > understand why changes were made.
> > That's what the changelog is for.
> The changelog is too granular, and has no mapping to actual changes in the
> source code.  CVS supplies that mapping with log messages and diffs for each
> revision.
Yes, you're right. I didn't consider that well enough.
> > > - A hypothetical security auditing team could easily and methodically audit
> > > the entire source tree.
> > *falls off his chair* Debian has ~600 developers. if each of them only
> > maintains 4 packages, each of around a megabyte of source code ( a gross
> > simplification, and doesn't take into account things like X, emacs, gnome,
> > kde etc). This is 2.4 gig of source code. Not to mention documentation. 
> I didn't claim that it would be quick or easy.  Such a project (as has already
> been suggested here) would probably start with the (relatively manageable) base
> system.

> True, but what is the analogue to cvs diff -rrev1 -rrev2?  cvs log <file>?
> These are powerful tools for keeping aware of what is going on with a source
> tree.
Sure. I was really voicing my overarching conecerns, rather than
granularily going through point to point. I should have taken
more time to write my first email.
> I subscribe to debian-bugs-dist, and sometimes to try to help investigate a
> bug, I'll download and extract the source package and poke around.  But if
> something broke between the previous revision and this one, I have to guess
> (based on the package changelog and my knowledge of the software) where to look
> for the problem.  Even knowing exactly which files changed between two
> revisions would be a huge help.  Members of the QA team would likely agree.
> > Tricky with CVS, i think. 
> Impossible in the current implementation.  One needs write access to the
> _directories_ in the repository in order to make any changes at all.
Yep. is subversion worth a look? - subversion.tigris.org, license
appears to be based on APL - it's still fairly new.
> The answer may be that Debian is simply too big to be manageable using such a
> system.  One could also argue that Debian is simply too large and complex to be
> secure.  In that case, we should focus on doing what we can for a subset of
> Debian.
Sure. but at that point, how do we define the subset? Is it just
the base system? Important packages? Daemons and services only?
I guess my major concern is that this idea - while highly laudible -
could easily eat up a major amount of infrastructure and
developer time.

> I have a 9gb disk looking for a use; I may just extract a useable subset of
> Debian into a CVS tree there and see what happens.  The components for
> importing new versions should be relatively simple.
I'll be very interested in the results :-)

Attachment: pgpzNTKG8trXx.pgp
Description: PGP signature

Reply to: