On Tue, Jul 20, 2010 at 5:28 AM, Jeroen De Dauw <jeroendedauw(a)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
*
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!
--
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