A suggested roadmap
tarjei-y/[email protected] Thu, 09 Feb 2006 11:23:58 +0100
| Newsgroups | gmane.comp.web.midgard.devel |
|---|---|
| Message-ID | <[email protected]> |
Hi, reading the discussions on dev@ the last days I must say we got a lot o f work to do. Here's a suggested actionplan for moving forward it is not perfect. As I see it we got some core issues here we need to adress, mainly the way we work on and discuss development. We do have some clear comunication issues that we need to resolve. One exam ple is that Piotras tends to ask a question hoping for feedback but often just gets a "RESOLVE THIS!" reply. A lot of the issues that both Torben and Piotras c ome up with need to be decided on, not just mailed about. We also have problems with people having a bit more attitude than needed at times. Based on this I suggest the following roadmap for a roadmap towards 1.8 and 2.0: a) All features should be documented before we continue making new ones. This implies: * Making an mRFC for the features that have been implemented. See b) for how the mRFCs should be written. => There are real technical issues that must be solved here. b) Core MRFC's that provide new APIs should contain: * A description of the technical solution * Any apis that are related to the language bindings * PHP documentation so that the php documentation is complete. c) All language features should have a set of unittests in PHP. This should secure that we get less errors and we get a body of sample code. => I can probably write these if someone can provide some funding. d) To address the installation and build issues, we should make a buildserv er where midgard is built twice a day and all the unittests are run. This shou ld ensure we catch segfaults and errors early. => Someone must volunteer to provide a server (or vserver) for this. I go t a set of buildscripts that can be used to mæke the builds. e) We got a backlog of issues that need to be resolved. This backlog must b e documented (a lot of it is in bugreports) and worked on. A good example is the notices that come out of ->execute(). => This could be the job of a release engineer who doesn't code (jval?). Now, we also need a roadmap towards MidCOM 2.6, but that is another issue. Tarjei