* Git feature branch @ 2010-01-20 14:00 Sebastian Spaeth 2010-01-20 20:00 ` micah anderson 0 siblings, 1 reply; 29+ messages in thread From: Sebastian Spaeth @ 2010-01-20 14:00 UTC (permalink / raw) To: Notmuch development list As I do like some of the additional patches, I am shoving some of them into my "all feature" branch. I make that one available in case you want to pull from it. It currently carries: Jameson Rollins: Simplify "unread" tag handling in emacs UI. David Bremner: notmuch.el: Refactor citation markup. Variables for minimum size, button text. Dirk-Jan C. Binnema: notmuch-new.c: refactor and improve dirs-to-ignore a bit Sebastian Spaeth: add notmuch-show-delete keybinding 'd' www: http://github.com/spaetz/notmuch-all-feature git: git://github.com/spaetz/notmuch-all-feature.git Sebastian ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: Git feature branch 2010-01-20 14:00 Git feature branch Sebastian Spaeth @ 2010-01-20 20:00 ` micah anderson 2010-01-22 8:09 ` Sebastian Spaeth 0 siblings, 1 reply; 29+ messages in thread From: micah anderson @ 2010-01-20 20:00 UTC (permalink / raw) To: Sebastian Spaeth, Notmuch development list [-- Attachment #1: Type: text/plain, Size: 723 bytes --] On Wed, 20 Jan 2010 15:00:46 +0100, "Sebastian Spaeth" <Sebastian@SSpaeth.de> wrote: > As I do like some of the additional patches, I am shoving some of them > into my "all feature" branch. I make that one available in case you > want to pull from it. It currently carries: > > Jameson Rollins: Simplify "unread" tag handling in emacs UI. > David Bremner: notmuch.el: Refactor citation markup. Variables for minimum size, button text. > Dirk-Jan C. Binnema: notmuch-new.c: refactor and improve dirs-to-ignore a bit > Sebastian Spaeth: add notmuch-show-delete keybinding 'd' Cool! It would be useful if you provided thread-id's for each of these so we could look them up and read more about them. micah [-- Attachment #2: Type: application/pgp-signature, Size: 835 bytes --] ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: Git feature branch 2010-01-20 20:00 ` micah anderson @ 2010-01-22 8:09 ` Sebastian Spaeth 2010-01-22 8:50 ` Sebastian Spaeth 0 siblings, 1 reply; 29+ messages in thread From: Sebastian Spaeth @ 2010-01-22 8:09 UTC (permalink / raw) Cc: Notmuch development list On 01/20/10 21:00, micah anderson wrote: > Cool! It would be useful if you provided thread-id's for each of these > so we could look them up and read more about them. True, I'll try to include thread id-s in the future. spaetz ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: Git feature branch 2010-01-22 8:09 ` Sebastian Spaeth @ 2010-01-22 8:50 ` Sebastian Spaeth 2010-01-22 21:10 ` Carl Worth 0 siblings, 1 reply; 29+ messages in thread From: Sebastian Spaeth @ 2010-01-22 8:50 UTC (permalink / raw) Cc: Notmuch development list On Fri, 22 Jan 2010 09:09:30 +0100, Sebastian Spaeth <Sebastian@SSpaeth.de> wrote: > On 01/20/10 21:00, micah anderson wrote: > > > Cool! It would be useful if you provided thread-id's for each of these > > so we could look them up and read more about them. > > True, I'll try to include thread id-s in the future. I have now listed all patches that I have added to my feature-branch here. Where possible I have added mail id or the git source that i have pulled from. The list is here: http://trac.sspaeth.de/issue?@columns=title,status&@filter=status&status=6 Stuff that I carry: - simplify "unread" tag handling in emacs UI - refactor and improve dirs-to-ignore a bit - Have notmuch count default to showing the total - add a submap (on "z" for "ztash") to stash things - When adding new messages, if they have the 'S' (seen) flag, do not add them to the 'unread' tag. - 'd' should "delete" a mail My feature-branch is still located here: http://github.com/spaetz/notmuch-all-feature So far things work fine for me. It would be cool if Carl would merge (parts of?) it. spaetz ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: Git feature branch 2010-01-22 8:50 ` Sebastian Spaeth @ 2010-01-22 21:10 ` Carl Worth 2010-01-25 21:32 ` martin f krafft 0 siblings, 1 reply; 29+ messages in thread From: Carl Worth @ 2010-01-22 21:10 UTC (permalink / raw) To: Sebastian Spaeth; +Cc: Notmuch development list [-- Attachment #1: Type: text/plain, Size: 1121 bytes --] On Fri, 22 Jan 2010 09:50:51 +0100, "Sebastian Spaeth" <Sebastian@SSpaeth.de> wrote: > My feature-branch is still located here: > http://github.com/spaetz/notmuch-all-feature > > So far things work fine for me. It would be cool if Carl would merge > (parts of?) it. Very much appreciated! Thanks for putting this together and publishing it. And I do apologize that my branch has been so stagnant lately. We've just completed a fabulous linux.conf.au. This included lots of hallway discussion of Notmuch, a Notmuch BOF, and a Notmuch lightning talk, but not much of a chance to sit and review/merge the backlog of patches. Oh, but we did succeed at getting a notmuch Debian package uploaded, (and there's now a "debian" branch in my repository which I pulled from the master branch of the shared notmuch repository on alioth). 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. -Carl [-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --] ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: Git feature branch 2010-01-22 21:10 ` Carl Worth @ 2010-01-25 21:32 ` martin f krafft 2010-01-26 0:46 ` sebastian 2010-02-04 3:05 ` Git feature branch Carl Worth 0 siblings, 2 replies; 29+ messages in thread From: martin f krafft @ 2010-01-25 21:32 UTC (permalink / raw) To: notmuch [-- Attachment #1: Type: text/plain, Size: 2066 bytes --] 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 [-- Attachment #2: Digital signature (see http://martin-krafft.net/gpg/) --] [-- Type: application/pgp-signature, Size: 198 bytes --] ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: Git feature branch 2010-01-25 21:32 ` martin f krafft @ 2010-01-26 0:46 ` sebastian 2010-01-26 22:24 ` micah anderson 2010-02-04 3:05 ` Git feature branch Carl Worth 1 sibling, 1 reply; 29+ messages in thread From: sebastian @ 2010-01-26 0:46 UTC (permalink / raw) To: notmuch > 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. Any of those sounds fine to me, really. No preferences. I have little experience with git, so I can't comment on the hierarchy of branches. Cherry-picking all those patches "up" does sound like it needs some dedicated attention though... > Sebastian, would it make sense to migrate your work into a 'pu' > branch? Not sure. My feature branch is basically just the branch I use and I have ecclectically been adding patches that seemed useful to me and ignored others I was not so sure about. I have no clue if Carl would want those features/patches in master, but if yes he is free to pull it into an unstable branch or however we want to name it. > 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]? Personally, I like how patchwork complements mailing lists for collecting patches, so a patchwork-supported mailing list would work well for me. I have less experience with the Debian bug tracker, not sure if a 'downstream' project can simply use it (but you would know that :-)). I wouldn't mind to have my roundup used, but it should probably be on some more officially-looking URL, rather than on a random personal webspace, shouldn't it? All I know is that there is a great momentum behind notmuch at the moment, and it would be great to not lose that. Sebastian ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: Git feature branch 2010-01-26 0:46 ` sebastian @ 2010-01-26 22:24 ` micah anderson 2010-01-27 19:17 ` Ben Gamari ` (2 more replies) 0 siblings, 3 replies; 29+ messages in thread From: micah anderson @ 2010-01-26 22:24 UTC (permalink / raw) To: sebastian, notmuch [-- Attachment #1: Type: text/plain, Size: 1817 bytes --] On Mon, 25 Jan 2010 16:46:43 -0800, sebastian@sspaeth.de wrote: > > 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 too prefer to stay away from commercial,non-free services like GitHub. Gitorious (http://www.gitorious.org/) is a great service, similar to Github, but with added freedom. Currently the git repository is at git://notmuchmail.org/git/notmuch which seems like a fine location for it, but perhaps I missed the motivation for switching to a centralized repository with the added overhead of giving people access to commit? Couldn't all of this be done without moving the existing git repository (don't forget that transition is a cost)? Those who wish to put together these proposed branches go ahead and do so, publishing those wherever they like (git.debian.org, gitorious, their own hosted git repositories, or even github) and then Carl can just add those as remotes as he sees fit. > > 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]? Personally, I've found mailing lists that have patches sent to them tends to totally kill the list for anything else. It seems a bit weird to use Debian's bug tracker for a non-Debian native program (but using it for the Debian package of notmuch does make sense). I am not so familiar with Roundup, patch queue trackers or patchwork to have anything to say about those. micah [-- Attachment #2: Type: application/pgp-signature, Size: 835 bytes --] ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: Git feature branch 2010-01-26 22:24 ` micah anderson @ 2010-01-27 19:17 ` Ben Gamari 2010-02-24 18:58 ` Carl Worth 2010-01-27 19:19 ` Jameson Rollins 2010-01-27 19:41 ` martin f krafft 2 siblings, 1 reply; 29+ messages in thread From: Ben Gamari @ 2010-01-27 19:17 UTC (permalink / raw) To: notmuch Excerpts from micah anderson's message of Tue Jan 26 17:24:15 -0500 2010: > On Mon, 25 Jan 2010 16:46:43 -0800, sebastian@sspaeth.de wrote: > > > 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 too prefer to stay away from commercial,non-free services like GitHub. > Gitorious (http://www.gitorious.org/) is a great service, similar to > Github, but with added freedom. > > Currently the git repository is at git://notmuchmail.org/git/notmuch > which seems like a fine location for it, but perhaps I missed the > motivation for switching to a centralized repository with the added > overhead of giving people access to commit? > > Couldn't all of this be done without moving the existing git repository > (don't forget that transition is a cost)? Those who wish to put together > these proposed branches go ahead and do so, publishing those wherever > they like (git.debian.org, gitorious, their own hosted git repositories, > or even github) and then Carl can just add those as remotes as he sees > fit. > I agree. There is no good reason to switch away from the existing infrastructure. If he wants, Carl can give regular contributors their own repositories on notmuchmail.org if some people have difficulties providing it themselves. After all, this is one of the strengths of distributed version control. - Ben ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: Git feature branch 2010-01-27 19:17 ` Ben Gamari @ 2010-02-24 18:58 ` Carl Worth 0 siblings, 0 replies; 29+ messages in thread From: Carl Worth @ 2010-02-24 18:58 UTC (permalink / raw) To: Ben Gamari, notmuch [-- Attachment #1: Type: text/plain, Size: 692 bytes --] On Wed, 27 Jan 2010 14:17:39 -0500, Ben Gamari <bgamari@gmail.com> wrote: > I agree. There is no good reason to switch away from the existing > infrastructure. If he wants, Carl can give regular contributors their > own repositories on notmuchmail.org if some people have difficulties > providing it themselves. After all, this is one of the strengths of > distributed version control. I should emphasize that point: I think it's great that people are posting their own notmuch repositories wherever they see fit. Please continue doing that. Also, if anybody would like to host such a repository on the notmuchmail.org server, I'm more than happy to arrange that. Just let me know. -Carl [-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --] ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: Git feature branch 2010-01-26 22:24 ` micah anderson 2010-01-27 19:17 ` Ben Gamari @ 2010-01-27 19:19 ` Jameson Rollins 2010-01-27 19:41 ` martin f krafft 2 siblings, 0 replies; 29+ messages in thread From: Jameson Rollins @ 2010-01-27 19:19 UTC (permalink / raw) To: micah anderson, sebastian, notmuch [-- Attachment #1: Type: text/plain, Size: 958 bytes --] On Wed, 27 Jan 2010 11:24:15 +1300, micah anderson <micah@riseup.net> wrote: > Couldn't all of this be done without moving the existing git repository > (don't forget that transition is a cost)? Those who wish to put together > these proposed branches go ahead and do so, publishing those wherever > they like (git.debian.org, gitorious, their own hosted git repositories, > or even github) and then Carl can just add those as remotes as he sees > fit. I second this idea. I've been working on quite a few projects that work in this way, with nothing but personal distributed repos, and it works quite well. Especially if Carl is going to continue to be benevolent dictator (as I agree that he should). Everyone who has patches can just post them to their personal repos, making sure that they're well rebased to Carl's master, and Carl can just pull from them as he sees fit. It's what git is designed to do, and it actually works really well. jamie. [-- Attachment #2: Type: application/pgp-signature, Size: 835 bytes --] ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: Git feature branch 2010-01-26 22:24 ` micah anderson 2010-01-27 19:17 ` Ben Gamari 2010-01-27 19:19 ` Jameson Rollins @ 2010-01-27 19:41 ` martin f krafft 2010-01-28 7:05 ` James Rowe 2 siblings, 1 reply; 29+ messages in thread From: martin f krafft @ 2010-01-27 19:41 UTC (permalink / raw) To: notmuch [-- Attachment #1: Type: text/plain, Size: 1941 bytes --] also sprach micah anderson <micah@riseup.net> [2010.01.27.1124 +1300]: > Couldn't all of this be done without moving the existing git > repository (don't forget that transition is a cost)? Those who > wish to put together these proposed branches go ahead and do so, > publishing those wherever they like (git.debian.org, gitorious, > their own hosted git repositories, or even github) and then Carl > can just add those as remotes as he sees fit. I brought this up, so I should make the motivation explicit: I just tried to relieve Carl from the burden of bottleneck. Since passing out SSH accounts on his own machine does not really scale, I looked elsewhere. However, I agree that the easiest solution is just to add more users. Potentially, Carl can make use of gitolite, I can investigate that some time this week. > Personally, I've found mailing lists that have patches sent to > them tends to totally kill the list for anything else. It seems > a bit weird to use Debian's bug tracker for a non-Debian native > program (but using it for the Debian package of notmuch does make > sense). I am not so familiar with Roundup, patch queue trackers or > patchwork to have anything to say about those. patchwork integrates with the mailing list and slurps patches and related discussion and threads them into a webpage, where they can be workflow-managed. The Debian bug tracker has the benefit of being usable with e-mail (and this is notmuch we're developing, don't forget). The others are all exclusively web-based, with the exception of launchpad, AFAIK. The idea of having a tracker is quite simply to make it easier for Carl to stay on top, and for e.g. you and I to assist him by vetting patches in our free minutes. -- martin | http://madduck.net/ | http://two.sentenc.es/ there's an old proverb that says just about whatever you want it to. spamtraps: madduck.bogus@madduck.net [-- Attachment #2: Digital signature (see http://martin-krafft.net/gpg/) --] [-- Type: application/pgp-signature, Size: 198 bytes --] ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: Git feature branch 2010-01-27 19:41 ` martin f krafft @ 2010-01-28 7:05 ` James Rowe 2010-02-01 22:31 ` patchwork test instance (was: Git feature branch) martin f krafft 0 siblings, 1 reply; 29+ messages in thread From: James Rowe @ 2010-01-28 7:05 UTC (permalink / raw) To: notmuch [-- Attachment #1: Type: text/plain, Size: 2270 bytes --] * martin f krafft (madduck@madduck.net) wrote: > also sprach micah anderson <micah@riseup.net> [2010.01.27.1124 +1300]: > > Personally, I've found mailing lists that have patches sent to > > them tends to totally kill the list for anything else. It seems > > a bit weird to use Debian's bug tracker for a non-Debian native > > program (but using it for the Debian package of notmuch does make > > sense). I am not so familiar with Roundup, patch queue trackers or > > patchwork to have anything to say about those. > > patchwork integrates with the mailing list and slurps patches and > related discussion and threads them into a webpage, where they can > be workflow-managed. > > The Debian bug tracker has the benefit of being usable with e-mail > (and this is notmuch we're developing, don't forget). The others are > all exclusively web-based, with the exception of launchpad, AFAIK. As I use some of the other options... Roundup has command line and email interfaces. The email interface is quite similar to debian's. I've never used a launchpad hosted project so I can't compare it. Google's codereview tool has a nice interface for collecting and commenting on patches, but I suspect that suggestion will also meet with a degree of friction. To me codereview feels like patchwork with polish. Both gitorious and github have commenting functionality built in. Commenting on commits in a fork is as easy as opening the commit in a browser. I use something along the lines of the following script to open commits on github: #! /bin/sh BASE=$(git config remote.${2:-origin}.url | sed 's,git\(@\|://\)\([^:/]*\)[:/]\(.*\).git,http://\2/\3/commit,') COMMIT=$(git rev-parse ${1:-HEAD}) sensible-browser ${BASE}/${COMMIT} Using github or gitorious you can easily find and track forks from one place as well, which makes discovering new work much easier. Github even provides a pretty single page interface to the work going on in other forks, gitorious requires a little more leg work to do the same but not much. For a couple of hosted projects we use at the office we email the individual entries from http://github.com/$user/$project/comments.atom to the mailing list so they're /forcibly/ seen by everybody :) Thanks, James [-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --] ^ permalink raw reply [flat|nested] 29+ messages in thread
* patchwork test instance (was: Git feature branch) 2010-01-28 7:05 ` James Rowe @ 2010-02-01 22:31 ` martin f krafft 2010-02-02 11:38 ` Marten Veldthuis 2010-02-10 3:25 ` patchwork test instance martin f krafft 0 siblings, 2 replies; 29+ messages in thread From: martin f krafft @ 2010-02-01 22:31 UTC (permalink / raw) To: notmuch [-- Attachment #1: Type: text/plain, Size: 3945 bytes --] I investigated some patch/issue trackers over the weekend. Here's my summary/reply. The executive summary is that http://patchwork.madduck.net/project/notmuch/list/ now exists. I have not really used it for anything real, so if some of you feel inclined to give it a shot, sign up and triage away! Feedback welcome. also sprach James Rowe <jnrowe@gmail.com> [2010.01.28.2005 +1300]: > Roundup has command line and email interfaces. The email interface is > quite similar to debian's. I've never used a launchpad hosted project > so I can't compare it. Roundup is an issue tracker, while Patchwork is a patch tracker. They are fundamentally distinct, but there are overlaps. What led me to go the Patchwork-path is that projects like the kernel and Git don't use issue trackers but work entirely patch-based. I don't know if that is the right way to do things, but having an issue tracker that fills up with bugs and wishlist items lacking patches is no better in the long run than not having an issue tracker. Arguably, being patch-centric means that a project has a higher barrier of entry, but it also means that if someone wants something, they know that they'll have to somehow end up with a patch. The way this happens on Git is that you either write it yourself and bring it up to discussion (which is what patchwork facilitates), or constructively theorise the functionality until someone else submits a patch. > Google's codereview tool has a nice interface for collecting and > commenting on patches, but I suspect that suggestion will also meet with > a degree of friction. To me codereview feels like patchwork with > polish. Maybe you could take some ideas from codereview and inform the patchwork people about them? > Both gitorious and github have commenting functionality built in. > Commenting on commits in a fork is as easy as opening the commit in > a browser. I use something along the lines of the following script to > open commits on github: > > #! /bin/sh > BASE=$(git config remote.${2:-origin}.url | sed 's,git\(@\|://\)\([^:/]*\)[:/]\(.*\).git,http://\2/\3/commit,') > COMMIT=$(git rev-parse ${1:-HEAD}) > sensible-browser ${BASE}/${COMMIT} > > Using github or gitorious you can easily find and track forks from one > place as well, which makes discovering new work much easier. Github > even provides a pretty single page interface to the work going on in > other forks, gitorious requires a little more leg work to do the same > but not much. Git now has commit notes, but it doesn't seem like that's integrated with Github/Gitorious. Mind you, patchwork isn't integrated at all with Git. It should be possible to set it up to automatically flag patches that are accepted into mainline, next, or pu. The benefit of patchwork is that discussion isn't moved to the web, but patchwork hooks into the mailing list, so discussion can stay where it should IMHO be. > For a couple of hosted projects we use at the office we email the > individual entries from http://github.com/$user/$project/comments.atom > to the mailing list so they're /forcibly/ seen by everybody :) Right, but replying requires them to open a browser and be online at the time, right? Anyway, I suggest we give patchwork a try. It occurs to me that notmuch can pretty much do all of what patchwork is doing — after all, it's just tagging patches/threads, but until we have synchronisable tags and a mailing list archive based on notmuch (which could then replace patchwork), I think we'll need to employ a third tool. -- martin | http://madduck.net/ | http://two.sentenc.es/ "what's your conceptual continuity? -- well, it should be easy to see: the crux of the bisquit is the apopstrophe!" -- frank zappa spamtraps: madduck.bogus@madduck.net [-- Attachment #2: Digital signature (see http://martin-krafft.net/gpg/) --] [-- Type: application/pgp-signature, Size: 198 bytes --] ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: patchwork test instance (was: Git feature branch) 2010-02-01 22:31 ` patchwork test instance (was: Git feature branch) martin f krafft @ 2010-02-02 11:38 ` Marten Veldthuis 2010-02-10 3:25 ` patchwork test instance martin f krafft 1 sibling, 0 replies; 29+ messages in thread From: Marten Veldthuis @ 2010-02-02 11:38 UTC (permalink / raw) To: martin f krafft, notmuch On Tue, 2 Feb 2010 11:31:12 +1300, martin f krafft <madduck@madduck.net> wrote: > Arguably, being patch-centric means that a project has a higher > barrier of entry, but it also means that if someone wants something, > they know that they'll have to somehow end up with a patch. The way > this happens on Git is that you either write it yourself and bring > it up to discussion (which is what patchwork facilitates), or > constructively theorise the functionality until someone else > submits a patch. And don't forget, if you really want something on the longterm todo list, you can always send in a patch for the TODO file. ;) -- - Marten ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: patchwork test instance 2010-02-01 22:31 ` patchwork test instance (was: Git feature branch) martin f krafft 2010-02-02 11:38 ` Marten Veldthuis @ 2010-02-10 3:25 ` martin f krafft 2010-02-10 8:49 ` David Bremner 2010-02-10 9:25 ` Sebastian Spaeth 1 sibling, 2 replies; 29+ messages in thread From: martin f krafft @ 2010-02-10 3:25 UTC (permalink / raw) To: notmuch [-- Attachment #1: Type: text/plain, Size: 835 bytes --] also sprach martin f krafft <madduck@madduck.net> [2010.02.02.1131 +1300]: > I investigated some patch/issue trackers over the weekend. Here's my > summary/reply. > > The executive summary is that > http://patchwork.madduck.net/project/notmuch/list/ now exists. > I have not really used it for anything real, so if some of you feel > inclined to give it a shot, sign up and triage away! Feedback > welcome. Are people actually using it? I know that merging patches is impossible, and that sucks, but otherwise: is this something to keep around, or should I take the site offline again? -- martin | http://madduck.net/ | http://two.sentenc.es/ "time flies like an arrow. fruit flies like a banana." -- groucho marx spamtraps: madduck.bogus@madduck.net [-- Attachment #2: Digital signature (see http://martin-krafft.net/gpg/) --] [-- Type: application/pgp-signature, Size: 198 bytes --] ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: patchwork test instance 2010-02-10 3:25 ` patchwork test instance martin f krafft @ 2010-02-10 8:49 ` David Bremner 2010-02-10 22:00 ` martin f krafft 2010-02-10 9:25 ` Sebastian Spaeth 1 sibling, 1 reply; 29+ messages in thread From: David Bremner @ 2010-02-10 8:49 UTC (permalink / raw) To: martin f krafft, notmuch On Wed, 10 Feb 2010 16:25:03 +1300, martin f krafft <madduck@madduck.net> wrote: > > Are people actually using it? I know that merging patches is > impossible, and that sucks, but otherwise: is this something to keep > around, or should I take the site offline again? I'm not sure what merging patches means here; some kind of squash operation? Anyway it seemed to me that every every patch series that I looked at was broken into individual patches. Maybe I am just unlucky, or does patchwork really not understand the concept of series of patches in a thread? d ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: patchwork test instance 2010-02-10 8:49 ` David Bremner @ 2010-02-10 22:00 ` martin f krafft 0 siblings, 0 replies; 29+ messages in thread From: martin f krafft @ 2010-02-10 22:00 UTC (permalink / raw) To: David Bremner; +Cc: notmuch also sprach David Bremner <bremner@unb.ca> [2010.02.10.2149 +1300]: > I'm not sure what merging patches means here; some kind of squash > operation? Anyway it seemed to me that every every patch series > that I looked at was broken into individual patches. Maybe I am > just unlucky, or does patchwork really not understand the concept > of series of patches in a thread? I don't think it does, this is what bundles are for, but these need to be created manually at the moment. Patch series are pretty easy to detect, so maybe the bundle could be automatically generated. http://lists.ozlabs.org/pipermail/patchwork/2010-February/000226.html -- martin | http://madduck.net/ | http://two.sentenc.es/ because light travels faster than sound, some people appear to be intelligent, until you hear them speak. spamtraps: madduck.bogus@madduck.net ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: patchwork test instance 2010-02-10 3:25 ` patchwork test instance martin f krafft 2010-02-10 8:49 ` David Bremner @ 2010-02-10 9:25 ` Sebastian Spaeth 2010-02-10 22:22 ` martin f krafft 2010-02-24 19:08 ` Carl Worth 1 sibling, 2 replies; 29+ messages in thread From: Sebastian Spaeth @ 2010-02-10 9:25 UTC (permalink / raw) To: notmuch On Wed, 10 Feb 2010 16:25:03 +1300, martin f krafft <madduck@madduck.net> wrote: > > http://patchwork.madduck.net/project/notmuch/list/ now exists. > > Are people actually using it? I know that merging patches is > impossible, and that sucks, but otherwise: is this something to keep > around, or should I take the site offline again? As long as patches aren't being marked as "rejected" or "superseded", I don't think it will be that useful in the long run. If it were actually maintained by a few people, this would probably be different. The alternative I can see is that we create a web page of patches based on carls notmuch tags (the tagging scheme he uses is unknown to me though). Something like: "notmuch dump tag:notmuch and tag:patch" could be used to construct a list of "accepted", "willnottakeit","superseded" and "pending" lists or whatever. If that list were made accessible somewhere, this would be super useful. At least it would help me see whether Carl just hasn't gotten around to including my "press 'd' for delete" patch or whether he is not interested in merging it. :) Sebastian ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: patchwork test instance 2010-02-10 9:25 ` Sebastian Spaeth @ 2010-02-10 22:22 ` martin f krafft 2010-02-24 19:10 ` Carl Worth 2010-02-24 19:08 ` Carl Worth 1 sibling, 1 reply; 29+ messages in thread From: martin f krafft @ 2010-02-10 22:22 UTC (permalink / raw) To: Sebastian Spaeth; +Cc: notmuch also sprach Sebastian Spaeth <Sebastian@SSpaeth.de> [2010.02.10.2225 +1300]: > "notmuch dump tag:notmuch and tag:patch" could be used to construct a > list of "accepted", "willnottakeit","superseded" and "pending" lists or > whatever. If that list were made accessible somewhere, this would be > super useful. At least it would help me see whether Carl just hasn't > gotten around to including my "press 'd' for delete" patch or whether he > is not interested in merging it. :) Carl, would you consider bouncing messages to addresses like patchwork+rejected@patchwork.notmuchmail.org? That would make it trivial for me to write glue to update patchwork automatically. -- martin | http://madduck.net/ | http://two.sentenc.es/ "es ist gut, eine sache doppelt auszudrücken und ihr einen rechten und linken fuß zu geben. auf einem bein kann die wahrheit zwar stehen; mit zweien aber wird sie gehen und herumkommen." -- friedrich nietzsche spamtraps: madduck.bogus@madduck.net ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: patchwork test instance 2010-02-10 22:22 ` martin f krafft @ 2010-02-24 19:10 ` Carl Worth 2010-02-24 20:39 ` martin f krafft 0 siblings, 1 reply; 29+ messages in thread From: Carl Worth @ 2010-02-24 19:10 UTC (permalink / raw) To: martin f krafft, Sebastian Spaeth; +Cc: notmuch [-- Attachment #1: Type: text/plain, Size: 588 bytes --] On Thu, 11 Feb 2010 11:22:16 +1300, martin f krafft <madduck@madduck.net> wrote: > Carl, would you consider bouncing messages to addresses like > patchwork+rejected@patchwork.notmuchmail.org? That would make it > trivial for me to write glue to update patchwork automatically. Now you're talking my language, Martin! I'm disinclined to go to a web browser, find the right buttons and push them, but it's easy for me to add an extra address when declining a patch, (since I have to write that email message already and I can even just add a keybinding to add the extra address). -Carl [-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --] ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: patchwork test instance 2010-02-24 19:10 ` Carl Worth @ 2010-02-24 20:39 ` martin f krafft 0 siblings, 0 replies; 29+ messages in thread From: martin f krafft @ 2010-02-24 20:39 UTC (permalink / raw) To: Carl Worth; +Cc: notmuch [-- Attachment #1: Type: text/plain, Size: 1255 bytes --] also sprach Carl Worth <cworth@cworth.org> [2010.02.24.2010 +0100]: > > Carl, would you consider bouncing messages to addresses like > > patchwork+rejected@patchwork.notmuchmail.org? That would make it > > trivial for me to write glue to update patchwork automatically. > > Now you're talking my language, Martin! > > I'm disinclined to go to a web browser, find the right buttons and > push them, but it's easy for me to add an extra address when > declining a patch, (since I have to write that email message > already and I can even just add a keybinding to add the extra > address). This is trivial to implement, but I don't see myself able to do that anytime soon. The basic idea is the same as the Git hook[0], and if someone wanted to take a shot, I'd be happy to create an account on the machine hosting the patchwork instance. 0. http://lists.ozlabs.org/pipermail/patchwork/2010-February/000224.html -- martin | http://madduck.net/ | http://two.sentenc.es/ "most people become bankrupt through having invested too heavily in the prose of life. to have ruined one's self over poetry is an honour." -- oscar wilde spamtraps: madduck.bogus@madduck.net [-- Attachment #2: Digital signature (see http://martin-krafft.net/gpg/) --] [-- Type: application/pgp-signature, Size: 198 bytes --] ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: patchwork test instance 2010-02-10 9:25 ` Sebastian Spaeth 2010-02-10 22:22 ` martin f krafft @ 2010-02-24 19:08 ` Carl Worth 2010-02-25 8:06 ` martin f krafft 1 sibling, 1 reply; 29+ messages in thread From: Carl Worth @ 2010-02-24 19:08 UTC (permalink / raw) To: Sebastian Spaeth, notmuch [-- Attachment #1: Type: text/plain, Size: 1491 bytes --] On Wed, 10 Feb 2010 10:25:49 +0100, "Sebastian Spaeth" <Sebastian@SSpaeth.de> wrote: > On Wed, 10 Feb 2010 16:25:03 +1300, martin f krafft <madduck@madduck.net> wrote: > > > http://patchwork.madduck.net/project/notmuch/list/ now exists. And even as http://patchwork.notmuchmail.org now. > As long as patches aren't being marked as "rejected" or "superseded", I > don't think it will be that useful in the long run. If it were actually > maintained by a few people, this would probably be different. I agree that in its current form it's not useful, (it seems to be just a long list of the patches that have ever been submitted). I seem to recall Martin saying that patches that get accepted will be automatically detected and removed from the list. Is that successfully happening now? > The alternative I can see is that we create a web page of patches based > on carls notmuch tags (the tagging scheme he uses is unknown to me > though). At this point, and with the JSON support in place, I think it should be trivial for someone to write a script that will take a notmuch search specification and create an HTML view of all the threads matching that search, right? If so, I'd be happy to regularly post the results of my notmuch todo list, which, by the way, is currently: notmuch search tag:todo-notmuch or (tag:notmuch and (tag:todo or tag:inbox)) In the meantime, if someone does want to push some buttons in patchwork, nothing before 2009-12-01 at least is interesting. -Carl [-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --] ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: patchwork test instance 2010-02-24 19:08 ` Carl Worth @ 2010-02-25 8:06 ` martin f krafft 0 siblings, 0 replies; 29+ messages in thread From: martin f krafft @ 2010-02-25 8:06 UTC (permalink / raw) To: Carl Worth; +Cc: notmuch [-- Attachment #1: Type: text/plain, Size: 829 bytes --] also sprach Carl Worth <cworth@cworth.org> [2010.02.24.2008 +0100]: > I agree that in its current form it's not useful, (it seems to be just a > long list of the patches that have ever been submitted). > > I seem to recall Martin saying that patches that get accepted will be > automatically detected and removed from the list. Is that successfully > happening now? Yes, I've automatically tagged approx. 140 patches "accepted" so far. > In the meantime, if someone does want to push some buttons in > patchwork, nothing before 2009-12-01 at least is interesting. Okay, all of those can be tagged superseeded. -- martin | http://madduck.net/ | http://two.sentenc.es/ kermit: why are there so many songs about rainbows? fozzy: that's part of what rainbows do. spamtraps: madduck.bogus@madduck.net [-- Attachment #2: Digital signature (see http://martin-krafft.net/gpg/) --] [-- Type: application/pgp-signature, Size: 198 bytes --] ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: Git feature branch 2010-01-25 21:32 ` martin f krafft 2010-01-26 0:46 ` sebastian @ 2010-02-04 3:05 ` Carl Worth 2010-02-04 3:50 ` martin f krafft 2010-02-04 3:58 ` Git feature branch Jameson Rollins 1 sibling, 2 replies; 29+ messages in thread From: Carl Worth @ 2010-02-04 3:05 UTC (permalink / raw) To: martin f krafft, notmuch [-- Attachment #1: Type: text/plain, Size: 3894 bytes --] On Tue, 26 Jan 2010 10:32:31 +1300, martin f krafft <madduck@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 [-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --] ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: Git feature branch 2010-02-04 3:05 ` Git feature branch Carl Worth @ 2010-02-04 3:50 ` martin f krafft 2010-02-05 3:36 ` patchwork now auto-updates patches from Git (was: Git feature branch) martin f krafft 2010-02-04 3:58 ` Git feature branch Jameson Rollins 1 sibling, 1 reply; 29+ messages in thread From: martin f krafft @ 2010-02-04 3:50 UTC (permalink / raw) To: Carl Worth; +Cc: notmuch [-- Attachment #1: Type: text/plain, Size: 8691 bytes --] also sprach Carl Worth <cworth@cworth.org> [2010.02.04.1605 +1300]: > > 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. I'll happily explain if you want. I think that this workflow, in combination with the distributed functionality of Git, makes for really powerful collaboration. To answer your two (implicit) questions directly: - as a user, you'd probably be tracking master, if you aren't running a stable release anyway. if you are ready to deal with the occasional bug and want some juicy stuff, go with next. if you are a developer ready to fend of the sh*t as it hits the fan, use pu. Basically, it's a bit like Debian testing/unstable/experiemental, except that the default entry point for new patches (packages in that analogy) is pu (experimental), not next (unstable, as it is in Debian). maint is then the stable branch, see below. - nothing is ever rebased. patches are cherry-picked downwards (pu→next→master) and branches are occasionally merged upwards (master into next, next into pu). I don't think we will need 'next' anytime soon, not until we have a situation where we are e.g. working on the next 1.x release by already have 2.0 on the horizon. The important distinction is between pu (proposed-updates) and master. The goal for master should always be that it's usable. Features that are too new to ensure that go to pu until they matured. > 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. :-) This is all possible to do. It has no impact on the pu/next/master distinction. Basically, once a release is made, master is merged into maint (I think) and tagged. If a maintenance release has to be made, a maint/1.0 branch is created. I don't think Git/Linux do that, but I do. > 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.] Do you want to maintain that branch yourself for your own purposes, or do you want to be the sole maintainer of the branch that is advertised as *the* notmuch branch, and from which future releases are made? > 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*. Actually, there is no reason for master to exist at all. ;) It's just the default, but it's not intrinsic. > 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. So you are talking repos, not branches. I know they are almost the same, but branches live in repos, and if you want to be the only person pushing to a branch, you need to be the only one with write access to the containing repo — unless you use gitolite, which can do in-repo per-branch access control. > > 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). The reason why I set up patchwork is because you might have spent hours triaging some patches already, e.g. bringing the count from 400 to 100. Since I cannot really "pull" your tags, I am forced to go through the entire list myself. > > 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. Absolutely. There are two comments I have: - this gets easier the closer we get to a centralised model, simply because patchwork is centralised. We *may* be able to use Git's new "notes" feature to attach workflow information to patches, but for that, patches have to become commits in the ancestry, so we need some way of pulling them off the list and into the ancestry. Simply slurping all patches into an 'all-patches' branch won't work due to merge conflicts, so it has to be a manual operation anyway. This then either happens centrally, or we have some sort of communication protocol to tell others which patches have been integrated into the ancestry. This is where patchwork could come in (again). - … which brings me to my second point: there are certain things that patchwork can do, at least in theory: * mark patches accepted when they hit your (canonical) master branch * mark patches rfc when they hit e.g. my (canonical) next branch * mark patches "under review" when they hit the all-patches (or pu) branch. I have not yet tried any of these, and I am basing this theory only on the idea that git-patch-id can come to the rescue, for there is no other linkage between the patch on the mailing list (and thus known to patchwork), and the commit in the repo. Given that * git-patch-id will fail if the patch is modified before it's applied to the ancestry, * git-patch-id might not work at all, and * there are status changes that cannot be deduced from Git (rejected, superseded, not applicable, changes requested, deferred), we might need some sort of protocol anyway. This could be either * a mail processor, in the style of the Debian bug control system, to which you send commands like 'status 1234 superseded', or * a policy specification using e.g. Git notes on commits, such that workflow changes could be attached to commits in a way that would let patchwork and humans follow what's going on. > Also interesting would be support for publishing my notmuch-based > queue of patches to a web page. Absolutely. As I said before, notmuch and tagging could pretty much render patchwork obsolete, but to do that, I /think/ we need to grow two features: - the ability to share tags, so that I don't have to manually track my own patch list, - a web archive with notmuch search/tag support. Simply publishing your workflow statuses would be an improvement, but I am unsure I can fully quantify the gain. In closing, I would like draw a parallel between commits, patches and mails: 1. notmuch deals with mails, and Git deals with commits 2. a commit can be turned into a patch and sent as a mail 3. notmuch can tag mails, Git can attach notes to commits 4. notes can be used to store tag-like information If we continue the road of sending patches to the mailing list (which I think is a good one, due to discussions and comments), then we inevitably need to link commits to mails, along with the associated metadata (tags, workflow status), in two ways. Fun times, -- martin | http://madduck.net/ | http://two.sentenc.es/ "of course the music is a great difficulty. you see, if one plays good music, people don't listen, and if one plays bad music people don't talk." -- oscar wilde spamtraps: madduck.bogus@madduck.net [-- Attachment #2: Digital signature (see http://martin-krafft.net/gpg/) --] [-- Type: application/pgp-signature, Size: 198 bytes --] ^ permalink raw reply [flat|nested] 29+ messages in thread
* patchwork now auto-updates patches from Git (was: Git feature branch) 2010-02-04 3:50 ` martin f krafft @ 2010-02-05 3:36 ` martin f krafft 0 siblings, 0 replies; 29+ messages in thread From: martin f krafft @ 2010-02-05 3:36 UTC (permalink / raw) To: Carl Worth, notmuch [-- Attachment #1: Type: text/plain, Size: 1547 bytes --] also sprach martin f krafft <madduck@madduck.net> [2010.02.04.1650 +1300]: > - … which brings me to my second point: there are certain things > that patchwork can do, at least in theory: > > * mark patches accepted when they hit your (canonical) master > branch > * mark patches rfc when they hit e.g. my (canonical) next branch > * mark patches "under review" when they hit the all-patches (or > pu) branch. > > I have not yet tried any of these, and I am basing this theory > only on the idea that git-patch-id can come to the rescue, for > there is no other linkage between the patch on the mailing list > (and thus known to patchwork), and the commit in the repo. Patchwork now marks patches Accepted once they hit Carl's master branch (up to 10 minutes delay due to Cron). It uses an algorithm similar (but not equal) to git-patch-id in that it hashes the diff. This means that the commit message can be amended when patches are applied/cherry-picked, but the patch itself must be verbatim. I ran it on all history thus far and it found 99 patches. It'll be trivial to set it up to mark other states when the corresponding commits hit another branch. Let me know if there are any problems, and feedback welcome. -- martin | http://madduck.net/ | http://two.sentenc.es/ "if they can get you asking the wrong questions, they don't have to worry about answers." -- thomas pynchon spamtraps: madduck.bogus@madduck.net [-- Attachment #2: Digital signature (see http://martin-krafft.net/gpg/) --] [-- Type: application/pgp-signature, Size: 198 bytes --] ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: Git feature branch 2010-02-04 3:05 ` Git feature branch Carl Worth 2010-02-04 3:50 ` martin f krafft @ 2010-02-04 3:58 ` Jameson Rollins 2010-02-24 19:13 ` Carl Worth 1 sibling, 1 reply; 29+ messages in thread From: Jameson Rollins @ 2010-02-04 3:58 UTC (permalink / raw) To: Carl Worth, martin f krafft, notmuch [-- Attachment #1: Type: text/plain, Size: 2214 bytes --] On Wed, 03 Feb 2010 19:05:42 -0800, Carl Worth <cworth@cworth.org> wrote: > 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.] Just my 2 cents here, but I fully support the idea of perusing a fully distributed development model. I have been using it on other projects I work on and it works great. > 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*. There's really no need to do that. For others developers, they would just add your repo as a "remote", which would presumably be named something like "cworth". Then in the developers repo your master branch would be named "cworth/master". With a crew of developers, A, B, C, etc., each one would add the others as remotes, and their branches would be visible under their remotes, ie: C@host:~$ git branch -a master foo bar remotes/A/master remotes/A/foo remotes/B/master remotes/B/foo ... > 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. I think this is the right idea. I think the problem we've been having recently is that we have bit of a patch backlog due to circumstances of Carl's travel. This is an issue because the project is new and people are eager to see their contributions in place. I'm sure Carl will get to them as fast as he can. Once the project becomes more mature and other developers are vetting patches, then their branches can take over as "master" in the absence of an outdated canonical master. jamie. [-- Attachment #2: Type: application/pgp-signature, Size: 835 bytes --] ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: Git feature branch 2010-02-04 3:58 ` Git feature branch Jameson Rollins @ 2010-02-24 19:13 ` Carl Worth 0 siblings, 0 replies; 29+ messages in thread From: Carl Worth @ 2010-02-24 19:13 UTC (permalink / raw) To: Jameson Rollins, martin f krafft, notmuch [-- Attachment #1: Type: text/plain, Size: 725 bytes --] On Wed, 03 Feb 2010 22:58:05 -0500, Jameson Rollins <jrollins@finestructure.net> wrote: > Once the project becomes more mature and other developers are > vetting patches, then their branches can take over as "master" in the > absence of an outdated canonical master. The other thing that will happen as the project matures is that I expect to start merging other people's carefully vetted and reviewed branches. This will happen as people start to take ownership of particular code areas and we establish mutual trust on taste, code review, testing, etc. I think that will be the real solution for future bottlenecks when I'm not available for much patch review due to travel, sickness, hectic-life-in-general, etc. -Carl [-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --] ^ permalink raw reply [flat|nested] 29+ messages in thread
end of thread, other threads:[~2010-02-25 8:06 UTC | newest] Thread overview: 29+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2010-01-20 14:00 Git feature branch Sebastian Spaeth 2010-01-20 20:00 ` micah anderson 2010-01-22 8:09 ` Sebastian Spaeth 2010-01-22 8:50 ` Sebastian Spaeth 2010-01-22 21:10 ` Carl Worth 2010-01-25 21:32 ` martin f krafft 2010-01-26 0:46 ` sebastian 2010-01-26 22:24 ` micah anderson 2010-01-27 19:17 ` Ben Gamari 2010-02-24 18:58 ` Carl Worth 2010-01-27 19:19 ` Jameson Rollins 2010-01-27 19:41 ` martin f krafft 2010-01-28 7:05 ` James Rowe 2010-02-01 22:31 ` patchwork test instance (was: Git feature branch) martin f krafft 2010-02-02 11:38 ` Marten Veldthuis 2010-02-10 3:25 ` patchwork test instance martin f krafft 2010-02-10 8:49 ` David Bremner 2010-02-10 22:00 ` martin f krafft 2010-02-10 9:25 ` Sebastian Spaeth 2010-02-10 22:22 ` martin f krafft 2010-02-24 19:10 ` Carl Worth 2010-02-24 20:39 ` martin f krafft 2010-02-24 19:08 ` Carl Worth 2010-02-25 8:06 ` martin f krafft 2010-02-04 3:05 ` Git feature branch Carl Worth 2010-02-04 3:50 ` martin f krafft 2010-02-05 3:36 ` patchwork now auto-updates patches from Git (was: Git feature branch) martin f krafft 2010-02-04 3:58 ` Git feature branch Jameson Rollins 2010-02-24 19:13 ` Carl Worth
Code repositories for project(s) associated with this public inbox https://yhetil.org/notmuch.git/ This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).