Re: MidCOM and its further adaption to new Midgard versions - AKA Midgard core quality
Piotras <pp-VVDi8QVAvoBWk0Htik3J/[email protected]> Wed, 8 Feb 2006 17:24:00 +0100
| Newsgroups | gmane.comp.web.midgard.devel |
|---|---|
| Message-ID | <[email protected]> |
Jukka Zitting <[email protected]> wrote: > > Hereby I officially cease to support any 1.8 version/feature in the current > > MidCOM CVS codebase or any future development thereoff in any part of the core > > (/lib/midcom/*), unless: > > +1, I share your concerns. > > BR, > > Jukka Zitting Ok , guys. I will provide more documented and detailed developemnt plans only if: 1. Midgard-php developers will be more active in midgard-php devlopment cycle. By "active" I mean * more feedback after using CVS versions of midgard * focusing on *language possibilities* 2. mRFC like 0024 or 0022 will focus on details insetad of ideas Currently both mRFC require other mRFCs ( at least 5 each ) which are mandatory to make changes in core. Each of this mRFC doesn't provide any information how much other features should be changed or rewritten to make described idea to be working. I ( as a core devloper ) have no idea how and when and why core should be changed to follow such mRFC. None of this mRFC describe real API anyway. 3. No mRFC like 0016 will be written. There is huge difference between theory and practice. 4. There will be no more discussions like proposed by me about midgard_object_property ( replaced with midgard_reflection_property ) because ( again ) there is huge difference between theory and practice. 5. I am not going to make more releases if developers expect features in release X and those are planned ( or depend on ) (features from) or release Y. 6. More details , less ideas ( including mRFC for core ). 7. <joke> someone is going to give me an url to *good* zend docs </joke> 8. Someone must decide if we want 1.8 at last or delete old code now and start working on 2.0 release ( without any sheduled date defined ). 9. Language bindings developers will give me some detailed problems descriptions. Piotras