[haiku-development] Re: [haiku-development] Re: [haiku-development] Commit access for Andreas Färber
- From: Andreas Färber <andreas.faerber@xxxxxx>
- To: haiku-development@xxxxxxxxxxxxx
- Date: Sun, 6 Jun 2010 21:57:27 +0200
Am 06.06.2010 um 17:05 schrieb Ingo Weinhold:
On 2010-06-06 at 15:09:18 [+0200], Stephan Assmus <superstippi@xxxxxx>
wrote:
perhaps Ingo would be more suited to propose Andreas for commit
access
since he reviews and applies most of Andreas' patches, but to me it
seems
it would already be well deserved and review could continue via the
commit
list. Any objections?
Yes. While I'd like Andreas to get commit access eventually, I think
that
time should not be now. At least not for working on the kernel.
IMO a developer should get commit access when review is not necessary
anymore, i.e. when virtually all patches are OK -- not necessarily bug
free, of course, but in a technical and "that's a good approach"
sense.
If I may offer an opinion myself, you're both assuming a certain
workflow here. In other projects commit access does not imply no more
upfront review. Given that the Haiku tree is pretty large and diverse
too, maybe this is something to rethink?
There have been a number of patches that have been applied with minor
or no changes.
Yet I feel like spamming the Trac site with my Enhancement tickets
(and I do hold back already!).
Like Stephan recently said himself, the patch review is somewhat
unsatisfactory. The patches I least care about get reviewed and
applied the quickest.
Some patches that fall into that 'trivial' category include:
* new keymap
* trace output changes
* resolving unimportant ppc TODOs (who cares if a ppc stack frame is
off by one!)
Then there's patches that are pretty central to my work but don't get
any review for up to half a year, i.e. no negative one either. On that
list:
i) boot loader TCP support,
ii) line ending fixes,
iii) OF system_time().
I can understand that PC users don't really benefit from that, but
applying it wouldn't seem to break x86 either. Given that Macs have no
serial port I would not only like to extend network boot protocol
support but am also investigating redirecting serial output to the
network, so that we can properly retrieve stack traces and debug the
frame buffer blitting.
The longer the review takes, the more features I might add, making
patches larger and even harder to review. And the longer a patch is
unreviewed, the less motivated I am to post updates in a monologue,
potentially leading to differences and conflicts between Trac and
local version once someone does look at it.
Any improvement there beyond Trac checkboxes would be very much
appreciated!
On the other hand, what you probably refer to with:
Most of Andreas' non-trivial patches I've seen so far needed at
least one
review+improvement iteration before I considered them OK.
...will be things like:
* SA_SIGINFO - still no real clue for a clean solution
* every new ppc boot issue - touches a different area each time, so no
familiarity to expect
I honestly don't feel comfortable committing patches in that area to
trunk without prior ACK from someone in the know, whether granted
commit access or not.
So, having said that, is it conceivable to...
- grant slightly elevated Trac priviledges so that I can mark my
tickets as low and duplicate/invalid/fixed myself?
- grant "limited" commit access for certain directories like */arch/
ppc and */platform/openfirmware?
Either way,
Thanks for suggesting!
Whatever gets decided,
It's been an honour.
Regards,
Andreas
Other related posts:
