[notmuch] Git feature branch

[Carl Worth]

On Tue, 26 Jan 2010 10:32:31 +1300, martin f krafft <madduck at madduck.net> wrote:
> 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 ;)

Sounds great! Let's keep working together and find ways to help our
community work together. And I really appreciate all the help!

> 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.

I'm glad to help make things work on notmuchmail.org directly. I don't
have a problem giving out shell access to people who want to help set
things up the way we want. (And prototyping things elsewhere is fine
too.)

> 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)

I'm not a fan of this scheme, (or maybe I've just never quite understood
it).

When I first encountered this scheme, (when first using git), it was
never clear to me what branch I should actually run or test as a
user. Nor was it obvious which branches would be regularly rebased or
not---nor which branches had features being discussed on the mailing
list.

Here are some of my thoughts:

Instead of "maint" I'd much rather just have branches that are named
directly after the stable releases being maintained. We've done this
with the cairo repository with branch names like "1.2", "1.4", "1.6",
etc. That way it's very clear what the branch represents and it's
possible to have multiple concurrent "live" maintenance branches. But of
course, until we actually have releases, this doesn't really matter. :-)

I want to maintain a branch myself, (where I'm the only person pushing
to the branch). [This is different than what I've done with the cairo
repository where we have all core maintainer's pushing to a central
repository. I'm intentionally trying something new here.]

Obviously, that branch that I maintain is currently called "master", but
I wouldn't mind (and might actually prefer) to have it be called
"~cworth" or so. Though we have the problem that we need "master" to
point to *something*.

Beyond that, I'm quite happy to have any number of branches similarly
maintained by any other individuals. I want to get things setup so that
those will be hosted and listed alongside my branch on
notmuchmail.org. And I'll be happy to accept pull requests from
people. I expect to find people naturally gravitating to "ownership" or
particular portions of the code, where I will gain a lot of trust for
particular maintainers over the code they own.

> What patch tracking workflow should we adopt? Keep sending patches
> to the mailing list

I definitely like the patches on the list. I find that with notmuch, I
can maintain a queue of outstanding patches very effectively, (meaning,
that the queue is usable and doesn't forget even if I do get very far
behind like I am currently).

> 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]?

I'm personally not interested in any system that requires me to push any
additional buttons outside of notmuch and git itself. I am interested in
tools that can generate reports and help provide visibility into
things. So patchwork fixed to automatically notice when patches are
merged would be interesting. Also interesting would be support for
publishing my notmuch-based queue of patches to a web page.

-Carl
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://notmuchmail.org/pipermail/notmuch/attachments/20100203/75d8d745/attachment.pgp>