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

List:       koffice-devel
Subject:    Re: Review policy proposal. Wat: Re: koffice
From:       "C. Boemann" <cbo () boemann ! dk>
Date:       2009-12-31 12:58:31
Message-ID: 200912311358.31185.cbo () boemann ! dk
[Download RAW message or body]

On Thursday 31 December 2009 13:30:50 Thomas Zander 
wrote:
> So, if people really want I can start posting all refactor patches 
here
>  first, but I'd like to know what others think; isn't this a bit 
overkill?
>  Will you help reviewing? Is it worth your time? (i.e. do you 
read all libs
>  patches on the svn commits ML?)
> I fear it will take all the joy out of the work for many here as it 
would
>  add an unrealistic bureaucratic overhead.
I usually look at those commits yes. Not to the point of checking 
the code works as intended or that it complies with coding style, 
but more on the overall impact.

I think that if we have a timeout period it will be manageable for 
all of us, to have a look.

more import I think that maybe we should have a pre-coding 
review as well or instead. Like a mail saying: I'd like to change 
these method names to this and that. Again with a timeout 
period. But this would prevent us from coding a lot only to have 
it rejected. This will lessen the emotional investment, and we 
might find it easier to accept a decline.

If we do have such a pre-coding review, then we might be able 
to only have post-commit reviews of actual changes? Commit 
message could then refer to the mail thread.

some changes (like bugfixes) would probably have to be coded 
before the poster would actually know what the change will 
consist of, but in that case, the patch could just be posted for 
review. Thus becoming a pre-commit review.

I also agree that it's hard to differentiate as to what changes 
have an impact and which don't. So I think it might be good to 
say: Everything should be reviewed. I'd hate it myself to have to 
go through this process for even simple fixes, but I also think it's 
needed.

best regards
Casper
_______________________________________________
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]