Moving to git.kde.org open
aleixpol at kde.org
Mon Nov 8 16:03:44 UTC 2010
On Fri, Oct 29, 2010 at 12:40 AM, Aleix Pol <aleixpol at kde.org> wrote:
> On Thu, Oct 28, 2010 at 7:29 PM, Milian Wolff <mail at milianw.de> wrote:
>> Andreas Pakulat, 28.10.2010:
>> > On 28.10.10 13:18:23, Milian Wolff wrote:
>> > > Andreas Pakulat, 27.10.2010:
>> > > > 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
>> > > 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...
>> > The problem is that there is basically no choice, unless you want to
>> > KDevelop a non-KDE app (i.e. completely loose the KDE eco-system as Sho
>> > explained on IRC). So wether we go back to mail-patches or reviewboard
>> > being used is not an important point (unless you want to work with the
>> > reviewboard devs on its improvement or on MR's for git.kde.org) for
>> > or not or when to move.
>> Andreas, I didn't say we should not move to git.kde.org - quite the
>> I just want us to have a clear migration path for our existing workflow.
>> requests are quite popular for us (imo) and we got lots of contributions
>> way. So we have to have an idea of what to tell poeple on how to
>> after the merge.
>> In my first mail I already explained one way this could work. It's
>> but it works. I just want to know whether there are alternatives and - as
>> said in my other mail - I cannot imagine we are the only project that used
>> be on gitorious which got contributions through merge requests. How are
>> doing that? The one doing the kdevelop migration should also look into
>> that's all I wanted to make sure...
>> Milian Wolff
>> mail at milianw.de
>> KDevelop-devel mailing list
>> KDevelop-devel at kdevelop.org
> Since I already was in the ReviewBoard mailing list since the last GSoC I
> sent them an e-mail asking how hard would be to add this feature (branch
> comparison). I'll get back to you when there's a response. I don't think we
> should stop the process because of that issue, anyway.
After using MR with Benjamin yesterday I came to the conclusion that we may
just ask the requesters to provide the branch they used to create the patch,
then provide it using "git diff master..devbranch", other than that, I think
reviewboard is more advanced than gitorious MR.
Just to say, I moved Kamoso last week and it was harmless, i think that we
could change repositories in few days lapse.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the KDevelop-devel