Re: [Wikitech-l] Draft plan for 1.17 branch next week (Code review and making it to 1.17)
2010/12/5 Roan Kattouw : > The picture might look > different for WMF-enabled extensions, I'll have stats on them > tomorrow. > Full stats at http://toolserver.org/~catrope/crstats . Key figures: * There are 762 unreviewed revisions in phase3 (phase3-statuses.html). 41 of these are in the r776* and r777* series (past 200 revs), the rest are clustered more or less randomly * There are 1620 unreviewed revisions in WMF-deployed code. These seem to be a bit more clustered towards recent revisions. Roan Kattouw (Catrope) ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Draft plan for 1.17 branch next week (Code review and making it to 1.17)
On Sat, Dec 4, 2010 at 10:27 PM, Roan Kattouw wrote: > 2010/12/4 Robert Leverington : >> It is unclear to me whether the plan is to branch from the latest >> reviewed code or trunk HEAD > This was kind of overlooked by everyone in that discussion :( > The latest fully reviewed code is like February or March 2010, so I think everybody was assuming HEAD. Bryan ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Draft plan for 1.17 branch next week (Code review and making it to 1.17)
Rob Lanphier wrote: > Hi everyone, > > On IRC, Trevor lead the charge "to Etherpad!", and some of us > followed. This was the result: > http://www.mediawiki.org/wiki/MediaWiki_roadmap/1.17 > > This is an aggressive plan, starting with branching for 1.17 early > next week. It is by no means official; Tim and Mark H are both named, > but neither have weighed in, so don't take this as "the plan", but as > a proposal for discussion here. > > Rob It's nice having a plan. But I wonder who will assign those "engineering resources"? And what will they be unassigned from? Regarding the "Release manager" section, I have no problem aiding with merging (that is, provided I'm comfortable with the fix itself :) but I don't think that's something reserved to a few RM. Rather, if something is a bugfix affecting the branch, the commiter should backport it himself (or tag as 1.17, and delay the MFT until it gets reviewed). We can't assume that any bugfix will be seen and cherrypicked as appropiate (even with more than one person doing that work). ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Draft plan for 1.17 branch next week (Code review and making it to 1.17)
2010/12/5 Robert Leverington : > On the other hand this creates a huge amount of work in identifying and > backporting any essential bug fixes between the branch point and HEAD at > branching - I imagine probably more than it alleviates (albeit for > different people). > Yes, there's a balance there. In the post you're replying to I said it should be considered if unreviewed revisions were skewed towards the recent ones, but this doesn't seem to be the case for /trunk/phase3 at least. See https://secure.wikimedia.org/wikipedia/mediawiki/wiki/User:Catrope/CR_stats#Distribution_of_unreviewed_revisions_in_phase3 for details (left column is a 3-digit revid prefix identifying a range of 100 revisions, right column is the number of new/fixme revs in that range): for instance, the past 7 days account for 5% of the review backlog, the past ~4 weeks for ~10%. However, we've only got good stats on phase3 at this time; I'll run them on phase3 plus WMF-deployed extensions tomorrow so we'll have the full picture. The crux of the above: recent revisions are a tiny fraction of the review backlog (the last ~4 weeks of commits account for only ~10% of the backlog), at least for /trunk/phase3. IMO this means there's no reason to branch off anything other than HEAD. The picture might look different for WMF-enabled extensions, I'll have stats on them tomorrow. > Either way this is something that needs to be considered prior to > branching as it will change the schedule and allocation of resources > (to me the current schedule seems overly optimistic in this respect). > I agree the review backlog won't magically fix itself over the holidays, which is why I call on everyone who can help to do so or ask their boss to be 'allowed' to spend time on it (I hear RobLa is allocating some people's time to this). Roan Kattouw (Catrope) ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Draft plan for 1.17 branch next week (Code review and making it to 1.17)
On 2010-12-04, Roan Kattouw wrote: > 2010/12/4 Robert Leverington : > > The schedule suggests an intial deployment in January, > > but my understanding is that even if there were no further commits it > > would still take until March for it to catch up with HEAD. > > > March has been mentioned by a few people now, and now you're even > suggesting that /even with no further commits/ it would take that > long. To me that seems overly pessimistic. The code review backlog in > /trunk/phase3 was 775 revisions last time I checked (Saturday around > 01:15 UTC). It shouldn't take 3 months to catch up with that. The pessimism was not intentional, just noting my understanding of what others said. What you say sounds reasonable. > Of course "less than 3 months" doesn't necessarily mean it'll be a > manageable amount of time, and there's WMF-deployed extensions to > consider too. So I do think we should look at where the unreviewed > revs are concentrated; if it turns out they're mostly recent, that'd > be a strong case for moving the branch point into the past. On the other hand this creates a huge amount of work in identifying and backporting any essential bug fixes between the branch point and HEAD at branching - I imagine probably more than it alleviates (albeit for different people). Either way this is something that needs to be considered prior to branching as it will change the schedule and allocation of resources (to me the current schedule seems overly optimistic in this respect). Robert ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Draft plan for 1.17 branch next week (Code review and making it to 1.17)
2010/12/4 Robert Leverington : > It is unclear to me whether the plan is to branch from the latest > reviewed code or trunk HEAD This was kind of overlooked by everyone in that discussion :( > , assuming the latter then I think that code > review needs to be a part of the schedule as it is by far the most time > consuming part of the process and presumably needs to be complete before > a deployment. Yes. > The schedule suggests an intial deployment in January, > but my understanding is that even if there were no further commits it > would still take until March for it to catch up with HEAD. > March has been mentioned by a few people now, and now you're even suggesting that /even with no further commits/ it would take that long. To me that seems overly pessimistic. The code review backlog in /trunk/phase3 was 775 revisions last time I checked (Saturday around 01:15 UTC). It shouldn't take 3 months to catch up with that. Of course "less than 3 months" doesn't necessarily mean it'll be a manageable amount of time, and there's WMF-deployed extensions to consider too. So I do think we should look at where the unreviewed revs are concentrated; if it turns out they're mostly recent, that'd be a strong case for moving the branch point into the past. Roan Kattouw (Catrope) ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Draft plan for 1.17 branch next week (Code review and making it to 1.17)
On 2010-12-03, Rob Lanphier wrote: > Hi everyone, > > On IRC, Trevor lead the charge "to Etherpad!", and some of us > followed. This was the result: > http://www.mediawiki.org/wiki/MediaWiki_roadmap/1.17 It is unclear to me whether the plan is to branch from the latest reviewed code or trunk HEAD, assuming the latter then I think that code review needs to be a part of the schedule as it is by far the most time consuming part of the process and presumably needs to be complete before a deployment. The schedule suggests an intial deployment in January, but my understanding is that even if there were no further commits it would still take until March for it to catch up with HEAD. Robert ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] Draft plan for 1.17 branch next week (Code review and making it to 1.17)
Hi everyone, On IRC, Trevor lead the charge "to Etherpad!", and some of us followed. This was the result: http://www.mediawiki.org/wiki/MediaWiki_roadmap/1.17 This is an aggressive plan, starting with branching for 1.17 early next week. It is by no means official; Tim and Mark H are both named, but neither have weighed in, so don't take this as "the plan", but as a proposal for discussion here. Rob On Fri, Dec 3, 2010 at 2:35 PM, Trevor Parscal wrote: > Agreed - branching will not prevent bugs from getting fixed, we will be > merging in a limited set of changes (fixes to bug) while ignoring new > and irrelevant development. > > - Trevor > > On 12/3/10 2:26 PM, Roan Kattouw wrote: >> 2010/12/3 Platonides: >>> So if we can cope with reviewing, I would wait (I think >>> RobLa took it into account). Who will work into stabilizing the branch? >>> A branch will have less attention (bug hunting) than trunk >> Well to keep review catchup manageable, I think we need to either >> branch or declare something like a feature freeze and freeze for minor >> stuff in trunk. My general opinion on this sort of thing is that trunk >> should not generally be subject to such freezes. >> >> Roan Kattouw (Catrope) >> >> ___ >> Wikitech-l mailing list >> Wikitech-l@lists.wikimedia.org >> https://lists.wikimedia.org/mailman/listinfo/wikitech-l > > ___ > Wikitech-l mailing list > Wikitech-l@lists.wikimedia.org > https://lists.wikimedia.org/mailman/listinfo/wikitech-l > > ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
