[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:04:50
Message-ID: 200912311304.50622.cbo () boemann ! dk
[Download RAW message or body]

I agree with Boudewijn. However just putting up for review isn't 
quite enough of a policy.

We also need to decide when the change can be commited. If no 
one has any objections it might go unanswered, slowing up the 
process, requiring a follow-up from the original poster. It will be 
very cumbersome.

On the other hand we can't say that one person can say ok 
either, because no one knows what happens in all apps.

I think it's best to say: if no one has objected within say 48 hours 
that it is ok to commit. This will cause a permanent 48 hour 
delay on all such changes but at least it has had fair hearing.

If a reviewer thinks he needs more time all he has to do is reply 
with a "I need until X hour to review it because it might cause 
me problems if commited"

best regards
Casper

On Thursday 31 December 2009 12:48:44 Boudewijn Rempt 
wrote:
> On Wednesday 30 December 2009, Thorsten Zachmann 
wrote:
> > Can changes like this, where stuff that also affects stuff 
outside of
> >  flake, please be discussed and put for review before being 
executed.
> > This would really improve the acceptance for such changes.
> 
> I agree with Thorsten that having review beforehand would be 
good, but
>  there is the problem that the review discussions tend become 
emotional. Of
>  course, with the commit-and-discuss afterwards model, 
discussions get
>  hardly less emotional. There aren't many people working on 
the libraries,
>  which makes adequate reviewing a problem, but we are all 
depending on the
>  libaries, so we really should try to keep track of what is 
happening in
>  there.
> 
> Add to that that we have at least two types of commits to the 
libraries:
> 
> * cleanup/refactoring to improve the quality of the library
> * feature additions to make the library actually useful for one 
or more
> KOffice applications.
> 
> I think refactoring/cleanup patces need to be put up for 
review, either on
> reviewboard (which is sucking more and more), or on the 
mailing list if
>  they are either big, or touch applications. (This is going to 
suck for me,
>  personally, since I've got a big pigment refactoring coming up 
and it's
>  already more than a dozen patches big, but if we agree on 
this, I'll clean
>  them up and submit for review.)
> 
> I also would like all of us to agree and putting up patches for 
review that
> add new features to the KOffice libraries, especially for 
libraries we are
> trying to make ready for third-party usage, like flake or koodf.
> 
_______________________________________________
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]