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

List:       kde-core-devel
Subject:    Re: KDE Trunk based on Qt 4.6
From:       Christoph Feck <christoph () maxiom ! de>
Date:       2009-08-30 19:52:48
Message-ID: 200908302152.49261.christoph () maxiom ! de
[Download RAW message or body]

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)

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