incubator-isis-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dan Haywood <dkhayw...@gmail.com>
Subject Re: r0.1 tracking in JIRA
Date Wed, 01 Dec 2010 10:27:04 GMT
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<dkhaywood@gmail.com>  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
>>
>>
>>

Mime
  • Unnamed multipart/mixed (inline, None, 0 bytes)
View raw message