2011/4/5 Marcel Offermans <[email protected]>: > On 5 Apr 2011, at 10:38 , Ivo Ladage-van Doorn wrote: > > I assigned project leads to the JIRA components based on our agreement of > last week. JIRA components match on Amdatu subprojects. > > Ok! > > Please let me know if something is missing or if I assigned a wrong person: > > Amdatu Auth (Lead: Ivo Ladage - van Doorn) > Amdatu Cassandra (Lead: Ivo Ladage - van Doorn) > Amdatu Core (Lead: Bram de Kruijff) > Amdatu Example > Amdatu OpenSocial (Lead: Ivo Ladage - van Doorn) > Amdatu Provisioning (Lead: Marcel Offermans) > Amdatu Search & Index (Lead: Ivo Ladage - van Doorn) > Amdatu Semantic (Lead: Angelo van der Sijpt) > Amdatu Sevice Fabric (Lead: Bram de Kruijff) > > Amdatu Testing - Integration (Lead: Ivo Ladage - van Doorn) > Amdatu Testing - Performance (Lead: Ivo Ladage - van Doorn) > > I'm not sure if we want to have one overall project for all tests, or have > integration tests as part of the subproject they belong to (or maybe both).
I'd suggest having them as part of subprojects to keep thing moving (not having to wait for or fix integration tests out of subproject scope). They'll get there own continuous integration and release cycles anyway. > Amdatu Web (Lead: Bram de Kruijff) > Build & Release management (Lead: Bram de Kruijff) > > Formally I think the build and release management (and probably also Amdatu > Core) is the responsibility of the PMC, but since we cannot assign more than > one lead in Jira that's fine. Yup, let'see what happens. I have no problem delegating some stuff to other PMC members. In fact wee can divide the JIRA projects to distribute the attention/work load? > I didn’t assign anyone to Example since I believe this should not be a > subproject nor a JIRA component (as an examples belong to a subproject). > > Agreed. In any case I doubt we will ever release examples, so they can > either just be part of the subproject they belong to, or live in a separate > sandbox. > > Furthermore, to ease the roadmap process, I added a field ‘Estimated Eng > Workload’, which can be used to provide an estimate for the amount of > manhours needed to resolve the issue. I also added versions 0.2.1 till 0.2.5 > and mapped them on release dates. This should provide the tools needed to > define the roadmap for the upcoming versions: > > 0.2.5 05/Dec/11 > 0.2.4 07/Nov/11 > 0.2.3 05/Sep/11 > 0.2.2 04/Jul/11 > 0.2.1 06/Jun/11 > 0.2.0 02/May/11 > > For determining the release dates I used release cycles of 1 month, except > for the summer months where I used cycles of 2 months (due to holidays). > > Three comments: > 1) I think we need to revisit versioning to align it with the semantic > versioning whitepaper of the OSGi alliance. That would mean we cannot have a > single version number for all bundles we release, and that's fine. > 2) Since each subproject will be split off, we still have to decide which > subproject to release when. Also, we probably first need input from the > board on the actual roadmap. > 3) In general, I would prefer releasing things "when they're done" instead > of trying to stick to some fixed schedule. Now I don't mind setting dates, > but that probably means that if a subproject is not in a releasable state by > then, or not all features have been added, it will either not be released at > all at that date, or released with only the stuff that's done. Agreed, let's get the decoupling/versioning and workbacklog clear before comitting anyway. > Greetings, Marcel grz Bram _______________________________________________ Amdatu-developers mailing list [email protected] http://lists.amdatu.org/mailman/listinfo/amdatu-developers
