[haiku-development] Re: Apply Clang work from midar-github.master
- From: Jonathan Schleifer <js-haiku-development@xxxxxxxxxxx>
- To: haiku-development@xxxxxxxxxxxxx
- Date: Tue, 17 Dec 2013 01:33:08 +0100
First: I'm going to criticize a lot of the workflow in this mail, but please
don't take it personally, I mean it well: In order to solve a problem in the
workflow, it needs to be pointed out.
> Understandably. I can tell you that nobody likes being a roadblock to anybody
> else. Suppose you find yourself with an hour of spare time all of the sudden.
> Do you, a) spend it figuring out which patch you should look at first on Trac
> or b) picking up where you left off coding Haiku and finally trying the idea
> you had rolling in your head for a while?
I can understand that very well. Nobody wants to search the archives or
actively look for patches in the bug tracker. But I actually bugged people
directly several times, without much action. After about a year, this changed
when a Clang port was mentioned in the IRC and I replied that I already did the
work but that it has never been paid attention to and thus I never rebased it,
so it was based on a 1 year old repo. I said that I'd be willing to rebase it,
but if and only if someone promises me that it then gets merged, so that I
don't do all that work for nothing again. After that, tqh promised to not
forget about the branch and working on getting it in.
So, as you can see, there is a real problem that can't be reduced to "I rather
code than look at Trac".
> Sometimes I do a), but then I find out the code is not good quality and I
> have to chose to either explain to the contributor what I would do
> differently or just do the work myself. But when I want to apply the patch,
> it no longer applies...
Yes, the no longer applies part is what happens if patches get ignored for too
long. That can be fixed by faster deciding whether a patch should go in or not.
Maybe a solution would be to automatically set a deadline for a ticket in Trac
if a patch is attached and it needs to be decided within this deadline whether
the patch gets merged or not, and if not why?
> The real problem here is that there simply isn't a critical mass of Haiku
> committers with enough spare time to also work through patches, among other
> things.
I can understand that. I can understand people ignoring patches in Trac. But
the problem here was that people actually reviewed the stuff, said "this is ok
besides this whitespace, remove it" and then ignored the new patch were it was
fixed instead of merging it. And I also cannot understand why even after
bugging people on IRC it doesn't get merged. If you already replied to a commit
and said it's basically good, but change this one little thing, then you
already know you can merge the patch if the author says he fixed it, which then
is a matter of seconds. I don't get why this didn't happen.
I know I criticized a lot now, but I mean it well. I'm just pointing the
problems I experienced so that the workflow can be improved.
> If you are still interested, maybe it would be a good idea for people who
> actually reviewed your patches to speak up whether they feel you should
> simply get commit access. It would definitely be great to have you.
Yes, I did not lose interest in Haiku, I only became frustrated with not
getting it in and basically gave up. Commit access would solve that problem and
I'd be more than happy to commit these changes myself, but unfortunately this
only solves the problem for me, not for others. So while this would be a
solution with which I'd be very happy, the workflow would still need
improvement. I remember than when I looked through Trac more than 1 year ago,
there were many interesting patches which just rotted there.
--
Jonathan
Other related posts:
