You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@isis.apache.org by Dan Haywood <dk...@gmail.com> on 2010/12/01 01:24:54 UTC
r0.1 tracking in JIRA
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
Re: r0.1 tracking in JIRA
Posted by Kevin Meyer <ke...@kmz.co.za>.
Sounds good to me (+1).
> The proposal for the 0.1 release is to create a JIRA ticket for each of
> the following:
>
> Alternatives: ObjectStore: SQL (Lead: Kevin Meyer)
>
> 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
>
> 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.
Re: r0.1 tracking in JIRA
Posted by Kevin Meyer <ke...@kmz.co.za>.
Bernd,
While I 100% agree with you, the choice of label is not 100% trivial
either.
I have an occasional interest in words and enjoy thinking about
one or the other, especially when there is a choice.. but don't let
this distract from the real issues.
On Wed, December 1, 2010 16:17, Mohammad Nour El-Din wrote:
> +1 @ Bernd
>
> /me At last I found something ti agree upon with Bernd :P
>
>>> What do you think?
>>
>> I think that this discussion is going into the wrong direction,
>> whatever you call it, be it lead, FPoC, maintainer, whatever.
>> In practice, of course, committer A will work more on code subset A1
>> and B on B1. But this should really be the committer's (daily) choice,
>> and not be carved in stone.
>>
Re: r0.1 tracking in JIRA
Posted by Mohammad Nour El-Din <no...@gmail.com>.
+1 @ Bernd
/me At last I found something ti agree upon with Bernd :P
On Wed, Dec 1, 2010 at 3:54 PM, Bernd Fondermann
<be...@googlemail.com> wrote:
> On Wed, Dec 1, 2010 at 13:11, Kevin Meyer <ke...@kmz.co.za> wrote:
>>
>> Hmm - I'd have to disagree - unless maintainer means something else
>> in "Developer English", to me, a maintainer (again) does work, and
>> possibly "owns", whereas co-ordinator just co-ordinates. ;)
>>
>> In this case, the [insert word here] *are* currently actively doing
>> the work, but this need not always be the case... and the goal is
>> to get to the stage where the [insert word here] (at most) oversees
>> the contributions and ensures that the module functionality is not
>> being compromised/degraded (for example)..
>>
>> But yes, they are also the first point of contact, should anyone
>> require help regarding either usage (as an application developer) or
>> guidance (as a framework developer).
>>
>> Finally, if someone breaks a module, a maintainer would be expected
>> to fix it, but a co-ordinator would just tell the person who broke it
>> to do so! ;0
>>
>> What do you think?
>
> I think that this discussion is going into the wrong direction,
> whatever you call it, be it lead, FPoC, maintainer, whatever.
> In practice, of course, committer A will work more on code subset A1
> and B on B1. But this should really be the committer's (daily) choice,
> and not be carved in stone.
>
> Bernd
>
--
Thanks
- Mohammad Nour
Author of (WebSphere Application Server Community Edition 2.0 User Guide)
http://www.redbooks.ibm.com/abstracts/sg247585.html
- LinkedIn: http://www.linkedin.com/in/mnour
- Blog: http://tadabborat.blogspot.com
----
"Life is like riding a bicycle. To keep your balance you must keep moving"
- Albert Einstein
"Writing clean code is what you must do in order to call yourself a
professional. There is no reasonable excuse for doing anything less
than your best."
- Clean Code: A Handbook of Agile Software Craftsmanship
"Stay hungry, stay foolish."
- Steve Jobs
Re: r0.1 tracking in JIRA
Posted by Bernd Fondermann <be...@googlemail.com>.
On Wed, Dec 1, 2010 at 13:11, Kevin Meyer <ke...@kmz.co.za> wrote:
>
> Hmm - I'd have to disagree - unless maintainer means something else
> in "Developer English", to me, a maintainer (again) does work, and
> possibly "owns", whereas co-ordinator just co-ordinates. ;)
>
> In this case, the [insert word here] *are* currently actively doing
> the work, but this need not always be the case... and the goal is
> to get to the stage where the [insert word here] (at most) oversees
> the contributions and ensures that the module functionality is not
> being compromised/degraded (for example)..
>
> But yes, they are also the first point of contact, should anyone
> require help regarding either usage (as an application developer) or
> guidance (as a framework developer).
>
> Finally, if someone breaks a module, a maintainer would be expected
> to fix it, but a co-ordinator would just tell the person who broke it
> to do so! ;0
>
> What do you think?
I think that this discussion is going into the wrong direction,
whatever you call it, be it lead, FPoC, maintainer, whatever.
In practice, of course, committer A will work more on code subset A1
and B on B1. But this should really be the committer's (daily) choice,
and not be carved in stone.
Bernd
Re: r0.1 tracking in JIRA
Posted by Kevin Meyer <ke...@kmz.co.za>.
Hmm - I'd have to disagree - unless maintainer means something else
in "Developer English", to me, a maintainer (again) does work, and
possibly "owns", whereas co-ordinator just co-ordinates. ;)
In this case, the [insert word here] *are* currently actively doing
the work, but this need not always be the case... and the goal is
to get to the stage where the [insert word here] (at most) oversees
the contributions and ensures that the module functionality is not
being compromised/degraded (for example)..
But yes, they are also the first point of contact, should anyone
require help regarding either usage (as an application developer) or
guidance (as a framework developer).
Finally, if someone breaks a module, a maintainer would be expected
to fix it, but a co-ordinator would just tell the person who broke it
to do so! ;0
What do you think?
co-ordinate[1]: to synchronise
maintain[2]: to keep up; to preserve
PS: A lot of tongue in cheek, in case you were wondering, but
I do prefer coordinator of maintainer, for the stated reasons.
On Wed, December 1, 2010 13:55, Mohammad Nour El-Din wrote:
> You could have said Maintainer ;)
>
> On Wed, Dec 1, 2010 at 1:43 PM, Bernd Fondermann
> <be...@googlemail.com> wrote:
>> On Wed, Dec 1, 2010 at 12:00, Mark Struberg <st...@yahoo.de> wrote:
>>> use the word 'coordinator' than?
>>
>> +1. Couldn't have phrased it any better.
[1] http://en.wiktionary.org/wiki/coordinate
[2] http://en.wiktionary.org/wiki/maintain
Re: r0.1 tracking in JIRA
Posted by Mohammad Nour El-Din <no...@gmail.com>.
You could have said Maintainer ;)
On Wed, Dec 1, 2010 at 1:43 PM, Bernd Fondermann
<be...@googlemail.com> wrote:
> On Wed, Dec 1, 2010 at 12:00, Mark Struberg <st...@yahoo.de> wrote:
>> use the word 'coordinator' than?
>> Words are for sure important, but even more important is imo how the community _acts_. And that worked pretty well so far (attracting 3 new contributors itmt).
>
> +1. Couldn't have phrased it any better.
>
> Bernd
>
--
Thanks
- Mohammad Nour
Author of (WebSphere Application Server Community Edition 2.0 User Guide)
http://www.redbooks.ibm.com/abstracts/sg247585.html
- LinkedIn: http://www.linkedin.com/in/mnour
- Blog: http://tadabborat.blogspot.com
----
"Life is like riding a bicycle. To keep your balance you must keep moving"
- Albert Einstein
"Writing clean code is what you must do in order to call yourself a
professional. There is no reasonable excuse for doing anything less
than your best."
- Clean Code: A Handbook of Agile Software Craftsmanship
"Stay hungry, stay foolish."
- Steve Jobs
Re: r0.1 tracking in JIRA
Posted by Bernd Fondermann <be...@googlemail.com>.
On Wed, Dec 1, 2010 at 12:00, Mark Struberg <st...@yahoo.de> wrote:
> use the word 'coordinator' than?
> Words are for sure important, but even more important is imo how the community _acts_. And that worked pretty well so far (attracting 3 new contributors itmt).
+1. Couldn't have phrased it any better.
Bernd
Re: r0.1 tracking in JIRA
Posted by Mark Struberg <st...@yahoo.de>.
use the word 'coordinator' than?
Words are for sure important, but even more important is imo how the community _acts_. And that worked pretty well so far (attracting 3 new contributors itmt).
LieGrue,
strub
--- On Wed, 12/1/10, Dan Haywood <dk...@gmail.com> wrote:
> From: Dan Haywood <dk...@gmail.com>
> Subject: Re: r0.1 tracking in JIRA
> To: "Bernd Fondermann" <be...@googlemail.com>
> Cc: isis-dev@incubator.apache.org
> Date: Wednesday, December 1, 2010, 10:27 AM
> 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<dk...@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
> >>
> >>
> >>
>
Re: r0.1 tracking in JIRA
Posted by Dan Haywood <dk...@gmail.com>.
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<dk...@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
>>
>>
>>
Re: r0.1 tracking in JIRA
Posted by Bernd Fondermann <be...@googlemail.com>.
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 <dk...@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
>
>
>