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