On Wed, Apr 27, 2011 at 12:43 PM, Chad innocentkiller@gmail.com wrote:
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.
I've been thinking about this over the past few days, and I've got a proposed release schedule and development roadmap to carry us through the rest of the year.
As we all know, 1.17 is due to drop Real Soon Now. To summarize for those who don't know the status: it's pretty much done. In talking with Roan, Tim and Sam earlier this week, we discussed that we're pretty much ready to drop a 1.17beta1. Tim was concerned about the release notes, but as I pointed out in my previous e-mail, Sam's tidied this up (and it's low-hanging fruit if someone wants to check behind us for sanity). That being said, I don't see any reason why we can't drop a beta1 sometime this week. Give it a week, and drop a beta2. Wait another week, then go final I think, all depending on what response we get from the betas.
As for 1.18, I say we branch it the same day we drop 1.17 final (making the branch is easy). There's still quite a bit of code to review, but going ahead and giving ourselves a cutoff point will make catching up easier. Large projects still outstanding in 1.18 to review are the img_metadata merge, and rewrites of Skin and Action code. By branching soon I think we can try to get a release out by the end of summer, at the very latest.
Looking ahead to 1.19, I'd like to do the same and branch soon after 1.18 has been dropped. Since 1.19's a little further out and hasn't started taking shape yet, I'd like to go ahead and propose what sort of release we should aim for.
Going back over the past couple of releases, we've had quite a few "rewrites" of major portions of code. While these are a necessary part of the process of developing MW, they are difficult to review due to their complexity. This complexity also makes it more likely for things to break. If I may be so bold, I would like to ask that 1.19 not contain any of these rewrites. Let's focus on making it a bugfix/cleanup release. Personally I think it would make for a very clean and polished release, as well as reducing the time for us to review and ship it.
If we go this route, I don't see any reason we couldn't ship 1.19 by year end (or if we really push, 11.11.11, as the other thread suggested). I think it would put us in a really good place to move forward into 2012, and help get us back into a somewhat regular release pattern.
I really would love to hear from people to see if they think I'm crazy or if this could work out fairly well. I know it's pretty tl;dr for most people, but the ones who read it are the ones I wanna hear from anyway ;-)
-Chad
+1;
Sent from my Android phone.
On Sat, Apr 30, 2011 at 5:05 AM, Chad innocentkiller@gmail.com wrote:
As for 1.18, I say we branch it the same day we drop 1.17 final (making the branch is easy). There's still quite a bit of code to review, but going ahead and giving ourselves a cutoff point will make catching up easier. Large projects still outstanding in 1.18 to review are the img_metadata merge, and rewrites of Skin and Action code. By branching soon I think we can try to get a release out by the end of summer, at the very latest.
Suggest waiting a couple of weeks in case a lot of bugs will be discovered in 1.17 release, to reduce the number of needed merges.
On Sat, Apr 30, 2011 at 3:05 AM, Chad innocentkiller@gmail.com wrote:
Looking ahead to 1.19, I'd like to do the same and branch soon after 1.18 has been dropped. Since 1.19's a little further out and hasn't started taking shape yet, I'd like to go ahead and propose what sort of release we should aim for.
Going back over the past couple of releases, we've had quite a few "rewrites" of major portions of code. While these are a necessary part of the process of developing MW, they are difficult to review due to their complexity. This complexity also makes it more likely for things to break. If I may be so bold, I would like to ask that 1.19 not contain any of these rewrites. Let's focus on making it a bugfix/cleanup release. Personally I think it would make for a very clean and polished release, as well as reducing the time for us to review and ship it.
I like this idea, although it does mean pushing back the iwtransclusion branch merge to 1.20, presumably. But then you say:
If we go this route, I don't see any reason we couldn't ship 1.19 by year end (or if we really push, 11.11.11, as the other thread suggested).
We'd be branching 1.18 in mid-May (when 1.17 goes final). If we release a beta of 1.19 in November and it's a small release, we should branch in October (or branch in November and release by year end). That means there'd be 5 or 6 months of development in 1.19. I'm on board with shooting for a clean and polished release, but we shouldn't make /any/ release longer than 4 months, and this one should probably be 3 IMO. Also, 6 months is a long time for a ban on rewrites.
I've seen a few suggestions about release schedules on this list now, and all of them seem to, implicitly or explicitly, accept that releases contain outrageous amounts of code and take more than 3 months to stabilize, just because that's what happened with 1.17. Instead, I'd like us to be ambitious about not repeating the 1.17 fiasco, and aiming for a shorter cycle. Tim is right in the other thread that cycles can be too short, but I think once every 3-4 months is good middle ground. In any case, if stabilizing a release to even get it to the first beta takes more than a month, something is fundamentally wrong IMO.
think it would put us in a really good place to move forward into 2012, and help get us back into a somewhat regular release pattern.
I agree and applaud this goal, though per the above I'm not entirely sure we mean the same thing when we say "regular release pattern".
Roan Kattouw (Catrope)
On Sat, Apr 30, 2011 at 7:00 AM, Roan Kattouw roan.kattouw@gmail.com wrote:
I like this idea, although it does mean pushing back the iwtransclusion branch merge to 1.20, presumably. But then you say:
That thought occurred to me, it would require pushing iwtransclusion back a bit.
If we go this route, I don't see any reason we couldn't ship 1.19 by year end (or if we really push, 11.11.11, as the other thread suggested).
We'd be branching 1.18 in mid-May (when 1.17 goes final). If we release a beta of 1.19 in November and it's a small release, we should branch in October (or branch in November and release by year end). That means there'd be 5 or 6 months of development in 1.19. I'm on board with shooting for a clean and polished release, but we shouldn't make /any/ release longer than 4 months, and this one should probably be 3 IMO. Also, 6 months is a long time for a ban on rewrites.
I've seen a few suggestions about release schedules on this list now, and all of them seem to, implicitly or explicitly, accept that releases contain outrageous amounts of code and take more than 3 months to stabilize, just because that's what happened with 1.17. Instead, I'd like us to be ambitious about not repeating the 1.17 fiasco, and aiming for a shorter cycle. Tim is right in the other thread that cycles can be too short, but I think once every 3-4 months is good middle ground. In any case, if stabilizing a release to even get it to the first beta takes more than a month, something is fundamentally wrong IMO.
My math was bad :) I was mainly looking at how long it took us to stabilize and release 1.17, and didn't really think we could get more than 3 releases (1.17, 18 and 19) out by year end. I think anything more ambitious than that is a little crazy on our part. But you're right, 6 months is a long time to say "don't rewrite stuff." That's why I asked for feedback.
think it would put us in a really good place to move forward into 2012, and help get us back into a somewhat regular release pattern.
I agree and applaud this goal, though per the above I'm not entirely sure we mean the same thing when we say "regular release pattern".
Regular here being "more than 1 and a half releases a year" :p
-Chad
On Sat, Apr 30, 2011 at 1:54 PM, Chad innocentkiller@gmail.com wrote:
My math was bad :) I was mainly looking at how long it took us to stabilize and release 1.17
I just want to reiterate that 1.17 is not necessarily a good precedent that's representative of 'normal' releases.
, and didn't really think we could get more than 3 releases (1.17, 18 and 19) out by year end.
It's not entirely fair to attribute 1.17 to this year, since it was branched last year. If we branch 1.18 when we release 1.17 and have a sane release latency, we'll have two releases in two months, but that's entirely due to wildly different latencies. The branch points would be mostly regular though.
Roan Kattouw (Catrope)
"Chad" innocentkiller@gmail.com wrote in message news:BANLkTi=mwb7GdCfZfTm4VxbwLn3iKStw+w@mail.gmail.com...
On Wed, Apr 27, 2011 at 12:43 PM, Chad innocentkiller@gmail.com wrote: Tim was concerned about the release notes, but as I pointed out in my previous e-mail, Sam's tidied this up (and it's low-hanging fruit if someone wants to check behind us for sanity). That being said, I don't see any reason why we can't drop a beta1 sometime this week. Give it a week, and drop a beta2. Wait another week, then go final I think, all depending on what response we get from the betas.
+1
As for 1.18, I say we branch it the same day we drop 1.17 final (making the branch is easy).
+1. I think porting 1.17 fixes to 1.18 is a much lesser evil than allowing the 1.18 branch to get any bigger.
There's still quite a bit of code to review, but going ahead and giving ourselves a cutoff point will make catching up easier. Large projects still outstanding in 1.18 to review are the img_metadata merge, and rewrites of Skin and Action code.
The plan *was* to revert the Action rewrite from 1.18 and put it into 1.19. If that's not going to happen then we should probably either a) push on with its development and try and get it fully in place for 1.18, b) (my preference) stabilise what's already there and leave it as a partially-used-framework like Message, or c) revert it altogether. We can't roll it back out of 1.18 *and* 1.19.
Looking ahead to 1.19, I'd like to do the same and branch soon after 1.18 has been dropped.
+1
Going back over the past couple of releases, we've had quite a few "rewrites" of major portions of code. While these are a necessary part of the process of developing MW, they are difficult to review due to their complexity. This complexity also makes it more likely for things to break. If I may be so bold, I would like to ask that 1.19 not contain any of these rewrites. Let's focus on making it a bugfix/cleanup release. Personally I think it would make for a very clean and polished release, as well as reducing the time for us to review and ship it.
+0 -- I don't have time in the next six months to take the hedgecutters to anything else in the codebase anyway... :-D
If we go this route, I don't see any reason we couldn't ship 1.19 by year end (or if we really push, 11.11.11, as the other thread suggested). I think it would put us in a really good place to move forward into 2012, and help get us back into a somewhat regular release pattern.
If it helps with getting onto a regular release pattern, then that's good. We need to be careful that that doesn't come at the expense of Useful Stuff Not Getting Done: it would be very easy to maintain a release schedule if we never added any new features, but it would be fairly pointless. I do understand what you mean, and I think it would be a worthwhile exercise; just as long as we treat it as an experiment.
I really would love to hear from people to see if they think I'm crazy or if this could work out fairly well. I know it's pretty tl;dr for most people, but the ones who read it are the ones I wanna hear from anyway ;-)
I approve of this response-filtration scheme... :-D
--HM
On 30/04/11 11:05, Chad wrote:
On Wed, Apr 27, 2011 at 12:43 PM, Chad innocentkiller@gmail.com wrote:
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.
I've been thinking about this over the past few days, and I've got a proposed release schedule and development roadmap to carry us through the rest of the year.
As we all know, 1.17 is due to drop Real Soon Now. To summarize for those who don't know the status: it's pretty much done. In talking with Roan, Tim and Sam earlier this week, we discussed that we're pretty much ready to drop a 1.17beta1.
Maybe we can talk about this again tonight my time, if you're around.
Tim was concerned about the release notes, but as I pointed out in my previous e-mail, Sam's tidied this up (and it's low-hanging fruit if someone wants to check behind us for sanity).
It would be nice if someone could write a user-oriented summary of the major changes in the branch, like I did for 1.16. The 1.16 one was used for the RELEASE-NOTES file, the mediawiki-announce email and the blog post. The 1.17 one would probably be used in the same places.
Looking ahead to 1.19, I'd like to do the same and branch soon after 1.18 has been dropped. Since 1.19's a little further out and hasn't started taking shape yet, I'd like to go ahead and propose what sort of release we should aim for.
Going back over the past couple of releases, we've had quite a few "rewrites" of major portions of code. While these are a necessary part of the process of developing MW, they are difficult to review due to their complexity. This complexity also makes it more likely for things to break. If I may be so bold, I would like to ask that 1.19 not contain any of these rewrites. Let's focus on making it a bugfix/cleanup release. Personally I think it would make for a very clean and polished release, as well as reducing the time for us to review and ship it.
The usual situation is that some developers are interested in features and others are interested in bug fixes. If you declare that you only want bug fixes, you risk losing the feature developers.
I think that the best way to retain feature developers is to treat them with respect and to value their contributions. That is why I haven't proposed a "feature freeze" in the past.
It would be possible to do a stability-oriented release if that's really what the community wants, but it would have to be carefully managed. We would have to increase our mentoring and review activity in the development branches, and keep the schedule very tight indeed.
Given our past record, I'm not really confident that we can pull that off. There's a risk of screwing it up badly and offending a lot of people. Release management isn't exactly an organisational strength.
-- Tim Starling
On 02.05.2011, 10:41 Tim wrote:
It would be nice if someone could write a user-oriented summary of the major changes in the branch, like I did for 1.16. The 1.16 one was used for the RELEASE-NOTES file, the mediawiki-announce email and the blog post. The 1.17 one would probably be used in the same places.
I started that at http://www.mediawiki.org/wiki/MediaWiki_1.17 some time ago, needs more collaboration.
On Mon, May 2, 2011 at 3:06 AM, Max Semenik maxsem.wiki@gmail.com wrote:
On 02.05.2011, 10:41 Tim wrote:
It would be nice if someone could write a user-oriented summary of the major changes in the branch, like I did for 1.16. The 1.16 one was used for the RELEASE-NOTES file, the mediawiki-announce email and the blog post. The 1.17 one would probably be used in the same places.
I started that at http://www.mediawiki.org/wiki/MediaWiki_1.17 some time ago, needs more collaboration.
Thank you for starting this. Sam and I are poking at it now.
-Chad
On 02/05/11 09:06, Max Semenik wrote:
I started that athttp://www.mediawiki.org/wiki/MediaWiki_1.17 some time ago, needs more collaboration.
And I started the 1.18 one with illustrative (and free) pictures :p
http://www.mediawiki.org/wiki/MediaWiki_1.18
On Mon, May 2, 2011 at 2:41 AM, Tim Starling tstarling@wikimedia.org wrote:
Looking ahead to 1.19, I'd like to do the same and branch soon after 1.18 has been dropped. Since 1.19's a little further out and hasn't started taking shape yet, I'd like to go ahead and propose what sort of release we should aim for.
Going back over the past couple of releases, we've had quite a few "rewrites" of major portions of code. While these are a necessary part of the process of developing MW, they are difficult to review due to their complexity. This complexity also makes it more likely for things to break. If I may be so bold, I would like to ask that 1.19 not contain any of these rewrites. Let's focus on making it a bugfix/cleanup release. Personally I think it would make for a very clean and polished release, as well as reducing the time for us to review and ship it.
The usual situation is that some developers are interested in features and others are interested in bug fixes. If you declare that you only want bug fixes, you risk losing the feature developers.
I think that the best way to retain feature developers is to treat them with respect and to value their contributions. That is why I haven't proposed a "feature freeze" in the past.
I understand, respect, and value the contributions of people who want to add new features. Features are what moves the product forward, and at no point do we want to be hostile to people willing to put in their time and effort to add functionality.
Given that our patch review process isn't fantastic, I really don't think it would affect the majority of bugs anyway. Mainly affected would be people with core access who write a new feature without putting it through BZ first. Given that our core group is relatively small, I figured we could come to some sort of consensus, if we do indeed move forward with this.
It would be possible to do a stability-oriented release if that's really what the community wants, but it would have to be carefully managed. We would have to increase our mentoring and review activity in the development branches, and keep the schedule very tight indeed.
I don't know what our development community wants. I just happened to think it was a good idea and so brought it up for discussion. If we collectively decide I'm nuts, we can toss this proposal, I won't be upset. I know we'd need to keep development on a very strict timeframe, which is why I outlined a more strict branching and timeline to stick to. As Roan and others pointed out, 6 months is a little long. I don't think we couldn't decide on a branch point and stick to it, especially if we're not holding up a branch for someone to finish sorting out a rewrite or major feature they didn't quite resolve.
Given our past record, I'm not really confident that we can pull that off. There's a risk of screwing it up badly and offending a lot of people. Release management isn't exactly an organisational strength.
I agree it's not our strength, but I don't think we can't do it. I think sticking to a firm branch date would largely alleviate this issue. I remain convinced that a stability-focused release would be a good idea at some point, whether we do it now or in a year.
-Chad
"Chad" innocentkiller@gmail.com wrote in message news:BANLkTikd4Eb-V8W-kA1qe+=bnJxMJ+OxUA@mail.gmail.com...
I understand, respect, and value the contributions of people who want to add new features. Features are what moves the product forward, and at no point do we want to be hostile to people willing to put in their time and effort to add functionality.
Given that our patch review process isn't fantastic, I really don't think it would affect the majority of bugs anyway. Mainly affected would be people with core access who write a new feature without putting it through BZ first. Given that our core group is relatively small, I figured we could come to some sort of consensus, if we do indeed move forward with this.
...
I don't know what our development community wants. I just happened to think it was a good idea and so brought it up for discussion. If we collectively decide I'm nuts, we can toss this proposal, I won't be upset. I know we'd need to keep development on a very strict timeframe, which is why I outlined a more strict branching and timeline to stick to. As Roan and others pointed out, 6 months is a little long. I don't think we couldn't decide on a branch point and stick to it, especially if we're not holding up a branch for someone to finish sorting out a rewrite or major feature they didn't quite resolve.
Given our past record, I'm not really confident that we can pull that off. There's a risk of screwing it up badly and offending a lot of people. Release management isn't exactly an organisational strength.
I agree it's not our strength, but I don't think we can't do it. I think sticking to a firm branch date would largely alleviate this issue. I remain convinced that a stability-focused release would be a good idea at some point, whether we do it now or in a year.
Feature freezes don't have much potential in the current development climate because the choice is basically between committing a feature to trunk and not committing a feature at all. Development work done in branches might as well be left in a working copy for all the attention it gets, BZ patches doubly so. What would almost certainly happen in a feature freeze would be that developers who are interested in core rewrites / major features would simply queue up their work for the next release, which would make 1.20 another massively-rewritten monster. That, if not properly managed, is just creating a bigger problem down the line; although conversely you could say it would make for a particularly Awesome(TM) milestone release.
If a feature freeze is to work, it has to either a) be for a very short period so that developers neither get disenchanted and wander off nor start stockpiling working-copy changes to empty onto trunk once it's thawed, or b) be part of a fundamental change in the way we approach rewrites. It would be perfectly acceptable to move to a completely different paradigm where branches are used properly, regularly reviewed, get plenty of inter-developer testing and can be smoothly merged back into trunk in an organised fashion. But right now, the only way to reliably get external eyes on code is to put it in trunk; the occasions when multiple developers are working on the same branch are both rare and not quite the same thing.
My login rewrite was done as a branch merge and was reverted three times from 1.16 (not unreasonably, for sure, but for bugs flagged up by precisely the sort of diverse testing that being in trunk provides and being in a branch doesn't); it's now 30,000 revisions bitrotted and will probably have to be redone from scratch. The 1.18 blocking rewrite was done in pieces in trunk and looks to have settled in reasonably well. A feature freeze will probably result in rather more of those Big Scary Commits (TM) -- either branch merges or whole features put together in a working copy -- and fewer features implemented through incremental changes. If we don't have provisions in place to handle that in some way, it will probably create more problems than it solves.
--HM
On Mon, May 2, 2011 at 7:52 PM, Happy-melon happy-melon@live.com wrote:
If a feature freeze is to work, it has to either a) be for a very short period so that developers neither get disenchanted and wander off nor start stockpiling working-copy changes to empty onto trunk once it's thawed, or b) be part of a fundamental change in the way we approach rewrites. It would be perfectly acceptable to move to a completely different paradigm where branches are used properly, regularly reviewed, get plenty of inter-developer testing and can be smoothly merged back into trunk in an organised fashion. But right now, the only way to reliably get external eyes on code is to put it in trunk; the occasions when multiple developers are working on the same branch are both rare and not quite the same thing.
I'm proposing (a). Shifting to (b) is an organizational shift, and some people don't seem to think it can happen unless we move to the Magical World of Git.
-Chad
I find fine planning to have a "normal", small release. But if the code development lead to eg. a parser rewrite, that's fine too. It can get in, or reverted for the branch if too close to the brach point. As far as it gets reviewed in time, it shouldn't be a problem. (We are going to get everything timely reviewed™ this time, right? ;) However, if it gets unreviewed three months, with furhter changes dependant of it, and is only looked at two weeks before the branching date (and obviously finding issues), then such rewrite becomes a big problem.
"Happy-melon" happy-melon@live.com writes:
Development work done in branches might as well be left in a working copy for all the attention it gets
I'm not about to say that development branches get the love and attention of trunk — just look at the mess we have with with iwtransclusion branch. Here we are about 9 months later and the GSOC code is just now being merged. (https://bugzilla.wikimedia.org/28673)
We are learning from that mistake, though. I think Sumanah is directing current GSOC students to work on trunk instead of a branch.
BZ patches doubly so.
I'm watching the front of the bug stream and, usually, when someone finds bug and provides a patch, I apply it right away. If someone does that enough (/me waves at Paul Copperman) then we try to get them commit access.
Of course, things aren't perfect, but hopefully they are getting better.
Mark.
wikitech-l@lists.wikimedia.org