[prev in list] [next in list] [prev in thread] [next in thread] 

List:       koffice-devel
Subject:    Re: Review Request: RDF support for KWord.
From:       Elvis Stansvik <elvstone () gmail ! com>
Date:       2010-02-11 11:55:11
Message-ID: 751a4f871002110355h2fec142cn781b669eb571e987 () mail ! gmail ! com
[Download RAW message or body]

2010/2/11 Jos van den Oever <Jos.van.den.Oever@kogmbh.com>:
> On Thursday 11 February 2010 12:38:54 Elvis Stansvik wrote:
>> 2010/2/11 Jos van den Oever <Jos.van.den.Oever@kogmbh.com>:
>> > On Thursday 11 February 2010 11:25:29 Thomas Zander wrote:
>> >> I'm fine with that approach.
>> >>
>> >> Thinking ahead, it would be good to avoid a lot of revisions in the
>> >> future by asking for feedback and approach *much* earlier in the
>> >> development cycle (the first patch was already huge).
>> >> I found an actual bug in this review cycle, one that we should have
>> >> caught earlier and probably would have if we had a smoother way of
>> >> reviewing. I still think that reviews are valuable, and we should
>> >> continue to do that. Lets try to work on the process to make it more
>> >> smooth for future versions.
>> >>
>> >> > As to the missing files, not sure what is up with them, but i'll vough
>> >> > for
>> >> >
>> >> >  the  quality.
>> >>
>> >> Its not vouching for quality, that kind of misses the point :)
>> >> Its about catching bugs early by having more people look at it. Its
>> >> about having an easier transfer of knowledge to more people in the
>> >> group. Which in itself is about sharing maintainership.
>> >>
>> >> But, yes, Jos, agreed, we've had 9 patch revisions, lets stop torturing
>> >> Ben and just aim for better approach next time.
>> >
>> > Yes, also when to use or not use reviewboard is not formalized. For new
>> > commtters it is expected and for large changes too. However for large
>> > changes the reviewboard does not work well, as shown by this long review
>> > instance.
>> >
>> > Once we switch to git, all of this should become much easier and at that
>> > point we can think about formalizing the reviewing some more.
>>
>> Sorry for a bit of a thread hijack, but I've been thinking about this;
>> when we move to git, I guess we will still use reviewboard? If so,
>> does anyone know if the latest version of reviewboard will eat git
>> diffs? If it does (and I think so), maybe we should bug whoever runs
>> reviewboard.kde.org to upgrade? Because it still won't accept git
>> diffs right?
>
> Gitorious has a way to request merges from branches that allows comments.
> When there are comments you change your branch and ask again. The revision
> history of the branch is also visible there.
>
> It works by doing a clone and then asking a merge. Here's an example:
> http://qt.gitorious.org/qt/qt/merge_requests/1623
>
>    *  Requested by:  avatar   Jos van den Oever
>    * Status: Merged
>    * Source repository: vandenoevers-clone:qtextformatpatch
>    * Target repository: qt:master
>    * Created at: September 26th, 2009 15:05
>
> It lists the commits in the cloned branch that would be merged as well as the
> comments and the revisions.

Great!

Elvis

>
> Cheers,
> Jos
>
>
> --
> Jos van den Oever, software architect
> +49 391 25 19 15 53
> http://kogmbh.com/legal/
> _______________________________________________
> koffice-devel mailing list
> koffice-devel@kde.org
> https://mail.kde.org/mailman/listinfo/koffice-devel
>
_______________________________________________
koffice-devel mailing list
koffice-devel@kde.org
https://mail.kde.org/mailman/listinfo/koffice-devel

[prev in list] [next in list] [prev in thread] [next in thread]