Hi all,
I'm wondering what the status for 1.17 is. How far are we from RC? Is there any more review left?
Related to this, as our review burden for 1.17 lessens, we should start to think about 1.18: re-recruit reviewers again, start thinking about when to branch 1.18, etc. Are there any plans related to that?
Bryan
Bryan Tong Minh bryan.tongminh@gmail.com writes:
I'm wondering what the status for 1.17 is. How far are we from RC? Is there any more review left?
Initially, Chad was going to be the release manager for 1.17, but other issues meant that he isn't going to have time to manage it right now.
I think the current plan is to have Tim make the 1.17 release. I don't think any merges are left at this time besides, maybe, the recent XSS fix.
Still, since Tim is is the release manager, he should have more definitive answers.
Related to this, as our review burden for 1.17 lessens, we should start to think about 1.18: re-recruit reviewers again, start thinking about when to branch 1.18, etc. Are there any plans related to that?
Nothing formal yet, but all of us are very aware of the need to make code review happen in a timely manner. I'll be watching CRStats (http://toolserver.org/~robla/crstats/crstats.html) closely and encouraging developers to help in code review.
I think branching 1.18 immediately after the 1.17 release (or now, for that matter) will help us manage code review better. If we have people testing the 1.18 branch and updating regularly (similar to what Ubuntu does for their development) and we set a date (July 15th?) when we know we have to have a release prepared, then that will help Code Review all the more.
But after a bit of discussion on IRC, I think we should try to get Tim's, Brion's and anyone else's opinion on what they think about the release schedule and code review.
Mark
2011/4/14 Mark A. Hershberger mhershberger@wikimedia.org:
I think branching 1.18 immediately after the 1.17 release (or now, for that matter) will help us manage code review better. If we have people testing the 1.18 branch and updating regularly (similar to what Ubuntu does for their development) and we set a date (July 15th?) when we know we have to have a release prepared, then that will help Code Review all the more.
July?!?
I know 1.17 took a long time, but that was like a year's worth of code. We should strike to keep the branch-to-release time as low as we can, and it definitely needs to be WAY less than 3 months. It's been like 4 months for 1.17, but 1.17 was quite exceptional, and more frequent and quicker releases should become the rule.
My opinion is it would be best to branch 1.18 now-ish and revert Happy-melon's Action changes (he wholeheartedly agreed that's 1.19 material).
Slightly off-topic:
Also, we should get our code review act together in a more sustainable way. I've brought this up before, but it hasn't gotten a lot of attention, probably due to the 1.17 craze. We have to have a serious discussion about code review reform (to use a political-sounding term); I think the tech staff meeting after the Berlin hackathon would be a good venue for discussing the WMF side of this. The conference itself is really supposed to be a hackathon this time, so I'm not sure that having a protracted discussion there would be a very good idea; that's basically what we did the whole time last year, and this year is supposed to not be like that for a reason.
As always we do of course need to be careful to not want to solve this "internally" between WMF staff, but have a public discussion with everyone regardless of whether they happen to be paid. However, my impression is that this particular topic is one that mainly involves staff and that it would be acceptable to hammer something out internally and propose that on wikitech-l as something of a draft, in this particular case. I'd be very interested to hear how unpaid developers feel about that, as some of them have called out this practice as undesirable back in September.
Roan Kattouw (Catrope)
Roan Kattouw wrote:
As always we do of course need to be careful to not want to solve this "internally" between WMF staff, but have a public discussion with everyone regardless of whether they happen to be paid. However, my impression is that this particular topic is one that mainly involves staff and that it would be acceptable to hammer something out internally and propose that on wikitech-l as something of a draft, in this particular case. I'd be very interested to hear how unpaid developers feel about that, as some of them have called out this practice as undesirable back in September.
I'm not a developer, but I can say this: from the outside, there's the appearance that a major part of the problem is that nobody seems to really be in charge. I see this problem in both Wikimedia and MediaWiki code development.
MZMcBride
On Thu, Apr 14, 2011 at 9:17 AM, Mark A. Hershberger < mhershberger@wikimedia.org> wrote:
But after a bit of discussion on IRC, I think we should try to get Tim's, Brion's and anyone else's opinion on what they think about the release schedule and code review.
I say push out a release immediately.
-- brion
On 14/04/11 21:19, Bryan Tong Minh wrote:
Hi all,
I'm wondering what the status for 1.17 is. How far are we from RC? Is there any more review left?
I'll be doing a 1.17beta1 release soon, probably early next week. There are 16 revisions tagged for backporting, those will have to be reviewed and backported, and I'll have to have a quick look through the older backports to make sure everything has a RELEASE-NOTES entry and looks more or less sane.
-- Tim Starling
On Thu, Apr 14, 2011 at 8:27 PM, Tim Starling tstarling@wikimedia.orgwrote:
On 14/04/11 21:19, Bryan Tong Minh wrote:
Hi all,
I'm wondering what the status for 1.17 is. How far are we from RC? Is there any more review left?
I'll be doing a 1.17beta1 release soon, probably early next week. There are 16 revisions tagged for backporting, those will have to be reviewed and backported, and I'll have to have a quick look through the older backports to make sure everything has a RELEASE-NOTES entry and looks more or less sane.
Any updates on this process? What's left to do, and what can people help with?
-- brion
On Wed, Apr 27, 2011 at 12:33 PM, Brion Vibber brion@pobox.com wrote:
Any updates on this process? What's left to do, and what can people help with?
-- brion
Getting the merges reviewed [0] and making sure we have a good set of release notes. That's what I know of, and Reedy's been working on the latter.
-Chad
[0] http://mediawiki.org/wiki/Special:Code/MediaWiki/status/new?path=/branches/R...
Brion Vibber brion@pobox.com writes:
Any updates on this process? What's left to do, and what can people help with?
For the future, it would be great if we have the whole process documented and a way to keep track of where we are in the release process. That way, if the current release manager's time gets eaten up (for example, by school, or, if I had been the manager last September, a TBI), other members of the tarball cabal can step in and keep the ball rolling.
It should be possible to coordinate efforts among members of the tarball cabal so that different members can handle things that could be done in parallel simultaneously.
Thoughts?
Mark.
On Wed, Apr 27, 2011 at 9:55 PM, Mark A. Hershberger mhershberger@wikimedia.org wrote:
It should be possible to coordinate efforts among members of the tarball cabal so that different members can handle things that could be done in parallel simultaneously.
There was an IRC chat today where Tim dished out some tasks to Sam and Chad to prepare for 1.16.5 and 1.17beta1, which Tim said should be first priority. So we have some parallelization going on right now.
Thoughts?
More documentation == good :)
Roan Kattouw (Catrope)
Mark A. Hershberger wrote:
Brion Vibber brion@pobox.com writes:
Any updates on this process? What's left to do, and what can people help with?
For the future, it would be great if we have the whole process documented and a way to keep track of where we are in the release process. That way, if the current release manager's time gets eaten up (for example, by school, or, if I had been the manager last September, a TBI), other members of the tarball cabal can step in and keep the ball rolling.
People get curious about this on an often enough basis, developers and end users. Having a page on mediawiki.org with the current release status of the next upcoming version would be nice (or something similar). mw-bot in #mediawiki usually has some idea if you ask it, but that's a bit obscure. ;-)
MZMcBride
wikitech-l@lists.wikimedia.org