KDE Trunk based on Qt 4.6

[Olivier Goffart]

Le Sunday 30 August 2009, Christoph Feck a écrit :
> 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
>
> For Qt sources I have to:

Most of your points are either bad uses of git (that can be fixed by knowing 
more the tool, which will happen if kde eventually switch to git), or little 
bit of bad faith.

> 0. "git pull/diff" to be sure (pull will not work anyway, because of my
> change?)
> 1. create a local branch for my fix (despite that my sources are already
> local?)
> 2. switch to that branch (and wait for git to "make the switch")
> 3. somehow reapply the fix there (either in the editor by reloading
> the "changed" document, even if the branches do not differ or manually
> fixing it again)
> 4. hope i didn't mess up all the states of all my branches, origins, and
> repos and whatever git calls them (what again is the difference between git
> pull, git fetch, git rebase, git checkout?)
> 5. "git commit" with ISSUE: number (finally? no! more to come...)

make that in right order, and everything becomes clear.

0. first, create and switch to the branch  
$ git checkout -b my_fixes
(you can do it even with local change)

1. Then you can do  git diff  to see your change. And commit locally with 
$ git commit -a

2. Then the equivalent of svn up:
$ git fetch origin && git rebase origin/master

It's few more command than svn up/diff, but it does more as well.  Note that 
creating a new branch is not required (thought recommanded)

> 6. "git push" to my remote git repo

Yes, this would be the git equivalent of svn commit, that pushes the change to 
the server.


> 7. open a webbrowser (imagine that, I often have no browser open)
> 8. visit a website to "request merge"
> 9. find my local branch there
> 10. find my local commit there

Ok, you need make a request.
But I guess it could be automated by a script so you don't need the web 
browser.

> 11. hope that the web page wont error out with "We are sorry, but something
> went wrong"
> 12. retry steps 8-10, because I could have make a mistake
> 13. hope that the web page wont error out with "We are sorry, but something
> went wrong"
> 14. retry steps 8-10 four hours later, because it might be a server load
> problem
> 15. hope that the web page wont error out with "We are sorry, but something
> went wrong"
> 16. retry steps 8-10 the next day, because it might be a bug in gitourious
> 17. repeat steps 8-16 when I want it in stable branch
> 18. hope that I don't forget to switch back to a different branch before I
> apply/commit my next fix

This is the "bad faith" I was refering to earlier.
Technical problem might happen, but I don't see them that often.

> 19. wait 4 hours for the next Qt recompile due to switching branches
> 20. wait 20 hours for next KDE recompile due to switching branches

Same with kde when you do svn up of kdelibs. Nothing we can do against that.
(Internaly we use compilation farm so it doesn't take 4 hours)

> 21. wait 14 days before someone even looks at it
> 22. wait 2 months to get a mail that it has been applied
> 23. go back to editor to look for the next thing I could fix

You don't need to wait the change to be integrated to go back to your editor.

And yes, you will have to wait a bit for a reply, we have a lot of things to 
do, and reviewing takes time.

> So much for "exactly".
>
> Yes, these is my actual experiences.
>
> > > </ignorethis>
>
> You did not ;)

Thanks for expressing your opinions.

-- 
Gof