also sprach Carl Worth <cworth at> [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
for now, or another place where everyone can easily get an account.
As alternatives I propose 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.


Sebastian, would it make sense to migrate your work into a 'pu'

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 Use patchwork [1]?


martin | |

"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 at
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature (see

Reply via email to