[haiku-development] Re: [haiku-development] Commit access for Andreas Färber
- From: Ingo Weinhold <ingo_weinhold@xxxxxx>
- To: haiku-development@xxxxxxxxxxxxx
- Date: Mon, 07 Jun 2010 01:06:27 +0200
On 2010-06-06 at 21:57:27 [+0200], Andreas Färber <andreas.faerber@xxxxxx>
wrote:
> 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?
While that would simplify getting trivial patches committed -- which e.g. an
"Apply" button besides a patch would also do -- it wouldn't change anything
for the upfront review. On the downside it would make it more likely that
changes that should be reviewed get committed without ever being reviewed.
[...]
> I can understand that PC users don't really benefit from that, but
> applying it wouldn't seem to break x86 either.
Nope, but that shouldn't be the criterion. Changes should only be committed
when they are OK (according to my earlier definition). Even for stuff pretty
much no one is interested in the code quality should be increased rather than
lowered. It's unfortunate that there are very few developers who review PPC
code at all and that to them the whole thing is low priority, but I still
wouldn't want code from (sorry, lacking a better phrase here ...) "untrusted
sources" to be committed without review.
[...]
> > 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
Then you might want to consider changing your approach and widening your
focus. Working on the PPC port should increase your knowledge of the kernel
in general (how things work together, what restrictions apply, what tools are
available, etc.), of the x86 port (when consulting it for reference), and,
obviously, of PPC specifics (PPC architecture, PPC ABI, OpenFirmware). E.g.
when looking up something in the specs a bit of context and reference reading
goes a long way. For the kernel there's unfortunately no design/code
documentation, but when working on a particular problem some
context/reference reading the kernel sources is very advantageous, too.
> 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?
+1
> - grant "limited" commit access for certain directories like */arch/
> ppc and */platform/openfirmware?
-1 for given reasons.
CU, Ingo
Other related posts:
