Moving to git.kde.org open

[Milian Wolff]

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

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

> Anyway, lets stop that here as Aleix said. Topic is about moving and
> when.

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

bye
-- 
Milian Wolff
mail at milianw.de
http://milianw.de
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kdevelop-devel/attachments/20101028/d3ec1991/attachment.sig>