Hey,
I want to make several structural changes to the new installer, to make it fit in a more general deployment model. This will involve moving code and renaming things. Does anyone have objections to me doing this? (I don't want to undermine work people are currently doing.)
Cheers
-- Jeroen De Dauw * http://blog.bn2vs.com * http://wiki.bn2vs.com Don't panic. Don't be evil. 50 72 6F 67 72 61 6D 6D 69 6E 67 20 34 20 6C 69 66 65! --
On 20.07.2010, 13:08 Jeroen wrote:
Hey,
I want to make several structural changes to the new installer, to make it fit in a more general deployment model. This will involve moving code and renaming things. Does anyone have objections to me doing this? (I don't want to undermine work people are currently doing.)
Cheers
Hard to tell without knowing what you're proposing:)
Hey,
Basically splitting core-specific stuff from general installer functionality (so the general stuff can also be used for extensions). Also making initial steps towards filesystem upgrades possible.
The point of this mail is not discussing what I want to do though, but rather avoiding commit conflicts, as I don't know which people are working on the code right now, and who has uncommitted changes.
Cheers
-- Jeroen De Dauw * http://blog.bn2vs.com * http://wiki.bn2vs.com Don't panic. Don't be evil. 50 72 6F 67 72 61 6D 6D 69 6E 67 20 34 20 6C 69 66 65! --
On 20 July 2010 11:14, Max Semenik maxsem.wiki@gmail.com wrote:
On 20.07.2010, 13:08 Jeroen wrote:
Hey,
I want to make several structural changes to the new installer, to make
it
fit in a more general deployment model. This will involve moving code and renaming things. Does anyone have objections to me doing this? (I don't
want
to undermine work people are currently doing.)
Cheers
Hard to tell without knowing what you're proposing:)
-- Best regards, Max Semenik ([[User:MaxSem]])
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
On Tue, Jul 20, 2010 at 5:28 AM, Jeroen De Dauw jeroendedauw@gmail.com wrote:
Hey,
Basically splitting core-specific stuff from general installer functionality (so the general stuff can also be used for extensions). Also making initial steps towards filesystem upgrades possible.
The point of this mail is not discussing what I want to do though, but rather avoiding commit conflicts, as I don't know which people are working on the code right now, and who has uncommitted changes.
Cheers
-- Jeroen De Dauw
Don't panic. Don't be evil. 50 72 6F 67 72 61 6D 6D 69 6E 67 20 34 20 6C 69 66 65! --
It really depends on the change, and I'd rather review diffs on this before applying them to new-installer. It's pretty feature-complete and we're in the bugfixing stage. I'd rather not introduce a *whole* lot of new code; a branch might be better suited until 1.17 is branched, then could quickly be integrated into trunk (1.18alpha?). That being said, feel free to ask. Good code is good code and if things can be put in easily and quickly them I'm for it.
On a more general note, the reason I'm being cautious is this: 1.16 saw a lot of feature creep. Part of the reason it took so long was a lack of reviewing manpower with Brion gone. The other reason is because developers just kept shoving more features in (myself included). With no 1.16 deadline looming, it was easy to keep adding new features to the release...delaying it even more. When I took up new-installer, I started down the same road with the schema abstraction work. It quickly grew out of scope and was moved to a branch.
An actual roadmap would help solve these issues, but I'm getting OT :)
-Chad
On 20/07/10 19:28, Jeroen De Dauw wrote:
Hey,
Basically splitting core-specific stuff from general installer functionality (so the general stuff can also be used for extensions). Also making initial steps towards filesystem upgrades possible.
The point of this mail is not discussing what I want to do though, but rather avoiding commit conflicts, as I don't know which people are working on the code right now, and who has uncommitted changes.
There's still quite a lot of work to do to get the new installer ready for 1.17. I think we should focus on that, and avoid expanding the scope of the project until we've reached that milestone.
There are the issues discussed here:
http://www.mediawiki.org/wiki/New-installer_issues
and more will become apparent as more testing is done.
If the new installer is not ready to replace the old installer when it comes time to branch 1.17, I will move it out of trunk, back to a development branch. Hopefully that won't be necessary.
-- Tim Starling
Hey,
Unless the installer needs to be ready within a week for 1.17 I don't see any issues.
I want to make structural changes, not add new features. The sooner these are made, the less overall work my GSoC project will be.
As I'll be doing all the work on these changes, and am not skipping any other work on the new installer to do so, the progress on the new installer should not be impacted negatively.
Cheers
-- Jeroen De Dauw * http://blog.bn2vs.com * http://wiki.bn2vs.com Don't panic. Don't be evil. 50 72 6F 67 72 61 6D 6D 69 6E 67 20 34 20 6C 69 66 65! --
On 21 July 2010 04:40, Tim Starling tstarling@wikimedia.org wrote:
On 20/07/10 19:28, Jeroen De Dauw wrote:
Hey,
Basically splitting core-specific stuff from general installer
functionality
(so the general stuff can also be used for extensions). Also making
initial
steps towards filesystem upgrades possible.
The point of this mail is not discussing what I want to do though, but rather avoiding commit conflicts, as I don't know which people are
working
on the code right now, and who has uncommitted changes.
There's still quite a lot of work to do to get the new installer ready for 1.17. I think we should focus on that, and avoid expanding the scope of the project until we've reached that milestone.
There are the issues discussed here:
http://www.mediawiki.org/wiki/New-installer_issues
and more will become apparent as more testing is done.
If the new installer is not ready to replace the old installer when it comes time to branch 1.17, I will move it out of trunk, back to a development branch. Hopefully that won't be necessary.
-- Tim Starling
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Tim Starling wrote:
There's still quite a lot of work to do to get the new installer ready for 1.17. I think we should focus on that, and avoid expanding the scope of the project until we've reached that milestone.
There are the issues discussed here:
http://www.mediawiki.org/wiki/New-installer_issues
and more will become apparent as more testing is done.
If the new installer is not ready to replace the old installer when it comes time to branch 1.17, I will move it out of trunk, back to a development branch. Hopefully that won't be necessary.
-- Tim Starling
We should probably ship both installers in 1.17. I wouldn't be surprised if it some odd configurations in the wild made it not work.
wikitech-l@lists.wikimedia.org