KDE Trunk based on Qt 4.6
Christoph Feck
christoph at maxiom.de
Sun Aug 30 20:52:48 BST 2009
Am Sunday 30 August 2009 21:19:48 schrieb 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
>
> [...] 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.
Many times? How many of the 1000000 KDE commits would you say were "bad"?
100? 1000? 10000? Even 10000 would be just 1%.
Could you imagine those 1000000 commits would have gone through a Merge
Request on that git website?
I cannot.
Yes, sometimes it is required to revert a commit. From the mere ~300 commits
that I did to KDE, I had to revert one after a post-commit review from
others.
Yes, I was even able to revert that myself after I got a simple "I would
suggest you revert that" message on IRC...
> Between, irc, email, paste websites, and the new review website
> there is little reason to not do some sort of review these days.
No problem here. I use all of those methods, and are fine with them. But
probably only for 10% of my commits.
Either you want Qt open to KDE developers, or you don't. I understand that you
seem to want to (you expressed that much often), but the door isn't open,
there isn't even an open window. It feels a bit like joining a birthday party
where you have to communicate with others via the mailbox...
There is much potential. Looking at http://gitorious.org/+kde-developers I see
a (small fraction of the) horde of willing developers who just wait for the
door to open fully.
But I don't see any of them appearing at the Merge Request list. I gave my
reason. Maybe others have different reasons.
I don't know.
Christoph Feck (kdepepo)
More information about the kde-core-devel
mailing list