Hi Bernd,
It's a good point you make.
In the discussion thread I posted earlier on for v0.1, I was careful to
use the correct language... it's about ownership of a getting a
component ready for the v0.1 release, rather than owning it for all time.
For the list below, I copied out details from the JIRA system, where
there is a field for component owner which I've populated. I'm
wondering if I ought to blank it out?
On the other hand, we do want to be able to say: "this person knows the
most about such-and-such a module", without it completely being their
responsibility for ever more. Do you have any ideas on the best way to
do that?
Thx
Dan
On 01/12/2010 10:16, Bernd Fondermann wrote:
Note from the peanut gallery: Please make sure that 'lead' is not
interpreted as 'having code ownership', or 'is telling/demanding how
that specific part of the project should evolve'. Leaving modules
explicitly without a shepherd could attract new people to jump in -
and growing community is one of the goals of Incubation.
Thanks,
Bernd
On Wed, Dec 1, 2010 at 01:24, Dan Haywood<[email protected]> wrote:
All,
Nour, Rob and myself had an skype call yesterday evening regarding an
approach to manage the v0.1 release. The plan we came up with was to use
JIRA, with a ticket for each main component (or group of components). I'm
posting this here for visibility/comments.
The proposal for the 0.1 release is to create a JIRA ticket for each of the
following:
Core (Lead: Dan Haywood)
AppLib (Lead: Dan Haywood)
Defaults (Lead: Dan Haywood)
Alternatives: Bytecode (Lead: Dan Haywood)
Alternatives: Embedded (Lead: Dan Haywood)
Alternatives: ObjectStore: NoSQL (Lead: Robert Matthews)
Alternatives: ObjectStore: SQL (Lead: Kevin Meyer)
Alternatives: ObjectStore: XML (Lead: Robert Matthews)
Alternatives: ProfileStore: XML (Lead: Robert Matthews)
Alternatives: ProgModel: Groovy (Lead: Dan Haywood)
Alternatives: ProgModel: Wrapper (Lead: Dan Haywood)
Alternatives: Security: LDAP (Lead: Robert Matthews)
Viewer: BDD (Lead: Dan Haywood)
Viewer: DnD (Lead: Robert Matthews)
Viewer: HTML (Lead: Robert Matthews)
Viewer: JUnit (Lead: Dan Haywood)
Viewer: Restful (Lead: Dan Haywood)
Viewer: Scimpi (Lead: Robert Matthews)
Viewer: Wicket (Lead: Dan Haywood)
NB: this combines all the core components into a single ticket; all the
default components into a single ticket, it excludes jpa objectstore,
mongodb objectstore, and remoting.
Each of these tickets will be used to track the status of:
1- Documentation (docbook PDF + site APT)
2- Review package names, Maven artifacts IDs, copyright notices.
3- For the alternatives and viewers, should have a module in the
support/prototype project
We also need a ticket for the archetype itself, to reverse engineer from
support/prototype into an archetype.
When all of these tickets are complete, then - in theory - r0.1 will be
ready for release.
If everyone is happy with this, then Nour has volunteered to enter these
tickets into JIRA and to track the status through to v0.1 release.
Cheers
Dan