Moving to git.kde.org open
mail at milianw.de
Thu Oct 28 11:18:23 UTC 2010
Andreas Pakulat, 27.10.2010:
> On 27.10.10 21:08:48, Milian Wolff wrote:
> > On Wednesday 27 October 2010 21:01:57 Niko Sams wrote:
> > > On Wed, Oct 27, 2010 at 20:33, Milian Wolff <mail at milianw.de> wrote:
> > > > On Wednesday 27 October 2010 19:53:29 Aleix Pol wrote:
> > > >> Does anybody have a clue about how can we move the merge requests?
> > > >
> > > > there is no such thing as a merge-request on the new architecture as
> > > > far as I understood.
> > >
> > > but there is reviewboard, I think that does more or less the same.
> > no, not at all. Reviewboard is nice for simple bug fixes and monolithic
> > patches for feature additions.
> > It does not cope well with the "develop a feature in a branch, then merge
> > it" workflow that git suggests and I came to love.
> But MR's didn't do anything to help you review a series of commits
> either or did I miss something? A MR (as far as I got to know it) was
> simply a dump of all changes done in the branch into a patch,
> reviewboard is supposed to supply that too.
You did miss something. And I'd even say you never used reviewboard.
1) in gitorious you could see the changes in each commit (as well as one big
diff for all commits in that request)
2) reviewboard (at least the svn version) did not allow you to post patches
that depend on each other. Only one patch that would get applied to current
trunk. If it did not apply, you where screwed. Esp. in cases like this:
commit #1: start new plugin $foo
commit #2: fix something in new file
the second could not be posted for review until the first one was in. Really
And you can get even insaner if you use e.g. git to create two or more patches
that touch a single file. You get into a state real easy that makes it
impossible to apply the plain patch of one of the later commits to the file.
> If you want to follow a features development in a branch then you either
> need to do that by updating a local clone of the branch regularly or
> somehow get commit-mails for the branch. I'm not sure wether the current
> plan for git.kde.org considered commit-mails for personal clones
> (which are supported, no group-clones though afaik).
It's not about following. It's about reviewing-as-soon-as-it's-supposed-to-be-
merged *and* making it as painless as possible for contributors to send
> Anyway, lets stop that here as Aleix said. Topic is about moving and
Sorry but this is an important topic for our project. How can we ignore it and
blindly hop over to something where we are not sure how the workflow is going
to be? As I said, manual reviews are possible but would mean we'd have to go
back to the email-area...
mail at milianw.de
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 198 bytes
Desc: This is a digitally signed message part.
More information about the KDevelop-devel