On Monday 24 January 2011 23:44:44 Ian Clarke wrote: > On Mon, Jan 24, 2011 at 12:34 PM, David ?Bombe? Roden < > bombe at pterodactylus.net> wrote: > > > I have recently started using the branching model suggested by Vincent > > Driessen in http://nvie.com/posts/a-successful-git-branching-model/. At > > first > > the amount of branches that are created seem overwhelming but after a short > > time the benefits of having features cleanly separated before merging them > > outweigh the added complexity of the graph in gitk by far.
Haven't had time to read it in full yet but will sometime. Agree with lots of branches and feature freezes on near-release branches. > > I'm all for doing things in ways that have been proven successful by others. > The current approach which involves a variety of independent repositories > does seem fairly peculiar. Separate repositories for each user is standard practice with git. IMHO branch per feature, possibly plus branch per release, has a lot going for it. > > I'm also thinking we may want to draw a distinction between commits which > can be mostly tested on local nodes only, I would consider Freetalk an > example of this, and commits where we can only be sure of their impact once > widely deployed on the network. An example of the latter would be changes > to load balancing. Yes, although Freetalk and especially WoT and Sone generate such a proportion of the total that they could actually cause serious network issues. Also, I would point out that Freetalk must be and will always be a separate repository. One repository per PROJECT is IMHO absolutely sensible. > > The latter variety of commit should obviously be treated much more > conservatively than something which can be tested on a relatively small > number of nodes and are unlikely to have any "emergent" effects. Right. But we're gonna have to deploy new load management soon. I'm asking for testing over the weekend (from the snapshot I uploaded, which is equivalent to the merge-new-load-management branch or the testing-build-1340-maybe-merge-new-load-management-pre1 tag). And deploying it will be potentially severely disruptive. However, it is necessary, and there is a limit to how much testing can be done beforehand, and to how much perfectionism is worthwhile given the existing state of the network. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part. URL: <https://emu.freenetproject.org/pipermail/devl/attachments/20110130/3606b703/attachment.pgp>
