Date
1 - 1 of 1
typo'ed the tsc mailing list on this: TSC status for the week of 08.05.2013
|
David Meyer <dmm@...>
---------- Forwarded message ---------- From: David Meyer <dmm@...> Date: Thu, Aug 8, 2013 at 12:08 PM Subject: TSC status for the week of 08.05.2013 To: board@... The TSC met on 08.08.2013. Major issues discussed included the establishment of a Development Process for ODP (see Section 6 of the TSC charter), standards for API consistency, and the Needs Analysis action item that Phil and I have from the Board.
In the case of the TSC's deliverable to the Board of a Development Process for ODP, the TSC presents the ODP Project Life Cycle for your approval [0] for your approval. Please let us know if you have questions or comments on this process. I will note that one thing that is not covered in the Project Life Cycle/Development Process is a description of coding standards for ODP. The TSC has decided to allow such standards to evolve over the time frame covering the first Simultaneous Release, and we expect such standards to firm up as we gain experience.
There was a far ranging discussion on the topic of API consistency. The TSC decided to start by providing API visibility in the form of a wiki on which APIs can be documented. It is envisioned that we will either put a "API review" milestone somewhere in either the release plan or perhaps in as a gate in future versions of the life cycle (or even more formal API governance if necessary), but as mentioned we are starting with visibility.
Finally, there was also a wide-ranging discussion of where ODP could use more resources (developers or otherwise). The clear gap that is of concern is QA/System Testing and Integration. Since the TSC is quite sensitive to whether is should be allocating resources (the clear consensus is that the TSC should *not* be allocating resources; instead, "resources follow interest" is the operating principle), we decided to build a wiki on which projects can essentially advertise for help. This will give folks who are just coming into the project a place to to find projects to work on to get started and will allow projects to fill their gaps. In addition, we discussed funding of continuous integration and release engineers; these are two different roles that likely aren't directly affiliated with any particular project and need some form of continuity (for example, spanning several Simultaneous Releases) to be effective.
Please let me know if you have questions or comments about any of the above. --dmm |
|
|