Please forgive my point-by-point response. You have some excellent questions and interesting points, and I did not want to loose any context.
On 11/2/10 10:46 AM, Robert Leverington wrote: > I wasn't present in D.C. so can't comment on the arguments made there, > but it is my understanding that there are people who are responsible for > reviewing code who aren't able/willing to deploy it - so this isn't > something that has a binary state. It's either going to be deployed, and thus needs to be reviewed, merged and scapped or it's not. There's no point to reviewing code that is not going to be merged and scapped, we should never be merging code that has not been reviewed, and we can't scap code that hasn't been merged - reviewed or not. Dividing these tasks is pointless, they either all need to be performed or none of them do. > Also, I think it would be useful > to document the movement between review, deployment, and enabling - as > even if this is done by a single person they might not be able to > complete it in one session, and the transparency is nice. > It is, that's what the state of the revision is for, it lets us keep track of whether the revision has been reviewed, and if so whether it's a good thing to merge or not (ok vs fixme). > Correct me if I'm wrong, but I believe we're talking specifically about > completely unreviewed extensions that need looking at entirely - not > incrementally. Certainly once an extension has been initially > reviewed and deployed, the existing code review system would come in to > effect - and I don't think we need to change anything with that at the > moment. If that's true, then we may be over-thinking this. The deployment of new features is only a tiny fraction of the review, merge and scap workload. - Trevor _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
