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
