KDE Trunk based on Qt 4.6

[Benjamin Meyer]

On Aug 30, 2009, at 2:53 PM, Albert Astals Cid wrote:

> A Diumenge, 30 d'agost de 2009, Benjamin Meyer va escriure:
>> On Aug 30, 2009, at 12:14 PM, Christoph Feck wrote:
>>> Am Sunday 30 August 2009 17:13:14 schrieb Thiago Macieira:
>>>> Em Domingo 30. Agosto 2009, às 16.49.55, Christoph Feck escreveu:
>>>>> Ideally, I would just svn commit to qt-copy with a fix, add a BUG:
>>>>> or a
>>>>> QTISSUE: number, and request merging with upstream Qt using a
>>>>> QTMERGE
>>>>> tag. Done. It cannot get simpler. Post-commit review works.
>>>>
>>>> That's exactly what we're asking of you.
>>>>
>>>> Create the fix, commit it, push to Gitorious, then create an MR
>>>> saying
>>>> "here, I fixed the issue".
>>>
>>> No. Browsing KDE/Qt sources in the editor. Find a bug. Correct that.
>>> Hit save.
>>> Want to commit.
>>>
>>> For KDE sources I have to:
>>>
>>> 0. "svn up/diff" to be sure
>>> 1. "svn commit" with BUG: number
>>> 2. "svnbackport" if I want it in stable branch
>>> 3. go back to editor to look for the next file I could fix
>>
>> And then I revert your commit because it broke something that would
>> have been caught if you had bother to ask for a review from the guy
>> who maintains the code.
>
> That's both rude and off topic.
>
> Albert

It is very much on topic.  The major difference between the two  
methods is that the qt patch requires a review and a Qt dev does the  
commit.  Who commits a patch isn't that important, but leaving out the  
review step is a big deal.  I have seen many bad commits in kde that  
were pushed in by developers who were not the maintainers of the code  
they were modifying.  I myself even did it.  Just because you can push  
in a patch to nearly all of kde's svn without a code review doesn't  
mean you should.  This is a lesson that kde has learned many times  
over.  Between, irc, email, paste websites, and the new review website  
there is little reason to not do some sort of review these days.

-Benjamin Meyer