I said I would lay out my thoughts regarding MW releases this weekend, so here goes.
First: I want to provide a regular schedule so users know what to expect, but something that a volunteer (me, for now) can achieve.
Second: I want to provide something that Linux distributors can incorporate into their distributions.
To fulfill the first point, I think a release twice a year -- like Ubuntu releases -- makes a lot of sense. This schedule also works for Linux distributors like Ubuntu, Fedora, and OpenSuSE
Since I started out using Debian (which has now adopted a 2 year freeze cycle), I think it also makes sense to provide LTS support. Platonides and I (but mostly Platonides) have been working with the Debian developers to get 1.19 into Wheezy which was frozen in June.
With that in mind, here is what I propose:
1.18.0 | Security updates till 1.20 1.19.x | April 2012 (LTS) 1.20.0 | October 2012 1.21.0 | April 2013 (Start in May) 1.22.0 | October 2013 (Start in September) 1.23.0 | April 2014 (LTS) 1.24.0 | October 2014 1.25.0 | April 2015 1.26.0 | October 2015 1.27.0 | April 2016 (LTS)
LTS releases will updates until (at least) the next LTS release. This means security updates, but other updates that don't require schema changes if people are interested in providing them. Since a couple of people have put the 1.20.0 milestone on a handful of bugs, I'm assuming now that they think those are worth merging to the 1.20 series. I'd like to get the fixes backported to 1.19 as well, if possible.
Well, that's pretty much it what I was thinking. How does this sound to you guys?
I do like the idea of a semiannual release. On a related note, I also think we should have better plans on what is actually going to be in each release. In other words, a site administrator should be able to know what new features are planned for the next release before the actual release has been made. Maybe this already happens and I just don't know where this resource is. *--* *Tyler Romeo* Stevens Institute of Technology, Class of 2015 Major in Computer Science www.whizkidztech.com | tylerromeo@gmail.com
On Sun, Oct 14, 2012 at 9:26 PM, Mark A. Hershberger mah@everybody.orgwrote:
I said I would lay out my thoughts regarding MW releases this weekend, so here goes.
First: I want to provide a regular schedule so users know what to expect, but something that a volunteer (me, for now) can achieve.
Second: I want to provide something that Linux distributors can incorporate into their distributions.
To fulfill the first point, I think a release twice a year -- like Ubuntu releases -- makes a lot of sense. This schedule also works for Linux distributors like Ubuntu, Fedora, and OpenSuSE
Since I started out using Debian (which has now adopted a 2 year freeze cycle), I think it also makes sense to provide LTS support. Platonides and I (but mostly Platonides) have been working with the Debian developers to get 1.19 into Wheezy which was frozen in June.
With that in mind, here is what I propose:
1.18.0 | Security updates till 1.20 1.19.x | April 2012 (LTS) 1.20.0 | October 2012 1.21.0 | April 2013 (Start in May) 1.22.0 | October 2013 (Start in September) 1.23.0 | April 2014 (LTS) 1.24.0 | October 2014 1.25.0 | April 2015 1.26.0 | October 2015 1.27.0 | April 2016 (LTS)
LTS releases will updates until (at least) the next LTS release. This means security updates, but other updates that don't require schema changes if people are interested in providing them. Since a couple of people have put the 1.20.0 milestone on a handful of bugs, I'm assuming now that they think those are worth merging to the 1.20 series. I'd like to get the fixes backported to 1.19 as well, if possible.
Well, that's pretty much it what I was thinking. How does this sound to you guys?
Any time you have "one overriding idea", and push your idea as a superior ideology, you're going to be wrong. ... The fact is, reality is complicated -- Linus Torvalds http://hexm.de/mc
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Release notes?
-Chad On Oct 14, 2012 9:30 PM, "Tyler Romeo" tylerromeo@gmail.com wrote:
I do like the idea of a semiannual release. On a related note, I also think we should have better plans on what is actually going to be in each release. In other words, a site administrator should be able to know what new features are planned for the next release before the actual release has been made. Maybe this already happens and I just don't know where this resource is. *--* *Tyler Romeo* Stevens Institute of Technology, Class of 2015 Major in Computer Science www.whizkidztech.com | tylerromeo@gmail.com
On Sun, Oct 14, 2012 at 9:26 PM, Mark A. Hershberger <mah@everybody.org
wrote:
I said I would lay out my thoughts regarding MW releases this weekend, so here goes.
First: I want to provide a regular schedule so users know what to expect, but something that a volunteer (me, for now) can achieve.
Second: I want to provide something that Linux distributors can incorporate into their distributions.
To fulfill the first point, I think a release twice a year -- like Ubuntu releases -- makes a lot of sense. This schedule also works for Linux distributors like Ubuntu, Fedora, and OpenSuSE
Since I started out using Debian (which has now adopted a 2 year freeze cycle), I think it also makes sense to provide LTS support. Platonides and I (but mostly Platonides) have been working with the Debian developers to get 1.19 into Wheezy which was frozen in June.
With that in mind, here is what I propose:
1.18.0 | Security updates till 1.20 1.19.x | April 2012 (LTS) 1.20.0 | October 2012 1.21.0 | April 2013 (Start in May) 1.22.0 | October 2013 (Start in September) 1.23.0 | April 2014 (LTS) 1.24.0 | October 2014 1.25.0 | April 2015 1.26.0 | October 2015 1.27.0 | April 2016 (LTS)
LTS releases will updates until (at least) the next LTS release. This means security updates, but other updates that don't require schema changes if people are interested in providing them. Since a couple of people have put the 1.20.0 milestone on a handful of bugs, I'm assuming now that they think those are worth merging to the 1.20 series. I'd like to get the fixes backported to 1.19 as well, if possible.
Well, that's pretty much it what I was thinking. How does this sound to you guys?
Any time you have "one overriding idea", and push your idea as a superior ideology, you're going to be wrong. ... The fact is, reality is complicated -- Linus Torvalds http://hexm.de/mc
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
On 10/14/2012 09:29 PM, Tyler Romeo wrote:
I also think we should have better plans on what is actually going to be in each release. In other words, a site administrator should be able to know what new features are planned for the next release before the actual release has been made. Maybe this already happens and I just don't know where this resource is.
Makes sense, and Chad points to the RELEASE-NOTES file as the place to look for this.
That file is updated regularly by the MW developers. Maybe it does the job you're looking for. Have you seen the file? RELEASE-NOTES-1.21 was just recently started and you can see it on Gerrit[0].
Is this what you're talking about?
[0-short] http://hexm.de/mn [0-long] https://gerrit.wikimedia.org/r/gitweb?p=mediawiki/core.git;a=blob;f=RELEASE-NOTES-1.21
I am aware of the RELEASE-NOTES file. However, it is only updated once a feature has been merged into the codebase, There should be some general idea of at least what is planned for a release before the code is actually written. *--* *Tyler Romeo* Stevens Institute of Technology, Class of 2015 Major in Computer Science www.whizkidztech.com | tylerromeo@gmail.com
On Tue, Oct 16, 2012 at 10:00 AM, Mark A. Hershberger mah@everybody.orgwrote:
On 10/14/2012 09:29 PM, Tyler Romeo wrote:
I also think we should have better plans on what is actually going to be in each release. In other words, a site administrator should be able to know what new features are planned for the next release before the actual release
has
been made. Maybe this already happens and I just don't know where this resource is.
Makes sense, and Chad points to the RELEASE-NOTES file as the place to look for this.
That file is updated regularly by the MW developers. Maybe it does the job you're looking for. Have you seen the file? RELEASE-NOTES-1.21 was just recently started and you can see it on Gerrit[0].
Is this what you're talking about?
[0-short] http://hexm.de/mn [0-long] < https://gerrit.wikimedia.org/r/gitweb?p=mediawiki/core.git;a=blob;f=RELEASE-...
Any time you have "one overriding idea", and push your idea as a superior ideology, you're going to be wrong. ... The fact is, reality is complicated -- Linus Torvalds http://hexm.de/mc
On 10/16/2012 11:45 AM, Tyler Romeo wrote:
There should be some general idea of at least what is planned for a release before the code is actually written.
This would mean getting any non-WMF contributors (the volunteers) to spec out what they planned to work on before hand and be committed to actually delivering it.
I'm not sure that is realistic.
It is realistic is getting a schedule for WMF-sponsored work, but a good deal of that is not going to interest the average MW admin since it is focused on Wikipedia.
As a sort of compromise, maybe we could write up a list of new features MediaWiki administrators would find useful a month before the release is planned. By that time, we've got a very good idea of what is going to be in it.
It could be that I'm just too pessimistic, but I think that comes from my introduction to the term "Cookie-Licking".
Mark.
As a sort of compromise, maybe we could write up a list of new features MediaWiki administrators would find useful a month before the release is planned. By that time, we've got a very good idea of what is going to be in it.
This seems like a good idea. Even if we never follow through with every plan, the primary reason I think we need something like this is so administrators can see what we're thinking about doing, and (possibly) provide feedback on that. For example, if a sysadmin sees that OAuth is on the list, they may come and say "This is awesome. You guys should totally do OAuth." or something along those lines.
*--* *Tyler Romeo* Stevens Institute of Technology, Class of 2015 Major in Computer Science www.whizkidztech.com | tylerromeo@gmail.com
On Tue, Oct 16, 2012 at 12:18 PM, Mark A. Hershberger mah@everybody.orgwrote:
On 10/16/2012 11:45 AM, Tyler Romeo wrote:
There should be some general idea of at least what is planned for a release before the code is
actually
written.
This would mean getting any non-WMF contributors (the volunteers) to spec out what they planned to work on before hand and be committed to actually delivering it.
I'm not sure that is realistic.
It is realistic is getting a schedule for WMF-sponsored work, but a good deal of that is not going to interest the average MW admin since it is focused on Wikipedia.
As a sort of compromise, maybe we could write up a list of new features MediaWiki administrators would find useful a month before the release is planned. By that time, we've got a very good idea of what is going to be in it.
It could be that I'm just too pessimistic, but I think that comes from my introduction to the term "Cookie-Licking".
Mark.
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
On Tue, Oct 16, 2012 at 12:18 PM, Mark A. Hershberger mah@everybody.org wrote:
On 10/16/2012 11:45 AM, Tyler Romeo wrote:
There should be some general idea of at least what is planned for a release before the code is actually written.
This would mean getting any non-WMF contributors (the volunteers) to spec out what they planned to work on before hand and be committed to actually delivering it.
I'm not sure that is realistic.
It is realistic is getting a schedule for WMF-sponsored work, but a good deal of that is not going to interest the average MW admin since it is focused on Wikipedia.
As a sort of compromise, maybe we could write up a list of new features MediaWiki administrators would find useful a month before the release is planned. By that time, we've got a very good idea of what is going to be in it.
It could be that I'm just too pessimistic, but I think that comes from my introduction to the term "Cookie-Licking".
Indeed, I agree on all the points here. Lots of things happen in development because somebody has been working on something and then commits it. This is perfectly ok--we don't want to discourage anyone by saying "That's not on the plan."
I think the idea of starting the general release notes maybe a month (or two) out from release is a good idea. It allows the release to start taking shape and we can start targeting a sane branch point. It also would happen when we generally start to "slush" master and ask people to hold off on earth-shattering changes since a branch point is coming up.
-Chad
I like the idea of LTS releases which are very useful in enterprise environments with focus on stability and maintenance.
We typically build our MediaWiki Enterprise stacks on Ubuntu Server LTS...
/Alexander
Am 15.10.2012 03:26, schrieb Mark A. Hershberger:
I said I would lay out my thoughts regarding MW releases this weekend, so here goes.
First: I want to provide a regular schedule so users know what to expect, but something that a volunteer (me, for now) can achieve.
Second: I want to provide something that Linux distributors can incorporate into their distributions.
To fulfill the first point, I think a release twice a year -- like Ubuntu releases -- makes a lot of sense. This schedule also works for Linux distributors like Ubuntu, Fedora, and OpenSuSE
Since I started out using Debian (which has now adopted a 2 year freeze cycle), I think it also makes sense to provide LTS support. Platonides and I (but mostly Platonides) have been working with the Debian developers to get 1.19 into Wheezy which was frozen in June.
With that in mind, here is what I propose:
1.18.0 | Security updates till 1.20 1.19.x | April 2012 (LTS) 1.20.0 | October 2012 1.21.0 | April 2013 (Start in May) 1.22.0 | October 2013 (Start in September) 1.23.0 | April 2014 (LTS) 1.24.0 | October 2014 1.25.0 | April 2015 1.26.0 | October 2015 1.27.0 | April 2016 (LTS)
LTS releases will updates until (at least) the next LTS release. This means security updates, but other updates that don't require schema changes if people are interested in providing them. Since a couple of people have put the 1.20.0 milestone on a handful of bugs, I'm assuming now that they think those are worth merging to the 1.20 series. I'd like to get the fixes backported to 1.19 as well, if possible.
Well, that's pretty much it what I was thinking. How does this sound to you guys?
On 10/16/2012 10:43 AM, planetenxin wrote:
I like the idea of LTS releases which are very useful in enterprise environments with focus on stability and maintenance.
We typically build our MediaWiki Enterprise stacks on Ubuntu Server LTS..
How many of these stacks do you deploy? Would you be willing to help with the MW LTS releases?
wikitech-l@lists.wikimedia.org