Is there anything we can do to help figure this out, kareila? I don't want to just spring this transition onto all the devs. I promise this isn't happening immediately; moving to a more branch-y model is something I'd like to encourage strongly, but I'd like to run through a proposed workflow using both git and mercurial first, so we can compare and contrast the two, before we make any final decision either way.
I do worry, though that major feature development on Dreamwidth has too many barriers the way we do it now. The review process through Zilla works for smaller patches, but breaks down a bit when we have:
a) bigger patches on major projects that need development over time; or b) patches that take multiple reviews and need multiple tweaking
In particular, with b), there's a stigma attached to the review- flag. It's perceived as a rejection of all that work, and hey I can sympathize with that *wry grin* It sucks to get that email and those comments, and reapplying the patch + tweaking + regenerating the new patch feels like starting from scratch. I hate to say it, but we've lost people over that. It contributes to general drift, and it's something I feel strongly about reversing.
Which is why I'm pushing for a more branch-like system. Based on what I've read, Git makes it easier to publish feature branches and merge them back into the main repository, without cloning to a new repository (which seems harder to juggle with cvsreport.pl. I'm not sure this will be an entirely moot point even once we get rid of the bulk of overlaid repositories; that's one of the things that needs to be settled).
I use MQ to manage my own patch queue, and it makes it easy, but by its temporary nature, it's hard to share it around, which doesn't help with transparency and encouraging feedback from other devs.
*but*, and very importantly, it looks like you've got things working quite well for you in Mercurial, and this is precisely the thing I'd like us to talk about: how you're making things work, and whether what works for you would be applicable to general development.
Bringing up one point specifically, have you looked into Git named branches in comparison to cloned repositories in Mercurial? I get the impression that the two are roughly the same, except that with Mercurial the feature development happens in a separate folder. This isn't a rhetorical question by the way! The way Mercurial and Git deal with branches seems to be one of the main big issues that will affect workflow, and it's among the things we need the most information about in terms of practical use.
no subject
I do worry, though that major feature development on Dreamwidth has too many barriers the way we do it now. The review process through Zilla works for smaller patches, but breaks down a bit when we have:
a) bigger patches on major projects that need development over time; or
b) patches that take multiple reviews and need multiple tweaking
In particular, with b), there's a stigma attached to the review- flag. It's perceived as a rejection of all that work, and hey I can sympathize with that *wry grin* It sucks to get that email and those comments, and reapplying the patch + tweaking + regenerating the new patch feels like starting from scratch. I hate to say it, but we've lost people over that. It contributes to general drift, and it's something I feel strongly about reversing.
Which is why I'm pushing for a more branch-like system. Based on what I've read, Git makes it easier to publish feature branches and merge them back into the main repository, without cloning to a new repository (which seems harder to juggle with cvsreport.pl. I'm not sure this will be an entirely moot point even once we get rid of the bulk of overlaid repositories; that's one of the things that needs to be settled).
I use MQ to manage my own patch queue, and it makes it easy, but by its temporary nature, it's hard to share it around, which doesn't help with transparency and encouraging feedback from other devs.
*but*, and very importantly, it looks like you've got things working quite well for you in Mercurial, and this is precisely the thing I'd like us to talk about: how you're making things work, and whether what works for you would be applicable to general development.
Bringing up one point specifically, have you looked into Git named branches in comparison to cloned repositories in Mercurial? I get the impression that the two are roughly the same, except that with Mercurial the feature development happens in a separate folder. This isn't a rhetorical question by the way! The way Mercurial and Git deal with branches seems to be one of the main big issues that will affect workflow, and it's among the things we need the most information about in terms of practical use.