You are viewing a plain text version of this content. The canonical link for it is here.
Posted to kato-dev@incubator.apache.org by Steve Poole <sp...@googlemail.com> on 2009/01/11 17:09:30 UTC
Kato Infrastructure setup - list to discuss
Hi,
Having got the holiday season out of the way I'd like to push now on getting
the Kato project moving. The infrastructure items that need
completing/discussing are
1. Creating a Wiki. I vote for a Confluence flavor of wiki rather than
MoinMoin. Apparently from this page (
http://cwiki.apache.org/CWIKI/#Index-HowdowerequestaCWIKISpace%253F) the
CWIKI guys would like a PMC member to take the admin role. The name of the
space would be "kato" presumably :-)
2. Create components in the Kato Jira instance. We have the following
obvious areas - is this a reasonable split?
- Test Compliance Kit. Items under this component would cover TCK
development and issues arrising about execution validity.
- API specification - items here would cover user story creation,
bugs in the spec and spec development
- Reference Implementation (nuf said)
- Test Harness. The TCK is only one part of the test suite. What we
are developing needs a complex test setup and execution environment - its
big enough to need its own component
3. Create at least two versions in the Kato Jira Instance. We have an
obvious 1.0 delivery version and a need for somewhere to store items that
will happen after that. Not sure if there is any standard form?
4. SVN repository needs basic trunk/branches/tags structure setup
5. For spec development we would like to provide the JSR Expert Group
members with the oppotunity to be able to contribute directly to the
specification (ie the API interface classes ) and to the TCK testsuite.
Some of the EG members cannot contribute to the RI development directly (due
to IP issues with exposure to Sun JVM internals) and so I'd like to explore
how we can resolve this?
6. We need a website for Kato setup - I don't have much exposure to the
alternatives proposed - which is best ? or do we roll our own?. Note that
we need to publish the API spec (in the form of javadoc pages) and the
binaries that we create.
7. The kato website, once created will need to be linked-to in various
places on other ASF pages. We need a list of these places made and
eventually get our links inserted.
8. ASF have a Hudson server and I'd like to use it to do the build and
basic unit testing. We'll need a job on Hudson set up.
9. TCK testing is likely to be expensive in cpu terms. I don't know if
we can lean on ASF hardware for this activity. IBM has machines that are
already building and testing DTFJ and there is no problem with them being
used to build and test Kato for the duration of the JSR development. However
I'd like to be clear on what we need to do to ensure that the Kato project
has a good hardware story for the future.
Thoughts?
Thanks
Steve
Re: Kato Infrastructure setup - list to discuss
Posted by Sonal Goyal <so...@gmail.com>.
Hi Steve,
From what I understand, we can follow the steps at
http://incubator.apache.org/guides/website.html
<http://incubator.apache.org/guides/website.html>
and add the project status report with the website link. The project link
would automatically get inserted into the incubator site, and Clutch should
be able to use this info as well.
Thanks and Regards,
Sonal
On Sun, Jan 11, 2009 at 10:39 PM, Steve Poole <sp...@googlemail.com>wrote:
> Hi,
>
> Having got the holiday season out of the way I'd like to push now on
> getting
> the Kato project moving. The infrastructure items that need
> completing/discussing are
>
>
> 1. Creating a Wiki. I vote for a Confluence flavor of wiki rather than
> MoinMoin. Apparently from this page (
> http://cwiki.apache.org/CWIKI/#Index-HowdowerequestaCWIKISpace%253F) the
> CWIKI guys would like a PMC member to take the admin role. The name of
> the
> space would be "kato" presumably :-)
> 2. Create components in the Kato Jira instance. We have the following
> obvious areas - is this a reasonable split?
> - Test Compliance Kit. Items under this component would cover TCK
> development and issues arrising about execution validity.
> - API specification - items here would cover user story creation,
> bugs in the spec and spec development
> - Reference Implementation (nuf said)
> - Test Harness. The TCK is only one part of the test suite. What we
> are developing needs a complex test setup and execution environment -
> its
> big enough to need its own component
> 3. Create at least two versions in the Kato Jira Instance. We have an
> obvious 1.0 delivery version and a need for somewhere to store items that
> will happen after that. Not sure if there is any standard form?
> 4. SVN repository needs basic trunk/branches/tags structure setup
> 5. For spec development we would like to provide the JSR Expert Group
> members with the oppotunity to be able to contribute directly to the
> specification (ie the API interface classes ) and to the TCK testsuite.
> Some of the EG members cannot contribute to the RI development directly
> (due
> to IP issues with exposure to Sun JVM internals) and so I'd like to
> explore
> how we can resolve this?
> 6. We need a website for Kato setup - I don't have much exposure to the
> alternatives proposed - which is best ? or do we roll our own?. Note
> that
> we need to publish the API spec (in the form of javadoc pages) and the
> binaries that we create.
> 7. The kato website, once created will need to be linked-to in various
> places on other ASF pages. We need a list of these places made and
> eventually get our links inserted.
> 8. ASF have a Hudson server and I'd like to use it to do the build and
> basic unit testing. We'll need a job on Hudson set up.
> 9. TCK testing is likely to be expensive in cpu terms. I don't know if
> we can lean on ASF hardware for this activity. IBM has machines that are
> already building and testing DTFJ and there is no problem with them being
> used to build and test Kato for the duration of the JSR development.
> However
> I'd like to be clear on what we need to do to ensure that the Kato
> project
> has a good hardware story for the future.
>
>
> Thoughts?
>
> Thanks
>
> Steve
>
Re: Kato Infrastructure setup - list to discuss
Posted by Stuart Monteith <st...@stoo.me.uk>.
Great, thanks Robert. I shall send such an email forthwith!
Stuart
On 20 Jan 2009, at 19:19, Robert Burrell Donkin wrote:
> On Tue, Jan 20, 2009 at 1:32 PM, Stuart Monteith
> <st...@stoo.me.uk> wrote:
>> Hi,
>> I think it would be good to get a Wiki up and running soon. I like
>> the
>> look of Confluence - having fine grained
>> control over access to the Wiki could be beneficial with our
>> interaction
>> with the JSR expert group.
>>
>> If nobody objects, can I ask either Robert or Ant (our PMC members)
>> to open
>> a ticket on Jira INFRA to create a Confluence Wiki?
>
> we're around on list ;-)
>
> just needs a consensus that confluence is the right way to go. one way
> would be to put it to a formal vote (just start a new thread with a
> [VOTE] prefix and include a vote template eg.
>
> --8<----------------------------------------------------------
> [ ] +1 Foo Bar!
> [ ] +0
> [ ] -0
> [ ] -1 No Foo Bar!
> ----------------------------------------------------------------
>
> ) though show of hands would be good enough (just people replying with
> +1 or -1).
>
> BTW it's quite important on apache lists that people who agree reply
> with a +1 even if they have nothing more to add: it allows people to
> understand whether that there's consensus on an issue rather than just
> apathy. you'll also see people reply +0 or -0 indicating that they
> mildly support the measure (or not) but don't really have the energy
> to strongly help (or create an alternative).
>
> - robert
Re: Kato Infrastructure setup - list to discuss
Posted by Robert Burrell Donkin <ro...@gmail.com>.
On Tue, Jan 20, 2009 at 1:32 PM, Stuart Monteith <st...@stoo.me.uk> wrote:
> Hi,
> I think it would be good to get a Wiki up and running soon. I like the
> look of Confluence - having fine grained
> control over access to the Wiki could be beneficial with our interaction
> with the JSR expert group.
>
> If nobody objects, can I ask either Robert or Ant (our PMC members) to open
> a ticket on Jira INFRA to create a Confluence Wiki?
we're around on list ;-)
just needs a consensus that confluence is the right way to go. one way
would be to put it to a formal vote (just start a new thread with a
[VOTE] prefix and include a vote template eg.
--8<----------------------------------------------------------
[ ] +1 Foo Bar!
[ ] +0
[ ] -0
[ ] -1 No Foo Bar!
----------------------------------------------------------------
) though show of hands would be good enough (just people replying with
+1 or -1).
BTW it's quite important on apache lists that people who agree reply
with a +1 even if they have nothing more to add: it allows people to
understand whether that there's consensus on an issue rather than just
apathy. you'll also see people reply +0 or -0 indicating that they
mildly support the measure (or not) but don't really have the energy
to strongly help (or create an alternative).
- robert
Re: Kato Infrastructure setup - list to discuss
Posted by Stuart Monteith <st...@stoo.me.uk>.
Hi,
I think it would be good to get a Wiki up and running soon. I like
the look of Confluence - having fine grained
control over access to the Wiki could be beneficial with our interaction
with the JSR expert group.
If nobody objects, can I ask either Robert or Ant (our PMC members) to
open a ticket on Jira INFRA to
create a Confluence Wiki? I look the look of the OpenJPA site -
exporting static HTML from Confluence
looks ok.
Thanks,
Stuart
Steve Poole wrote:
> Hi,
>
> Having got the holiday season out of the way I'd like to push now on getting
> the Kato project moving. The infrastructure items that need
> completing/discussing are
>
>
> 1. Creating a Wiki. I vote for a Confluence flavor of wiki rather than
> MoinMoin. Apparently from this page (
> http://cwiki.apache.org/CWIKI/#Index-HowdowerequestaCWIKISpace%253F) the
> CWIKI guys would like a PMC member to take the admin role. The name of the
> space would be "kato" presumably :-)
> 2. Create components in the Kato Jira instance. We have the following
> obvious areas - is this a reasonable split?
> - Test Compliance Kit. Items under this component would cover TCK
> development and issues arrising about execution validity.
> - API specification - items here would cover user story creation,
> bugs in the spec and spec development
> - Reference Implementation (nuf said)
> - Test Harness. The TCK is only one part of the test suite. What we
> are developing needs a complex test setup and execution environment - its
> big enough to need its own component
> 3. Create at least two versions in the Kato Jira Instance. We have an
> obvious 1.0 delivery version and a need for somewhere to store items that
> will happen after that. Not sure if there is any standard form?
> 4. SVN repository needs basic trunk/branches/tags structure setup
> 5. For spec development we would like to provide the JSR Expert Group
> members with the oppotunity to be able to contribute directly to the
> specification (ie the API interface classes ) and to the TCK testsuite.
> Some of the EG members cannot contribute to the RI development directly (due
> to IP issues with exposure to Sun JVM internals) and so I'd like to explore
> how we can resolve this?
> 6. We need a website for Kato setup - I don't have much exposure to the
> alternatives proposed - which is best ? or do we roll our own?. Note that
> we need to publish the API spec (in the form of javadoc pages) and the
> binaries that we create.
> 7. The kato website, once created will need to be linked-to in various
> places on other ASF pages. We need a list of these places made and
> eventually get our links inserted.
> 8. ASF have a Hudson server and I'd like to use it to do the build and
> basic unit testing. We'll need a job on Hudson set up.
> 9. TCK testing is likely to be expensive in cpu terms. I don't know if
> we can lean on ASF hardware for this activity. IBM has machines that are
> already building and testing DTFJ and there is no problem with them being
> used to build and test Kato for the duration of the JSR development. However
> I'd like to be clear on what we need to do to ensure that the Kato project
> has a good hardware story for the future.
>
>
> Thoughts?
>
> Thanks
>
> Steve
>
>