[bt-devel] The future of development and DVCS

Eeli Kaikkonen eekaikko at mail.student.oulu.fi
Sat Dec 5 08:11:34 MST 2009

On Sat, 5 Dec 2009, Raoul Snyman wrote:

> On Saturday 05 December 2009 02:29:05 'Kang Sun' wrote:
> > [If anyone objects to top-posting, please say something]
> Me. Bandwidth is expensive here in SA, I could do with smaller e-mails. Inline
> posting and trimming replies would benefit me greatly.

Bandwidth is cheap here (0 euros, 100Mbit) but I still appreciate
trimmed replys. It's not just bandwidth but also clarity and

> One of the things that really sold me on LP was the approval system. If you
> want to merge something from your local branch into trunk, you push your
> branch up to LP, and then propose a merge. People on the core team then get an
> e-mail, and can approve or reject the merge proposal. It has a nice web
> interface for viewing the diff between trunk and your branch too.
> Of course you don't need to use the proposal system, but if you do, it helps
> to keep and improve the quality of the code in trunk, and also can prevent
> problems and bugs from arising.

This is actually the same system which I proposed in an earlier mail. It
works with any dvcs and any service provider, if we don't count specific
web interfaces.

Bigox has worried about the "web of trust". I don't think it affects us
in any way. It's meaningful for very large, strongly decentralized
projects (like Linux kernel). For us it's only potential, not actual. We
have and will have only one canonical HEAD or trunk, releases and a
central repository. If you use svn it's forced by technology. Most open
source projects actually use this kind of system, but if you use a dvcs
it's an agreed convention, not a technical feature/limitation. Of course
this centralized goverment can be circumvented even in the case of svn
by cloning the central repository and forking it, or just by sending
patches around between people, so in practice svn isn't any "safer" than
a dvcs and you need "trust" just as much as with a dvcs.

As far as I know the "trust" means nothing more that you can trust the
code (or actually people behind it), but it's quite meaningless to us
because we know anyways who commits code to our central repo and we
don't control it much except with commit priviledges.

	Eeli Kaikkonen (Mr.), Oulu, Finland
	e-mail: eekaikko at mailx.studentx.oulux.fix (with no x)

More information about the bt-devel mailing list