Christian Heimes [mailto:lists at cheimes.de]:
> Trent Nelson schrieb:
> > I think holding a developer accountable for merging or blocking to
> py3k when they commit to trunk is a great idea. Who better to pass
> judgement on such an activity than the person closest to it?
>
> Blocking a revision makes my job as The Merger easier.
>
> I'm not so sure about the merging part. It takes some experience with
> the Python 3.0 code base to know the subtle differences in the C API.
> Most merges are straight forward for me. If you enforce the forward
> merging on every developer it may slow down development.
> Each regular merge takes me about 45 minutes of computer time but less
> than 15 supervisor time. The computer time is mostly compile and test
> time in the background. If everybody merges her own code to 3.0 it
> still takes *everybody* about 10 minutes of time and 45 minutes of computer
> time.
Ah, right, I wasn't thinking about the implication of code affecting the C base for some reason, but that's entirely reasonable. Perhaps each developer should be accountable for either:
a) blocking
b) merging, if they're able to do so
c) if they're unable to merge, replying to the relevant python-checkins@ e-mail indicating that they're unable to handle trunk -> py3k for whatever reason (e.g. not familiar with py3k code base)
Other developers could then pitch in and help merge if someone requests it via e-mail. I'd think that would make The Merger's life easier.
Trent.
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4