You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@river.apache.org by Patricia Shanahan <pa...@acm.org> on 2010/10/31 06:23:15 UTC
Graduation - Was Re: Praise for River Development team
On 10/30/2010 9:24 PM, Niclas Hedhman wrote:
> On Sat, Oct 30, 2010 at 2:36 PM, Peter Firmstone<ji...@zeus.net.au> wrote:
>> When the qa test suite are sorted, and we've tested on a number of
>> platforms, I'll release.
>
> Note; Code/QA quality is not a requirement for graduation. Community
> activity, collaboration and composition are.
Presumably, if we have an appropriate team working on River, we will get
code quality anyway. Is there any view of how large an active committer
community we need, and what skill range?
I assume we would be aiming to be a top level project, not transfer to
be a sub-project in another project.
I note that one of the requirements is "Developers tied into ASF PGP web
of trust". I've not yet worked out how to achieve this.
>> We've got a diverse background of developers, I agree with you, we're ready
>> for graduation, we've had two releases since River's inception.
>
> I think Jukka is an experience release manager from other projects, so
> if he remains active here, I am sure he can chip in with pointers if
> you run into trouble. IMHO, release not required for graduation.
>
> Another note; Apache has a PR department that are eager to send out
> note-worthy press releases, and claims that there is a lot of interest
> from "press" on what is happening in Apache. So, prior to graduation,
> contact Sally (VP, Marketing& Publicity) at press@apache.org, to work
> out a press release to coincide with http://river.apache.org (and
> mailing lists) going live. The sooner that starts the better...
> (within reason).
>
>
> Cheers
Re: Graduation - Was Re: Praise for River Development team
Posted by Peter Firmstone <ji...@zeus.net.au>.
Active committers:
Jonathan Costers
Tom Hobbs
Peter Firmstone
Sim was active on the list and working on Mekong jeri at the time.
Cheers Peter.
Benson Margulies wrote:
> Sim,
>
> We could put up a vote now, I think. What do the other mentors think?
> One question is how many of the current active participants were
> around for that release you cite.
>
> --benson
>
>
> On Sat, Nov 13, 2010 at 8:07 AM, Sim IJskes - QCG <si...@qcg.nl> wrote:
>
>> On 10/31/2010 12:50 PM, Benson Margulies wrote:
>>
>>> On the other hand, my fellow mentors, when they brought me into the
>>> picture, felt that a release would be a good capstone to moving River
>>> into an active state that would easily get a positive outcome from the
>>> IPMC.
>>>
>> Benson,
>>
>> what do you consider a release? Whe have already released 2.1.2. is there
>> anything missing what whe have overlooked?
>>
>> Or are you giving us 'the green light' when we would bring it to vote to the
>> IPMC?
>>
>> Gr. Sim
>>
>>
>
>
Re: Graduation - Was Re: Praise for River Development team
Posted by Peter Firmstone <ji...@zeus.net.au>.
Patricia Shanahan wrote:
> Tom Hobbs wrote:
>>> I know, and I know the list is so long that I just abbreviated "& Co",
>>> BUT I still maintain my opinion that you have been catalytic to get
>>> the project back on the right track...
>>
>> +1 agreed
>>
>
> +1
>
>
Thank you, neat to have started a snowball effect. But further thanks
for helping when I couldn't move that snowball by myself. ;)
Cheers,
Peter.
Re: Graduation - Was Re: Praise for River Development team
Posted by Patricia Shanahan <pa...@acm.org>.
Tom Hobbs wrote:
>> I know, and I know the list is so long that I just abbreviated "& Co",
>> BUT I still maintain my opinion that you have been catalytic to get
>> the project back on the right track...
>
> +1 agreed
>
+1
Re: Graduation - Was Re: Praise for River Development team
Posted by Tom Hobbs <tv...@googlemail.com>.
> I know, and I know the list is so long that I just abbreviated "& Co",
> BUT I still maintain my opinion that you have been catalytic to get
> the project back on the right track...
+1 agreed
Re: Graduation - Was Re: Praise for River Development team
Posted by Sim IJskes - QCG <si...@qcg.nl>.
On 15-11-10 13:48, Niclas Hedhman wrote:
> As for Jukka's request on namespaces; If River makes a statement that
> com.sun... (and others) will be migrated to an org.apache.river
> namespace after graduation adn after the next "bug fix" release, then
> I am Ok with that not blocking Graduation. net.jini namespace was from
> the beginning not part of the concerns, so that can remain the
> "official API" and evolution of specs in that space.
If we start with all the fanfare (new website,press@a.o involved), why
not do it before?
--
QCG, Software voor het MKB, 071-5890970, http://www.qcg.nl
Quality Consultancy Group b.v., Leiderdorp, Kvk Den Haag: 28088397
Re: Graduation - Was Re: Praise for River Development team
Posted by Niclas Hedhman <ni...@hedhman.org>.
On Mon, Nov 15, 2010 at 9:25 AM, Peter Firmstone <ji...@zeus.net.au> wrote:
> Thanks for your ongoing support Nic,
>
> Please though if you mention names, many members of our current development
> team have put in a huge effort(not in any order):
I know, and I know the list is so long that I just abbreviated "& Co",
BUT I still maintain my opinion that you have been catalytic to get
the project back on the right track...
In any event, I agree that all the people you mention are important to
the future of River, and I am confident that the community as such is
now stronger than ever before.
As for Jukka's request on namespaces; If River makes a statement that
com.sun... (and others) will be migrated to an org.apache.river
namespace after graduation adn after the next "bug fix" release, then
I am Ok with that not blocking Graduation. net.jini namespace was from
the beginning not part of the concerns, so that can remain the
"official API" and evolution of specs in that space.
Jukka, WDYT?
Cheers
--
Niclas Hedhman, Software Developer
http://www.qi4j.org - New Energy for Java
I live here; http://tinyurl.com/2qq9er
I work here; http://tinyurl.com/2ymelc
I relax here; http://tinyurl.com/2cgsug
Re: Graduation - Was Re: Praise for River Development team
Posted by Benson Margulies <bi...@gmail.com>.
OK, then, who wants to post the vote thread? Niklas and Jukka get
pride of place from their much longer involvement.
On Sun, Nov 14, 2010 at 8:25 PM, Peter Firmstone <ji...@zeus.net.au> wrote:
> Niclas Hedhman wrote:
>>
>> On Sat, Nov 13, 2010 at 9:10 PM, Benson Margulies <bi...@gmail.com>
>> wrote:
>>
>>>
>>> Sim,
>>>
>>> We could put up a vote now, I think. What do the other mentors think?
>>> One question is how many of the current active participants were
>>> around for that release you cite.
>>>
>>
>> I am Ok with graduation. I was worried for a while that the "outgoing"
>> Sun crowd (plus a "good enough" codebase) would be too much for the
>> project to absorb, but Peter & Co have really managed to turn this
>> into an optimistic future.
>>
>>
>> Cheers
>>
>
> Thanks for your ongoing support Nic,
>
> Please though if you mention names, many members of our current development
> team have put in a huge effort(not in any order):
>
> Jonathan Costers
> Tom Hobbs
> Sim IJskes
> Patricia Shanahan
> Greg Trasuk
>
> & still get advise and contributions from:
>
> Tim Blackman
> Fred Oliver
> Peter Jones (committer)
>
> & receive patches from:
>
> Bob Scheifler
> Christopher Dolan
> Michal Kleczek
> Brian Murphy (committer)
>
> & have received contributions from (who I'd encourage to become committers):
>
> Gregg Wonderly
> Dennis Reedy
>
> & our Apache mentors:
>
> Niclas
> Jukka
> Benson
>
> & encouragement & from others I haven't mentioned.
>
> Sorry if I've forgotten anybody, perhaps we can call ourselves Team River.
>
> Cheers,
>
> Peter.
>
>
>
Re: Graduation - Was Re: Praise for River Development team
Posted by Peter Firmstone <ji...@zeus.net.au>.
Niclas Hedhman wrote:
> On Sat, Nov 13, 2010 at 9:10 PM, Benson Margulies <bi...@gmail.com> wrote:
>
>> Sim,
>>
>> We could put up a vote now, I think. What do the other mentors think?
>> One question is how many of the current active participants were
>> around for that release you cite.
>>
>
> I am Ok with graduation. I was worried for a while that the "outgoing"
> Sun crowd (plus a "good enough" codebase) would be too much for the
> project to absorb, but Peter & Co have really managed to turn this
> into an optimistic future.
>
>
> Cheers
>
Thanks for your ongoing support Nic,
Please though if you mention names, many members of our current
development team have put in a huge effort(not in any order):
Jonathan Costers
Tom Hobbs
Sim IJskes
Patricia Shanahan
Greg Trasuk
& still get advise and contributions from:
Tim Blackman
Fred Oliver
Peter Jones (committer)
& receive patches from:
Bob Scheifler
Christopher Dolan
Michal Kleczek
Brian Murphy (committer)
& have received contributions from (who I'd encourage to become committers):
Gregg Wonderly
Dennis Reedy
& our Apache mentors:
Niclas
Jukka
Benson
& encouragement & from others I haven't mentioned.
Sorry if I've forgotten anybody, perhaps we can call ourselves Team River.
Cheers,
Peter.
Re: Graduation - Was Re: Praise for River Development team
Posted by Tom Hobbs <tv...@googlemail.com>.
I guess. I wasn't worrying about the number so much as the ordering.
On Mon, Nov 15, 2010 at 10:16 AM, Sim IJskes - QCG <si...@qcg.nl> wrote:
> On 15-11-10 10:44, Tom Hobbs wrote:
>>
>> This would be my preferred roadmap;
>>
>> 1. Bug fix release (minor version number change)
>> 2a. Namespace change release (major version number change)
>> 2b. Graduate
>> 3. Segment build release (major version number change)
>
> So conforming to:
>
> <http://river.staging.apache.org/development-process.html#version_numbering>
>
> 1. = 2.2
> 2a. = 3
>
> right?
>
> Gr. Sim
>
> --
> QCG, Software voor het MKB, 071-5890970, http://www.qcg.nl
> Quality Consultancy Group b.v., Leiderdorp, Kvk Den Haag: 28088397
>
Re: Graduation - Was Re: Praise for River Development team
Posted by Sim IJskes - QCG <si...@qcg.nl>.
On 15-11-10 10:44, Tom Hobbs wrote:
> This would be my preferred roadmap;
>
> 1. Bug fix release (minor version number change)
> 2a. Namespace change release (major version number change)
> 2b. Graduate
> 3. Segment build release (major version number change)
So conforming to:
<http://river.staging.apache.org/development-process.html#version_numbering>
1. = 2.2
2a. = 3
right?
Gr. Sim
--
QCG, Software voor het MKB, 071-5890970, http://www.qcg.nl
Quality Consultancy Group b.v., Leiderdorp, Kvk Den Haag: 28088397
Re: Graduation - Was Re: Praise for River Development team
Posted by Patricia Shanahan <pa...@acm.org>.
On 11/15/2010 2:45 AM, Peter Firmstone wrote:
> Sim IJskes - QCG wrote:
>> On 15-11-10 10:44, Tom Hobbs wrote:
>>> Segmenting the JARs and changing the namespaces are two very big
>>> chunks of work. Both of which are going to have an impact on our
>>> users. (Let's not forget the user list!)
>>
>> So this means publicity or announcing the change. And a roadmap item
>> on the website for users only focused on download.
>>
>>> My reluctance to spread the namespace change over a number of builds
>>> is simply due to the work we then place on our users. If, after each
>>> release, they need to refactor and/or retest their own code (which
>>> might be an extensive task) then asking them to do that multiple times
>>> is a big ask. Warning them that in X months times, if they want to
>>> continue using River, they're going to have to go through one big hit
>>> of pain is (in my perhaps flawed opinion) a better approach.
>>
>> +1
>>
>> For a user, one session of fixing the imports should be the limit.
+1
Not only does doing it all at once reduce the number of releases
involved, it makes the user response to the rename much simpler. It is
easier to write scripts for a rename of all packages with one or two
prefixes than to pick out individual packages. It is easier to remember
"com.sun.jini has been replaced by org.apache.river" than to remember a
series of package changes.
>
> That makes sense, these namespaces have been advised as subject to change.
>
> Let me finish sorting the failing qa tests first though.
I think the fix for that should be part of the minor release to fix bugs
that comes next, before the package rename.
Patricia
Re: Graduation - Was Re: Praise for River Development team
Posted by Peter Firmstone <ji...@zeus.net.au>.
Sim IJskes - QCG wrote:
> On 15-11-10 10:44, Tom Hobbs wrote:
>> Segmenting the JARs and changing the namespaces are two very big
>> chunks of work. Both of which are going to have an impact on our
>> users. (Let's not forget the user list!)
>
> So this means publicity or announcing the change. And a roadmap item
> on the website for users only focused on download.
>
>> My reluctance to spread the namespace change over a number of builds
>> is simply due to the work we then place on our users. If, after each
>> release, they need to refactor and/or retest their own code (which
>> might be an extensive task) then asking them to do that multiple times
>> is a big ask. Warning them that in X months times, if they want to
>> continue using River, they're going to have to go through one big hit
>> of pain is (in my perhaps flawed opinion) a better approach.
>
> +1
>
> For a user, one session of fixing the imports should be the limit.
>
> Gr. Sim
>
That makes sense, these namespaces have been advised as subject to change.
Let me finish sorting the failing qa tests first though.
Cheers,
Peter.
Re: Graduation - Was Re: Praise for River Development team
Posted by Sim IJskes - QCG <si...@qcg.nl>.
On 15-11-10 10:44, Tom Hobbs wrote:
> Segmenting the JARs and changing the namespaces are two very big
> chunks of work. Both of which are going to have an impact on our
> users. (Let's not forget the user list!)
So this means publicity or announcing the change. And a roadmap item on
the website for users only focused on download.
> My reluctance to spread the namespace change over a number of builds
> is simply due to the work we then place on our users. If, after each
> release, they need to refactor and/or retest their own code (which
> might be an extensive task) then asking them to do that multiple times
> is a big ask. Warning them that in X months times, if they want to
> continue using River, they're going to have to go through one big hit
> of pain is (in my perhaps flawed opinion) a better approach.
+1
For a user, one session of fixing the imports should be the limit.
Gr. Sim
--
QCG, Software voor het MKB, 071-5890970, http://www.qcg.nl
Quality Consultancy Group b.v., Leiderdorp, Kvk Den Haag: 28088397
Re: Graduation - Was Re: Praise for River Development team
Posted by Tom Hobbs <tv...@googlemail.com>.
Segmenting the JARs and changing the namespaces are two very big
chunks of work. Both of which are going to have an impact on our
users. (Let's not forget the user list!)
Moving the package names would be a nice to thing to do for
graduation. It just feels more clean. If there is real fundamental
reason why to leave it until afterwards, then I'm not going to argue
the point. I would think that segmenting (and maven-izing, maybe) the
build can wait until after graduation.
This would be my preferred roadmap;
1. Bug fix release (minor version number change)
2a. Namespace change release (major version number change)
2b. Graduate
3. Segment build release (major version number change)
I see 2b as being our "graduation build".
My reluctance to spread the namespace change over a number of builds
is simply due to the work we then place on our users. If, after each
release, they need to refactor and/or retest their own code (which
might be an extensive task) then asking them to do that multiple times
is a big ask. Warning them that in X months times, if they want to
continue using River, they're going to have to go through one big hit
of pain is (in my perhaps flawed opinion) a better approach.
Having said that, I can see Peter's point that because of the scale
and impact of the task, taking it slowly and carefully is an
attractive approach.
My gut still says that a warning and big bang approach would be
cleaner (especially if it coincides with graduation). However, I've
also learnt not to accept advice from many of my own body parts...
On Mon, Nov 15, 2010 at 8:36 AM, Sim IJskes - QCG <si...@qcg.nl> wrote:
> On 15-11-10 09:04, Peter Firmstone wrote:
>>
>> Some thoughts:
>>
>> I think we could move service implementations and proxy's first, client
>> code should not directly depend on these and it moves large quantity of
>> code to the new name space.
>>
>> Due to the size of the task of moving all of com.sun.* and the potential
>> implications, I think we should take a softly softly approach, this
>> might take a number of releases.
>>
>> As we rebuild the namespace we could make it more modular as we progress.
>
> My proposal is the exact opposite. Just do it on the current codebase in one
> go, and not add extra constraints to it. From a code perspective it is a
> trivial excercise. Any problems i've experienced with it, were tool
> breakdown, and files outside the scope of the 'refactoring engine'.
>
> If we are all in agreement, we should merge the stuff we want included, and
> then make the svn jtsk trunk single user commit.
>
> As i've promised before i became committer i will try to do the package
> rename in the code and svn, but we have to have plans for the secundary
> stage (i.e. text files containing package references).
>
> For the first stage we need to establish the following rules:
> - move files with their revision history intact. (svn move = svn copy, svn
> delete)
> - only commit after codebase compiles.
>
> The following steps are to be defined.
>
> Gr. Sim
>
> --
> QCG, Software voor het MKB, 071-5890970, http://www.qcg.nl
> Quality Consultancy Group b.v., Leiderdorp, Kvk Den Haag: 28088397
>
Re: Graduation - Was Re: Praise for River Development team
Posted by Sim IJskes - QCG <si...@qcg.nl>.
On 15-11-10 09:04, Peter Firmstone wrote:
> Some thoughts:
>
> I think we could move service implementations and proxy's first, client
> code should not directly depend on these and it moves large quantity of
> code to the new name space.
>
> Due to the size of the task of moving all of com.sun.* and the potential
> implications, I think we should take a softly softly approach, this
> might take a number of releases.
>
> As we rebuild the namespace we could make it more modular as we progress.
My proposal is the exact opposite. Just do it on the current codebase in
one go, and not add extra constraints to it. From a code perspective it
is a trivial excercise. Any problems i've experienced with it, were tool
breakdown, and files outside the scope of the 'refactoring engine'.
If we are all in agreement, we should merge the stuff we want included,
and then make the svn jtsk trunk single user commit.
As i've promised before i became committer i will try to do the package
rename in the code and svn, but we have to have plans for the secundary
stage (i.e. text files containing package references).
For the first stage we need to establish the following rules:
- move files with their revision history intact. (svn move = svn copy,
svn delete)
- only commit after codebase compiles.
The following steps are to be defined.
Gr. Sim
--
QCG, Software voor het MKB, 071-5890970, http://www.qcg.nl
Quality Consultancy Group b.v., Leiderdorp, Kvk Den Haag: 28088397
Re: Graduation - Was Re: Praise for River Development team
Posted by Peter Firmstone <ji...@zeus.net.au>.
Patricia Shanahan wrote:
> Jukka Zitting wrote:
> ...
>> One thing I'd like to see before graduation is a clear roadmap for
>> when and how River will be migrating from com.sun (and com.artima)
>> packages to org.apache. Even better (but not necessary) if this
>> migration could be done before graduation.
> ...
>
> The difficult part of this is deciding how to handle it in terms of
> releases. We are well on the way to a bug fix release that should be
> able to run all categories of QA test. Do we want to combine the
> package name change with that, or do it as a separate release?
>
> My initial feeling is to keep them separate, and do the bug fix
> release first. The bug fix release is not a comparability issue. There
> have been some indications that some com.sun.jini classes are being
> used in user code, so the package name change may have more impact on
> users.
>
> The actual mechanics of renaming packages while preserving the history
> is a job for an IDE. In the past, I've done it using Eclipse with one
> of the subversion plug-ins.
>
> Patricia
>
Some thoughts:
I think we could move service implementations and proxy's first, client
code should not directly depend on these and it moves large quantity of
code to the new name space.
Due to the size of the task of moving all of com.sun.* and the potential
implications, I think we should take a softly softly approach, this
might take a number of releases.
As we rebuild the namespace we could make it more modular as we progress.
Cheers,
Peter.
Re: Graduation - Was Re: Praise for River Development team
Posted by Patricia Shanahan <pa...@acm.org>.
Jukka Zitting wrote:
...
> One thing I'd like to see before graduation is a clear roadmap for
> when and how River will be migrating from com.sun (and com.artima)
> packages to org.apache. Even better (but not necessary) if this
> migration could be done before graduation.
...
The difficult part of this is deciding how to handle it in terms of
releases. We are well on the way to a bug fix release that should be
able to run all categories of QA test. Do we want to combine the package
name change with that, or do it as a separate release?
My initial feeling is to keep them separate, and do the bug fix release
first. The bug fix release is not a comparability issue. There have been
some indications that some com.sun.jini classes are being used in user
code, so the package name change may have more impact on users.
The actual mechanics of renaming packages while preserving the history
is a job for an IDE. In the past, I've done it using Eclipse with one of
the subversion plug-ins.
Patricia
Re: Graduation - Was Re: Praise for River Development team
Posted by Jukka Zitting <ju...@gmail.com>.
Hi,
On Mon, Nov 15, 2010 at 2:34 AM, Niclas Hedhman <ni...@hedhman.org> wrote:
> On Sat, Nov 13, 2010 at 9:10 PM, Benson Margulies <bi...@gmail.com> wrote:
>> We could put up a vote now, I think. What do the other mentors think?
>> One question is how many of the current active participants were
>> around for that release you cite.
>
> I am Ok with graduation. I was worried for a while that the "outgoing"
> Sun crowd (plus a "good enough" codebase) would be too much for the
> project to absorb, but Peter & Co have really managed to turn this
> into an optimistic future.
Same thoughts here. It's been great to follow the growth of this
community since last summer, and I think you'll do great as an Apache
TLP.
One thing I'd like to see before graduation is a clear roadmap for
when and how River will be migrating from com.sun (and com.artima)
packages to org.apache. Even better (but not necessary) if this
migration could be done before graduation.
BR,
Jukka Zitting
Re: Graduation - Was Re: Praise for River Development team
Posted by Niclas Hedhman <ni...@hedhman.org>.
On Sat, Nov 13, 2010 at 9:10 PM, Benson Margulies <bi...@gmail.com> wrote:
> Sim,
>
> We could put up a vote now, I think. What do the other mentors think?
> One question is how many of the current active participants were
> around for that release you cite.
I am Ok with graduation. I was worried for a while that the "outgoing"
Sun crowd (plus a "good enough" codebase) would be too much for the
project to absorb, but Peter & Co have really managed to turn this
into an optimistic future.
Cheers
--
Niclas Hedhman, Software Developer
http://www.qi4j.org - New Energy for Java
I live here; http://tinyurl.com/2qq9er
I work here; http://tinyurl.com/2ymelc
I relax here; http://tinyurl.com/2cgsug
Re: Graduation - Was Re: Praise for River Development team
Posted by Sim IJskes - QCG <si...@qcg.nl>.
On 11/13/2010 02:10 PM, Benson Margulies wrote:
> One question is how many of the current active participants were
> around for that release you cite.
That release 2.1.2 was done from 8 mar 2010 to 13 mar 2010. In this
release were a number of commits from current active participants.
current active participants (last trunk commit):
- peter_firmstone (2010-11-12)
- sijskes (2010-11-03)
- pats (2010-11-02)
- thobbs (2010-10-13)
- jcosters (2010-10-02)
- btmurphy (2009-11-08)
recent commiters in diff between 2.1.2 and 2.1.1 (2010-03 to 2009-11)
- peter_firmstone
- thobbs
- sijskes (developer, patch via peter_firmstone)
- btmurphy
- jcosters
Gr. Sim
Re: Graduation - Was Re: Praise for River Development team
Posted by Benson Margulies <bi...@gmail.com>.
Sim,
We could put up a vote now, I think. What do the other mentors think?
One question is how many of the current active participants were
around for that release you cite.
--benson
On Sat, Nov 13, 2010 at 8:07 AM, Sim IJskes - QCG <si...@qcg.nl> wrote:
> On 10/31/2010 12:50 PM, Benson Margulies wrote:
>>
>> On the other hand, my fellow mentors, when they brought me into the
>> picture, felt that a release would be a good capstone to moving River
>> into an active state that would easily get a positive outcome from the
>> IPMC.
>
> Benson,
>
> what do you consider a release? Whe have already released 2.1.2. is there
> anything missing what whe have overlooked?
>
> Or are you giving us 'the green light' when we would bring it to vote to the
> IPMC?
>
> Gr. Sim
>
Re: Graduation - Was Re: Praise for River Development team
Posted by Sim IJskes - QCG <si...@qcg.nl>.
On 10/31/2010 12:50 PM, Benson Margulies wrote:
> On the other hand, my fellow mentors, when they brought me into the
> picture, felt that a release would be a good capstone to moving River
> into an active state that would easily get a positive outcome from the
> IPMC.
Benson,
what do you consider a release? Whe have already released 2.1.2. is
there anything missing what whe have overlooked?
Or are you giving us 'the green light' when we would bring it to vote to
the IPMC?
Gr. Sim
Re: Graduation - Was Re: Praise for River Development team
Posted by Benson Margulies <bi...@gmail.com>.
A few notes.
A release is not, indeed, a formal requirement. At this point, in
practical terms, the 'requirement' is a vote from the Incubator
Project Management Committee.
On the other hand, my fellow mentors, when they brought me into the
picture, felt that a release would be a good capstone to moving River
into an active state that would easily get a positive outcome from the
IPMC.
As for the web of trust: see
http://www.apache.org/dev/release-signing.html. It would be more
better if one of you could work out a way to get your key signed by
someone else around the foundation, but that is not a prerequisite of
a release. While an in-person meeting is considered idea, it's not
required.
Re: Graduation - Was Re: Praise for River Development team
Posted by Niclas Hedhman <ni...@hedhman.org>.
On Sun, Oct 31, 2010 at 1:23 PM, Patricia Shanahan <pa...@acm.org> wrote:
> Presumably, if we have an appropriate team working on River, we will get
> code quality anyway. Is there any view of how large an active committer
> community we need, and what skill range?
Skillset has never been discussed before IIRC, so that is a non-issue.
The Incubator PMC wants to see at least 3 active committers not
working for the same company. This is more than well met, and the
progress over the last year has been a good indicator, that once there
are things to scratch, people start getting involed. Good Stuff.
> I assume we would be aiming to be a top level project, not transfer to be a
> sub-project in another project.
Yes, in general, there must be very special considerations (typically,
'real small codebase') for sub-projects in Apache nowadays. If you
follow which projects are created each month, you will see that a
large set are actually not from the Incubator, but spin-off
subprojects from Lucene, Hadoop and others...
Cheers
--
Niclas Hedhman, Software Developer
http://www.qi4j.org - New Energy for Java
I live here; http://tinyurl.com/2qq9er
I work here; http://tinyurl.com/2ymelc
I relax here; http://tinyurl.com/2cgsug