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