also sprach Carl Worth <cworth@cworth.org> [2010.01.23.1010 +1300]: > Anyway, I'll be on vacation for the next few days, so will likely > not have much, (likely have not much?), time for patch merging. > > But I *am* anxious to get back to the backlog. And in the > meantime, I really appreciate others merging and sharing patches. I discussed this with Carl at LCA a bit and ideally we should come up with a way to relieve Carl of the bottleneck burden (obviously without stealing away his dictator hat ;) I think it would make sense to move the mainline to git.debian.org for now, or another place where everyone can easily get an account. As alternatives I propose repo.or.cz. I'd prefer to stay away from commercial services like Github. Once we're there, how about copying the branch structure from Git development[0]: maint/ — the stable release master/ — the stablising head next/ — testing branch pu/ — patch integration branch (proposed updates) Each of the four branches is usually a direct descendant of the one above it. Conceptually, the feature enters at an unstable branch (usually 'next' or 'pu'), and "graduates" to 'master' for the next release once it is considered stable enough. 0. http://repo.or.cz/w/git.git/blob/HEAD:/Documentation/gitworkflows.txt Sebastian, would it make sense to migrate your work into a 'pu' branch? What patch tracking workflow should we adopt? Keep sending patches to the mailing list and have a few people who integrate them into master or pu (or even maint/next), as appropriate? Use the Debian bug tracker? Use Sebastian's Roundup instance? Set up a patch queue manager on notmuchmail.org? Use patchwork [1]? Cheers, -- martin | http://madduck.net/ | http://two.sentenc.es/ "in all unimportant matters, style, not sincerity, is the essential. in all important matters, style, not sincerity, is the essential." -- oscar wilde spamtraps: madduck.bogus@madduck.net