Rethinking our release strategy

[Jacopo Cappellato-4]

I know this subject has been already discussed several times in the past, but I still would like to rethink our strategy for releases in OFBiz.
I am under the impression that, considering the release branch 9.04, that is our latest release branch:
* there are more users than maintainers
* because of this, no real maintenance plan, test strategy etc.. has been created around it from the community of users and interested parties (in fact we were not really able to officially release it)
* a lot of new users start eveluating OFBiz from that instead of the trunk
* it is rather old, several new features are missing and also code improvements (that could fix bugs etc)
* because of this, it tends to be less stable than the trunk

The main cons of this situations are the following:
1) not real interest in maintaining a release branch means that we will not be able to spend time on it and officially release it: the OFBiz community will miss the advantage of using the marketing channel represented by a new release
2) new users will get the wrong impression that the project is slowing improving if they just get the releases
3) it is much easier for a user to stay up to date with the trunk rather than with a release: I mean that there is no guarantee that one day someone will build an upgrade plan from the old release to the new one... users of the old release may be left behind forever

What I suggest is based on the following assumptions:
1) community is not ready or interested in maintaining releases
2) new users prefer to start evaluating OFBiz with a release instead of the trunk
3) it is good for the project to announce new releases often
4) because our current policies (slowly increasing number of committers, peer reviews, etc...) our trunk is (and will be) more stable than older releases

Here is what I suggest:
A) define an official release plan that says that we officially issue a release every approx 6 months (just to give you an idea): since there is no way to define a set of features that will go in the next release, our releases will be based on dates instead of features; but of course we can discuss the exact time of a release based on what is going on 1-2 weeks before the release date
B) there is no guarantee that patches will be backported to releases, that upgrade scripts will be created from release to release

It is true that the ASF policies ask that a release, that represents the code that is distributed by the ASF to the larger audience of users, is a "stable" deliverable; but if we continue with the current approach, even if it is intended to get a stable and maintained release, what we are really doing is distributing the code in the trunk (this is what we suggest our users to use instead of the release), not the "stable" release.

What do you think?

Jacopo

[Dimitri Unruh-2]

Jacopo,

this is exactly my point of view. So:

+1

Viele Grüße
Best Regards


Dimitri Unruh
Consultant AEW
Lynx-Consulting GmbH
Johanniskirchplatz 6
33615 Bielefeld
Deutschland
Fon: [phone]
Fax: [phone]
Mobil: [phone]


Company and Management Headquarters:
Lynx-Consulting GmbH, Johanniskirchplatz 6, 33615 Bielefeld, Deutschland
Fon: [phone], Fax: [phone], www.lynx.de

Court Registration: Amtsgericht Bielefeld HRB 35946
Chief Executive Officers: Karsten Noss, Dirk Osterkamp

----------------------------------------------------------------------------------------------------
This e-mail may contain trade secrets or privileged, undisclosed, or otherwise confidential information. If you have received this e-mail in error, you are hereby notified that any review, copying, or distribution of it is strictly prohibited. Please inform us immediately and destroy the original transmittal. Thank you for your cooperation.
----------------------------------------------------------------------------------------------------


SAP Special Expertise Partner ERP Upgrade

Erfolg ist eine Folge. 20 Jahre Lynx





From:   Jacopo Cappellato <[hidden email]>
To:     [hidden email]
Date:   15.02.2010 11:50
Subject:        Rethinking our release strategy



I know this subject has been already discussed several times in the past,
but I still would like to rethink our strategy for releases in OFBiz.
I am under the impression that, considering the release branch 9.04, that
is our latest release branch:
* there are more users than maintainers
* because of this, no real maintenance plan, test strategy etc.. has been
created around it from the community of users and interested parties (in
fact we were not really able to officially release it)
* a lot of new users start eveluating OFBiz from that instead of the trunk
* it is rather old, several new features are missing and also code
improvements (that could fix bugs etc)
* because of this, it tends to be less stable than the trunk

The main cons of this situations are the following:
1) not real interest in maintaining a release branch means that we will
not be able to spend time on it and officially release it: the OFBiz
community will miss the advantage of using the marketing channel
represented by a new release
2) new users will get the wrong impression that the project is slowing
improving if they just get the releases
3) it is much easier for a user to stay up to date with the trunk rather
than with a release: I mean that there is no guarantee that one day
someone will build an upgrade plan from the old release to the new one...
users of the old release may be left behind forever

What I suggest is based on the following assumptions:
1) community is not ready or interested in maintaining releases
2) new users prefer to start evaluating OFBiz with a release instead of
the trunk
3) it is good for the project to announce new releases often
4) because our current policies (slowly increasing number of committers,
peer reviews, etc...) our trunk is (and will be) more stable than older
releases

Here is what I suggest:
A) define an official release plan that says that we officially issue a
release every approx 6 months (just to give you an idea): since there is
no way to define a set of features that will go in the next release, our
releases will be based on dates instead of features; but of course we can
discuss the exact time of a release based on what is going on 1-2 weeks
before the release date
B) there is no guarantee that patches will be backported to releases, that
upgrade scripts will be created from release to release

It is true that the ASF policies ask that a release, that represents the
code that is distributed by the ASF to the larger audience of users, is a
"stable" deliverable; but if we continue with the current approach, even
if it is intended to get a stable and maintained release, what we are
really doing is distributing the code in the trunk (this is what we
suggest our users to use instead of the release), not the "stable"
release.

What do you think?

Jacopo

[Ruth Hoffman-2]

Hi Jacopo:
Its nice to see this kind of thought going into a release strategy.
Thanks for the effort. Please see my comments inline. Note, this is just
my opinion based on years of working with big complex IT organizations.
These are the kind of "users" who ultimately would be implementing OFBiz
(I hope...):

Jacopo Cappellato wrote:
> I know this subject has been already discussed several times in the past, but I still would like to rethink our strategy for releases in OFBiz.
> I am under the impression that, considering the release branch 9.04, that is our latest release branch:
> * there are more users than maintainers
>  
This is probably true. But to get a better understanding of who is using
what, maybe we could look into getting download statistics? I have
already put in a request to the infrastructure team for this, but have
not heard anything back from them. Maybe a project committer has more
clout and could get this implemented? Without that, we are just
speculating about who is doing what with the code.
> * because of this, no real maintenance plan, test strategy etc.. has been created around it from the community of users and interested parties (in fact we were not really able to officially release it)
> * a lot of new users start eveluating OFBiz from that instead of the trunk
> * it is rather old, several new features are missing and also code improvements (that could fix bugs etc)
>  
I thought all the bug fixes were retrofitted to the release? Is this not
true?
> * because of this, it tends to be less stable than the trunk
>  
How could the release be less stable than the trunk if bug fixes are
applied to the release and the trunk?
> The main cons of this situations are the following:
> 1) not real interest in maintaining a release branch means that we will not be able to spend time on it and officially release it: the OFBiz community will miss the advantage of using the marketing channel represented by a new release
> 2) new users will get the wrong impression that the project is slowing improving if they just get the releases
>  
Project committers should consider this behavior pattern: Most people
evaluating code will not want the latest release. They will patiently
wait until someone else has taken on the risk (and reward) of debugging
it. Do not think that just because the project releases a new release of
OFBiz, that everyone will stampede to get it. Far from it. Now if we had
download statistics we could verify my claim, but I'd be willing to bet
real money, that the only people who will jump to download this new
release will be project committers.
> 3) it is much easier for a user to stay up to date with the trunk rather than with a release: I mean that there is no guarantee that one day someone will build an upgrade plan from the old release to the new one... users of the old release may be left behind forever
>
>  
I think you mistake "user" with "committer". What "user" is actively
trying to stay current with the trunk? Just some food for thought.
> What I suggest is based on the following assumptions:
> 1) community is not ready or interested in maintaining releases
>  
Only the "committers" are not interested. Users out there may have a
different story to tell. Personally, I'd like to see releases "maintained".
> 2) new users prefer to start evaluating OFBiz with a release instead of the trunk
> 3) it is good for the project to announce new releases often
>  
True. Very true.
> 4) because our current policies (slowly increasing number of committers, peer reviews, etc...) our trunk is (and will be) more stable than older releases
>
>  
Again, why? I thought bug fixes are committed back to a release if
appropriate. Is this not the case?
> Here is what I suggest:
> A) define an official release plan that says that we officially issue a release every approx 6 months (just to give you an idea): since there is no way to define a set of features that will go in the next release, our releases will be based on dates instead of features; but of course we can discuss the exact time of a release based on what is going on 1-2 weeks before the release date
>  
Don't release every 6 months. That's crazy. Once a year is sufficient.
Put in place a real release plan including features, fixes and upgrade
instructions in advance and then work towards making OFBiz something
more than just a developer's playground. Make it "stable" by setting out
in advance what "stable" means. And then work towards making each
release meet the "stability" requirements. Just releasing something
every 6 months or a year does not a "stable" release make.
> B) there is no guarantee that patches will be backported to releases, that upgrade scripts will be created from release to release
>
>  
If so, then what is the point of even having releases? Just have nightly
trunk builds and everyone is happy.
> It is true that the ASF policies ask that a release, that represents the code that is distributed by the ASF to the larger audience of users, is a "stable" deliverable; but if we continue with the current approach, even if it is intended to get a stable and maintained release, what we are really doing is distributing the code in the trunk (this is what we suggest our users to use instead of the release), not the "stable" release.
>
>  
IMHO, one of the true benefits of going with the ASF is the structure
and stability they enforce on umbrella projects. Why not use these
"restrictions" to the project's advantage instead of trying to
circumvent them. I think I'm agreeing with you in that maybe "we" should
start pointing users to releases instead of trunk code. Just a thought.

Ruth
> What do you think?
>
> Jacopo
>
>
>
>
>  

[Adrian Crum]

Jacopo Cappellato wrote:
> I know this subject has been already discussed several times in the past, but I still would like to rethink our strategy for releases in OFBiz.
> I am under the impression that, considering the release branch 9.04, that is our latest release branch:
> * there are more users than maintainers
> * because of this, no real maintenance plan, test strategy etc.. has been created around it from the community of users and interested parties (in fact we were not really able to officially release it)
> * a lot of new users start eveluating OFBiz from that instead of the trunk
> * it is rather old, several new features are missing and also code improvements (that could fix bugs etc)
> * because of this, it tends to be less stable than the trunk

I thought the whole point of a release was to make it *more* stable than
the trunk. I'm puzzled by your conclusion.

> The main cons of this situations are the following:
> 1) not real interest in maintaining a release branch means that we will not be able to spend time on it and officially release it: the OFBiz community will miss the advantage of using the marketing channel represented by a new release
> 2) new users will get the wrong impression that the project is slowing improving if they just get the releases
> 3) it is much easier for a user to stay up to date with the trunk rather than with a release: I mean that there is no guarantee that one day someone will build an upgrade plan from the old release to the new one... users of the old release may be left behind forever

There seems to be a lot of subjective opinion here. I'm interested in
maintaining the release branch, and I commit fixes to it regularly.

> Here is what I suggest:
> A) define an official release plan that says that we officially issue a release every approx 6 months (just to give you an idea): since there is no way to define a set of features that will go in the next release, our releases will be based on dates instead of features; but of course we can discuss the exact time of a release based on what is going on 1-2 weeks before the release date

My preference would be yearly.

-Adrian

[BJ Freeman]

I agree that the community does not turn its attention to the releases
we have. It is a thorn of mine.
It seems people rather keep adding new features than test and stabilize
the releases.
You point out that we have more committer, yet it seems they are not
interested on focusing on the releases. I would like to see a 4 month
period where all work is focus on a release.

The down side of the trunk for a developer is it changes fast and breaks
      development time already put in.
There is also not back compatibility that is done.

for those that work on the trunk and can make changes I see your way
better, but for those that want to do things that may not be what
committers want to support, the developer can not share their changes
because they did it for a business, or just developing a horizontal
application that is not in the svn.



Jacopo Cappellato sent the following on 2/15/2010 2:49 AM:

> I know this subject has been already discussed several times in the past, but I still would like to rethink our strategy for releases in OFBiz.
> I am under the impression that, considering the release branch 9.04, that is our latest release branch:
> * there are more users than maintainers
> * because of this, no real maintenance plan, test strategy etc.. has been created around it from the community of users and interested parties (in fact we were not really able to officially release it)
> * a lot of new users start eveluating OFBiz from that instead of the trunk
> * it is rather old, several new features are missing and also code improvements (that could fix bugs etc)
> * because of this, it tends to be less stable than the trunk
>
> The main cons of this situations are the following:
> 1) not real interest in maintaining a release branch means that we will not be able to spend time on it and officially release it: the OFBiz community will miss the advantage of using the marketing channel represented by a new release
> 2) new users will get the wrong impression that the project is slowing improving if they just get the releases
> 3) it is much easier for a user to stay up to date with the trunk rather than with a release: I mean that there is no guarantee that one day someone will build an upgrade plan from the old release to the new one... users of the old release may be left behind forever
>
> What I suggest is based on the following assumptions:
> 1) community is not ready or interested in maintaining releases
> 2) new users prefer to start evaluating OFBiz with a release instead of the trunk
> 3) it is good for the project to announce new releases often
> 4) because our current policies (slowly increasing number of committers, peer reviews, etc...) our trunk is (and will be) more stable than older releases
>
> Here is what I suggest:
> A) define an official release plan that says that we officially issue a release every approx 6 months (just to give you an idea): since there is no way to define a set of features that will go in the next release, our releases will be based on dates instead of features; but of course we can discuss the exact time of a release based on what is going on 1-2 weeks before the release date
> B) there is no guarantee that patches will be backported to releases, that upgrade scripts will be created from release to release
>
> It is true that the ASF policies ask that a release, that represents the code that is distributed by the ASF to the larger audience of users, is a "stable" deliverable; but if we continue with the current approach, even if it is intended to get a stable and maintained release, what we are really doing is distributing the code in the trunk (this is what we suggest our users to use instead of the release), not the "stable" release.
>
> What do you think?
>
> Jacopo
>
>
>
>

[chris snow]

If migration from old releases to newer ones was more automated (e.g. providing db migration scripts, ensuring consistent apis between releases, etc), it would be more practical to have only one (maybe two) stable release  (i.e. supported).  I imagine the main reason for users wanting very old releases to be supported is because the manual upgrade process is very laborious.

Shouldn't we make is easy for uses to upgrade to the latest stable release to make it easier to phase out old releases?

[Adam Heath-2]

chris snow wrote:
> If migration from old releases to newer ones was more automated (e.g.
> providing db migration scripts, ensuring consistent apis between releases,
> etc), it would be more practical to have only one (maybe two) stable release
> (i.e. supported).  I imagine the main reason for users wanting very old
> releases to be supported is because the manual upgrade process is very
> laborious.

I have a plan to support in-place database upgrades.  Need to find
where I did that.

>
> Shouldn't we make is easy for uses to upgrade to the latest stable release
> to make it easier to phase out old releases?

[David E. Jones-2]

One point of clarification: it seems like the word "stable" here should be replaced by "bug free", as in [release branch] tends to be less "bug free" than the trunk. The release branch is inherently more "stable" because it doesn't change as much (ie the definition of stable), and I think Jacopo is really referring to the idea that we've discussed before that stability is not the same as being "bug free".

About the six month release period, I'm not so sure about that. It sounds like the idea is to give up on high quality releases in order to increase marketing. There are two problems I see with this:

1. this may not have a positive effect on marketing, I don't know but it seems like a large number of less meaningful press releases will not be as helpful as a few significant ones (yes, I know large companies tend to do lots of less meaningful press releases, but many of these stories are just another form of paid advertisement and press organizations like to carry them because name-dropping increases ad views for ads from other companies, and ad purchases from the companies mentioned, and therefore revenue; unfortunately Apache OFBiz doesn't benefit from this sort of status, so the story really needs to _mean_ something to get attention

2. I still think quality releases are important, and there are certain people in the community who consider this important and are willing to invest in and contribute to such an effort; if we move to more frequent releases it makes it much more difficult for the people who want to work on high quality releases, and decreases the chances that the project will ever have a vetted binary release

-David


On Feb 15, 2010, at 3:49 AM, Jacopo Cappellato wrote:

> I know this subject has been already discussed several times in the past, but I still would like to rethink our strategy for releases in OFBiz.
> I am under the impression that, considering the release branch 9.04, that is our latest release branch:
> * there are more users than maintainers
> * because of this, no real maintenance plan, test strategy etc.. has been created around it from the community of users and interested parties (in fact we were not really able to officially release it)
> * a lot of new users start eveluating OFBiz from that instead of the trunk
> * it is rather old, several new features are missing and also code improvements (that could fix bugs etc)
> * because of this, it tends to be less stable than the trunk
>
> The main cons of this situations are the following:
> 1) not real interest in maintaining a release branch means that we will not be able to spend time on it and officially release it: the OFBiz community will miss the advantage of using the marketing channel represented by a new release
> 2) new users will get the wrong impression that the project is slowing improving if they just get the releases
> 3) it is much easier for a user to stay up to date with the trunk rather than with a release: I mean that there is no guarantee that one day someone will build an upgrade plan from the old release to the new one... users of the old release may be left behind forever
>
> What I suggest is based on the following assumptions:
> 1) community is not ready or interested in maintaining releases
> 2) new users prefer to start evaluating OFBiz with a release instead of the trunk
> 3) it is good for the project to announce new releases often
> 4) because our current policies (slowly increasing number of committers, peer reviews, etc...) our trunk is (and will be) more stable than older releases
>
> Here is what I suggest:
> A) define an official release plan that says that we officially issue a release every approx 6 months (just to give you an idea): since there is no way to define a set of features that will go in the next release, our releases will be based on dates instead of features; but of course we can discuss the exact time of a release based on what is going on 1-2 weeks before the release date
> B) there is no guarantee that patches will be backported to releases, that upgrade scripts will be created from release to release
>
> It is true that the ASF policies ask that a release, that represents the code that is distributed by the ASF to the larger audience of users, is a "stable" deliverable; but if we continue with the current approach, even if it is intended to get a stable and maintained release, what we are really doing is distributing the code in the trunk (this is what we suggest our users to use instead of the release), not the "stable" release.
>
> What do you think?
>
> Jacopo
>
>
>

[Sharan-F]

Hi

It sounds like there 's some confusion as to whether the release branches are being updated with bug fixes or not. I thought they were.

My focus has been pretty much been on OFBiz documentation and I find it very, very hard to document things as they are changing so fast. Features seemed to be added with no hint of documentation or even a spec.  The only way to find out how things work,  is trial and error and not everyone is interested in (or capable of) looking at or understanding the code.

Personally I'd like to see a yearly release plan so that we could at least ensure that we had enough time to make it truly stable and that the right documentation is in place to support the release.

Thanks
Sharan

[David E. Jones-2]

I saw the comment below about OFBiz becoming a "developers playground." I'll admit I have been thinking for a while that many contributions do not meet business (ie end-user) needs nor do they make it easier to meet end-user needs, and in fact in some cases even make that more difficult. However, my opinion is that this is caused by end-user oriented contributors being less active than technically oriented contributors, in fact I would say FAR less active, and less active now than in years past.

Still, all of this comes down to the same message: if you want something to be done, or to be a certain way, either you figure out how to get other people to do it or you do it yourself.

-David


On Feb 15, 2010, at 9:03 AM, Ruth Hoffman wrote:

> Jacopo Cappellato wrote:
>> I know this subject has been already discussed several times in the past, but I still would like to rethink our strategy for releases in OFBiz.
>> I am under the impression that, considering the release branch 9.04, that is our latest release branch:
>> * there are more users than maintainers
>>  
> This is probably true. But to get a better understanding of who is using what, maybe we could look into getting download statistics? I have already put in a request to the infrastructure team for this, but have not heard anything back from them. Maybe a project committer has more clout and could get this implemented? Without that, we are just speculating about who is doing what with the code.
>> * because of this, no real maintenance plan, test strategy etc.. has been created around it from the community of users and interested parties (in fact we were not really able to officially release it)
>> * a lot of new users start eveluating OFBiz from that instead of the trunk
>> * it is rather old, several new features are missing and also code improvements (that could fix bugs etc)
>>  
> I thought all the bug fixes were retrofitted to the release? Is this not true?
>> * because of this, it tends to be less stable than the trunk
>>  
> How could the release be less stable than the trunk if bug fixes are applied to the release and the trunk?
>> The main cons of this situations are the following:
>> 1) not real interest in maintaining a release branch means that we will not be able to spend time on it and officially release it: the OFBiz community will miss the advantage of using the marketing channel represented by a new release
>> 2) new users will get the wrong impression that the project is slowing improving if they just get the releases
>>  
> Project committers should consider this behavior pattern: Most people evaluating code will not want the latest release. They will patiently wait until someone else has taken on the risk (and reward) of debugging it. Do not think that just because the project releases a new release of OFBiz, that everyone will stampede to get it. Far from it. Now if we had download statistics we could verify my claim, but I'd be willing to bet real money, that the only people who will jump to download this new release will be project committers.
>> 3) it is much easier for a user to stay up to date with the trunk rather than with a release: I mean that there is no guarantee that one day someone will build an upgrade plan from the old release to the new one... users of the old release may be left behind forever
>>
>>  
> I think you mistake "user" with "committer". What "user" is actively trying to stay current with the trunk? Just some food for thought.
>> What I suggest is based on the following assumptions:
>> 1) community is not ready or interested in maintaining releases
>>  
> Only the "committers" are not interested. Users out there may have a different story to tell. Personally, I'd like to see releases "maintained".
>> 2) new users prefer to start evaluating OFBiz with a release instead of the trunk
>> 3) it is good for the project to announce new releases often
>>  
> True. Very true.
>> 4) because our current policies (slowly increasing number of committers, peer reviews, etc...) our trunk is (and will be) more stable than older releases
>>
>>  
> Again, why? I thought bug fixes are committed back to a release if appropriate. Is this not the case?
>> Here is what I suggest:
>> A) define an official release plan that says that we officially issue a release every approx 6 months (just to give you an idea): since there is no way to define a set of features that will go in the next release, our releases will be based on dates instead of features; but of course we can discuss the exact time of a release based on what is going on 1-2 weeks before the release date
>>  
> Don't release every 6 months. That's crazy. Once a year is sufficient. Put in place a real release plan including features, fixes and upgrade instructions in advance and then work towards making OFBiz something more than just a developer's playground. Make it "stable" by setting out in advance what "stable" means. And then work towards making each release meet the "stability" requirements. Just releasing something every 6 months or a year does not a "stable" release make.
>> B) there is no guarantee that patches will be backported to releases, that upgrade scripts will be created from release to release
>>
>>  
> If so, then what is the point of even having releases? Just have nightly trunk builds and everyone is happy.
>> It is true that the ASF policies ask that a release, that represents the code that is distributed by the ASF to the larger audience of users, is a "stable" deliverable; but if we continue with the current approach, even if it is intended to get a stable and maintained release, what we are really doing is distributing the code in the trunk (this is what we suggest our users to use instead of the release), not the "stable" release.
>>
>>  
> IMHO, one of the true benefits of going with the ASF is the structure and stability they enforce on umbrella projects. Why not use these "restrictions" to the project's advantage instead of trying to circumvent them. I think I'm agreeing with you in that maybe "we" should start pointing users to releases instead of trunk code. Just a thought.
>
> Ruth
>> What do you think?
>>
>> Jacopo
>>
>>
>>
>>
>>  

[David E. Jones-2]

A release plan would be great. How are we going to do that, or what would it look like?

-David


On Feb 15, 2010, at 1:20 PM, Sharan-F wrote:

> Hi
>
> It sounds like there 's some confusion as to whether the release branches
> are being updated with bug fixes or not. I thought they were.
>
> My focus has been pretty much been on OFBiz documentation and I find it
> very, very hard to document things as they are changing so fast. Features
> seemed to be added with no hint of documentation or even a spec.  The only
> way to find out how things work,  is trial and error and not everyone is
> interested in (or capable of) looking at or understanding the code.
>
> Personally I'd like to see a yearly release plan so that we could at least
> ensure that we had enough time to make it truly stable and that the right
> documentation is in place to support the release.
>
> Thanks
> Sharan
>
> --
> View this message in context: http://n4.nabble.com/Rethinking-our-release-strategy-tp1555976p1556580.html
> Sent from the OFBiz - Dev mailing list archive at Nabble.com.

[Adrian Crum]

Plus, some of the technical work being done in the framework is intended
to make it easier for end-user-oriented contributors to write code.

The conversion framework is a perfect example: I just wanted to be able
to pass a TimeDuration instance around the framework, but couldn't
because of limitations in the framework. Once the conversion framework
is completely integrated, all developers will be able to pass
user-defined Java types around the framework easily.

-Adrian

David E Jones wrote:

> I saw the comment below about OFBiz becoming a "developers playground." I'll admit I have been thinking for a while that many contributions do not meet business (ie end-user) needs nor do they make it easier to meet end-user needs, and in fact in some cases even make that more difficult. However, my opinion is that this is caused by end-user oriented contributors being less active than technically oriented contributors, in fact I would say FAR less active, and less active now than in years past.
>
> Still, all of this comes down to the same message: if you want something to be done, or to be a certain way, either you figure out how to get other people to do it or you do it yourself.
>
> -David
>
>
> On Feb 15, 2010, at 9:03 AM, Ruth Hoffman wrote:
>
>> Jacopo Cappellato wrote:
>>> I know this subject has been already discussed several times in the past, but I still would like to rethink our strategy for releases in OFBiz.
>>> I am under the impression that, considering the release branch 9.04, that is our latest release branch:
>>> * there are more users than maintainers
>>>  
>> This is probably true. But to get a better understanding of who is using what, maybe we could look into getting download statistics? I have already put in a request to the infrastructure team for this, but have not heard anything back from them. Maybe a project committer has more clout and could get this implemented? Without that, we are just speculating about who is doing what with the code.
>>> * because of this, no real maintenance plan, test strategy etc.. has been created around it from the community of users and interested parties (in fact we were not really able to officially release it)
>>> * a lot of new users start eveluating OFBiz from that instead of the trunk
>>> * it is rather old, several new features are missing and also code improvements (that could fix bugs etc)
>>>  
>> I thought all the bug fixes were retrofitted to the release? Is this not true?
>>> * because of this, it tends to be less stable than the trunk
>>>  
>> How could the release be less stable than the trunk if bug fixes are applied to the release and the trunk?
>>> The main cons of this situations are the following:
>>> 1) not real interest in maintaining a release branch means that we will not be able to spend time on it and officially release it: the OFBiz community will miss the advantage of using the marketing channel represented by a new release
>>> 2) new users will get the wrong impression that the project is slowing improving if they just get the releases
>>>  
>> Project committers should consider this behavior pattern: Most people evaluating code will not want the latest release. They will patiently wait until someone else has taken on the risk (and reward) of debugging it. Do not think that just because the project releases a new release of OFBiz, that everyone will stampede to get it. Far from it. Now if we had download statistics we could verify my claim, but I'd be willing to bet real money, that the only people who will jump to download this new release will be project committers.
>>> 3) it is much easier for a user to stay up to date with the trunk rather than with a release: I mean that there is no guarantee that one day someone will build an upgrade plan from the old release to the new one... users of the old release may be left behind forever
>>>
>>>  
>> I think you mistake "user" with "committer". What "user" is actively trying to stay current with the trunk? Just some food for thought.
>>> What I suggest is based on the following assumptions:
>>> 1) community is not ready or interested in maintaining releases
>>>  
>> Only the "committers" are not interested. Users out there may have a different story to tell. Personally, I'd like to see releases "maintained".
>>> 2) new users prefer to start evaluating OFBiz with a release instead of the trunk
>>> 3) it is good for the project to announce new releases often
>>>  
>> True. Very true.
>>> 4) because our current policies (slowly increasing number of committers, peer reviews, etc...) our trunk is (and will be) more stable than older releases
>>>
>>>  
>> Again, why? I thought bug fixes are committed back to a release if appropriate. Is this not the case?
>>> Here is what I suggest:
>>> A) define an official release plan that says that we officially issue a release every approx 6 months (just to give you an idea): since there is no way to define a set of features that will go in the next release, our releases will be based on dates instead of features; but of course we can discuss the exact time of a release based on what is going on 1-2 weeks before the release date
>>>  
>> Don't release every 6 months. That's crazy. Once a year is sufficient. Put in place a real release plan including features, fixes and upgrade instructions in advance and then work towards making OFBiz something more than just a developer's playground. Make it "stable" by setting out in advance what "stable" means. And then work towards making each release meet the "stability" requirements. Just releasing something every 6 months or a year does not a "stable" release make.
>>> B) there is no guarantee that patches will be backported to releases, that upgrade scripts will be created from release to release
>>>
>>>  
>> If so, then what is the point of even having releases? Just have nightly trunk builds and everyone is happy.
>>> It is true that the ASF policies ask that a release, that represents the code that is distributed by the ASF to the larger audience of users, is a "stable" deliverable; but if we continue with the current approach, even if it is intended to get a stable and maintained release, what we are really doing is distributing the code in the trunk (this is what we suggest our users to use instead of the release), not the "stable" release.
>>>
>>>  
>> IMHO, one of the true benefits of going with the ASF is the structure and stability they enforce on umbrella projects. Why not use these "restrictions" to the project's advantage instead of trying to circumvent them. I think I'm agreeing with you in that maybe "we" should start pointing users to releases instead of trunk code. Just a thought.
>>
>> Ruth
>>> What do you think?
>>>
>>> Jacopo
>>>
>>>
>>>
>>>
>>>  
>
>

[Adam Heath-2]

Adrian Crum wrote:
> Plus, some of the technical work being done in the framework is intended
> to make it easier for end-user-oriented contributors to write code.
>
> The conversion framework is a perfect example: I just wanted to be able
> to pass a TimeDuration instance around the framework, but couldn't
> because of limitations in the framework. Once the conversion framework
> is completely integrated, all developers will be able to pass
> user-defined Java types around the framework easily.

And, of course, the webslinger stuff I have started to commit won't
nescessarily be used until the final step.  This means there will be a
window where ofbiz has to maintain the code, with no apparent use case
for it.

However, what is good, is that Adrian's conversion framework was a
more advanced version of a library that webslinger already had, and I
was able to convert over to it with relative ease.

[Ruth Hoffman-2]

Hi David:
First, sorry I'm not making myself clear. I'm not asking that anything
be done. I only wished to reply to Jacopo's query "What do you think?"
Regards,
Ruth


David E Jones wrote:

> I saw the comment below about OFBiz becoming a "developers playground." I'll admit I have been thinking for a while that many contributions do not meet business (ie end-user) needs nor do they make it easier to meet end-user needs, and in fact in some cases even make that more difficult. However, my opinion is that this is caused by end-user oriented contributors being less active than technically oriented contributors, in fact I would say FAR less active, and less active now than in years past.
>
> Still, all of this comes down to the same message: if you want something to be done, or to be a certain way, either you figure out how to get other people to do it or you do it yourself.
>
> -David
>
>
> On Feb 15, 2010, at 9:03 AM, Ruth Hoffman wrote:
>
>  
>> Jacopo Cappellato wrote:
>>    
>>> I know this subject has been already discussed several times in the past, but I still would like to rethink our strategy for releases in OFBiz.
>>> I am under the impression that, considering the release branch 9.04, that is our latest release branch:
>>> * there are more users than maintainers
>>>  
>>>      
>> This is probably true. But to get a better understanding of who is using what, maybe we could look into getting download statistics? I have already put in a request to the infrastructure team for this, but have not heard anything back from them. Maybe a project committer has more clout and could get this implemented? Without that, we are just speculating about who is doing what with the code.
>>    
>>> * because of this, no real maintenance plan, test strategy etc.. has been created around it from the community of users and interested parties (in fact we were not really able to officially release it)
>>> * a lot of new users start eveluating OFBiz from that instead of the trunk
>>> * it is rather old, several new features are missing and also code improvements (that could fix bugs etc)
>>>  
>>>      
>> I thought all the bug fixes were retrofitted to the release? Is this not true?
>>    
>>> * because of this, it tends to be less stable than the trunk
>>>  
>>>      
>> How could the release be less stable than the trunk if bug fixes are applied to the release and the trunk?
>>    
>>> The main cons of this situations are the following:
>>> 1) not real interest in maintaining a release branch means that we will not be able to spend time on it and officially release it: the OFBiz community will miss the advantage of using the marketing channel represented by a new release
>>> 2) new users will get the wrong impression that the project is slowing improving if they just get the releases
>>>  
>>>      
>> Project committers should consider this behavior pattern: Most people evaluating code will not want the latest release. They will patiently wait until someone else has taken on the risk (and reward) of debugging it. Do not think that just because the project releases a new release of OFBiz, that everyone will stampede to get it. Far from it. Now if we had download statistics we could verify my claim, but I'd be willing to bet real money, that the only people who will jump to download this new release will be project committers.
>>    
>>> 3) it is much easier for a user to stay up to date with the trunk rather than with a release: I mean that there is no guarantee that one day someone will build an upgrade plan from the old release to the new one... users of the old release may be left behind forever
>>>
>>>  
>>>      
>> I think you mistake "user" with "committer". What "user" is actively trying to stay current with the trunk? Just some food for thought.
>>    
>>> What I suggest is based on the following assumptions:
>>> 1) community is not ready or interested in maintaining releases
>>>  
>>>      
>> Only the "committers" are not interested. Users out there may have a different story to tell. Personally, I'd like to see releases "maintained".
>>    
>>> 2) new users prefer to start evaluating OFBiz with a release instead of the trunk
>>> 3) it is good for the project to announce new releases often
>>>  
>>>      
>> True. Very true.
>>    
>>> 4) because our current policies (slowly increasing number of committers, peer reviews, etc...) our trunk is (and will be) more stable than older releases
>>>
>>>  
>>>      
>> Again, why? I thought bug fixes are committed back to a release if appropriate. Is this not the case?
>>    
>>> Here is what I suggest:
>>> A) define an official release plan that says that we officially issue a release every approx 6 months (just to give you an idea): since there is no way to define a set of features that will go in the next release, our releases will be based on dates instead of features; but of course we can discuss the exact time of a release based on what is going on 1-2 weeks before the release date
>>>  
>>>      
>> Don't release every 6 months. That's crazy. Once a year is sufficient. Put in place a real release plan including features, fixes and upgrade instructions in advance and then work towards making OFBiz something more than just a developer's playground. Make it "stable" by setting out in advance what "stable" means. And then work towards making each release meet the "stability" requirements. Just releasing something every 6 months or a year does not a "stable" release make.
>>    
>>> B) there is no guarantee that patches will be backported to releases, that upgrade scripts will be created from release to release
>>>
>>>  
>>>      
>> If so, then what is the point of even having releases? Just have nightly trunk builds and everyone is happy.
>>    
>>> It is true that the ASF policies ask that a release, that represents the code that is distributed by the ASF to the larger audience of users, is a "stable" deliverable; but if we continue with the current approach, even if it is intended to get a stable and maintained release, what we are really doing is distributing the code in the trunk (this is what we suggest our users to use instead of the release), not the "stable" release.
>>>
>>>  
>>>      
>> IMHO, one of the true benefits of going with the ASF is the structure and stability they enforce on umbrella projects. Why not use these "restrictions" to the project's advantage instead of trying to circumvent them. I think I'm agreeing with you in that maybe "we" should start pointing users to releases instead of trunk code. Just a thought.
>>
>> Ruth
>>    
>>> What do you think?
>>>
>>> Jacopo
>>>
>>>
>>>
>>>
>>>  
>>>      
>
>
>  

[Chris Snow-3]

As part of the release plan, could we create some formal roles
responsible for certain aspects for each release?  i.e. people
responsible for:

- migration from previous release
- documentation
- patch management
- etc


David E Jones wrote:

> A release plan would be great. How are we going to do that, or what would it look like?
>
> -David
>
>
> On Feb 15, 2010, at 1:20 PM, Sharan-F wrote:
>
>  
>> Hi
>>
>> It sounds like there 's some confusion as to whether the release branches
>> are being updated with bug fixes or not. I thought they were.
>>
>> My focus has been pretty much been on OFBiz documentation and I find it
>> very, very hard to document things as they are changing so fast. Features
>> seemed to be added with no hint of documentation or even a spec.  The only
>> way to find out how things work,  is trial and error and not everyone is
>> interested in (or capable of) looking at or understanding the code.
>>
>> Personally I'd like to see a yearly release plan so that we could at least
>> ensure that we had enough time to make it truly stable and that the right
>> documentation is in place to support the release.
>>
>> Thanks
>> Sharan
>>
>> --
>> View this message in context: http://n4.nabble.com/Rethinking-our-release-strategy-tp1555976p1556580.html
>> Sent from the OFBiz - Dev mailing list archive at Nabble.com.
>>    
>
>  

[Adrian Crum-2]

Or even informal roles.

For example: My employer doesn't use eCommerce, so I am not qualified to be responsible for that. But, I will gladly take on responsibility for areas of the project my employer uses - like Work Effort and Asset Maintenance.

I have been thinking about that lately - each contributor or committer could list the areas they feel comfortable with overseeing. It would be strictly voluntary - not a serious commitment or anything.

The reason I suggest it is because I recognize my own limitations - I can't review and comment on EVERYTHING. I have a feeling other committers are in the same situation. So, why not catalog our strengths, and assume responsibility for pieces of the project we feel confident with - instead of (right or wrong) feeling responsible for the whole project.

W could use the service provider Wiki page as a model - create a Wiki page where everyone advertises what areas of the project they feel knowledgeable in.

-Adrian


--- On Mon, 2/15/10, Christopher Snow <[hidden email]> wrote:

> From: Christopher Snow <[hidden email]>
> Subject: Re: Rethinking our release strategy
> To: [hidden email]
> Date: Monday, February 15, 2010, 10:16 PM
> As part of the release plan, could we
> create some formal roles responsible for certain aspects for
> each release?  i.e. people responsible for:
>
> - migration from previous release
> - documentation
> - patch management
> - etc
>
>
> David E Jones wrote:
> > A release plan would be great. How are we going to do
> that, or what would it look like?
> >
> > -David
> >
> >
> > On Feb 15, 2010, at 1:20 PM, Sharan-F wrote:
> >
> >   
> >> Hi
> >> It sounds like there 's some confusion as to
> whether the release branches
> >> are being updated with bug fixes or not. I thought
> they were.
> >>
> >> My focus has been pretty much been on OFBiz
> documentation and I find it
> >> very, very hard to document things as they are
> changing so fast. Features
> >> seemed to be added with no hint of documentation
> or even a spec.  The only
> >> way to find out how things work,  is trial
> and error and not everyone is
> >> interested in (or capable of) looking at or
> understanding the code.
> >> Personally I'd like to see a yearly release plan
> so that we could at least
> >> ensure that we had enough time to make it truly
> stable and that the right
> >> documentation is in place to support the release.
> >>
> >> Thanks
> >> Sharan
> >>
> >> -- View this message in context: http://n4.nabble.com/Rethinking-our-release-strategy-tp1555976p1556580.html
> >> Sent from the OFBiz - Dev mailing list archive at
> Nabble.com.
> >>     
> >
> >   
>
>

[Chris Snow-3]

It's kind of funny that ofbiz promotes the use of best practice in many
areas
(http://cwiki.apache.org/confluence/dosearchsite.action?queryString=ofbiz%20best%20practice)
EXCEPT release management.

Ruth Hoffman wrote:

> Hi Jacopo:
> Its nice to see this kind of thought going into a release strategy.
> Thanks for the effort. Please see my comments inline. Note, this is
> just my opinion based on years of working with big complex IT
> organizations. These are the kind of "users" who ultimately would be
> implementing OFBiz (I hope...):
>
> Jacopo Cappellato wrote:
>> I know this subject has been already discussed several times in the
>> past, but I still would like to rethink our strategy for releases in
>> OFBiz.
>> I am under the impression that, considering the release branch 9.04,
>> that is our latest release branch:
>> * there are more users than maintainers
>>  
> This is probably true. But to get a better understanding of who is
> using what, maybe we could look into getting download statistics? I
> have already put in a request to the infrastructure team for this, but
> have not heard anything back from them. Maybe a project committer has
> more clout and could get this implemented? Without that, we are just
> speculating about who is doing what with the code.
>> * because of this, no real maintenance plan, test strategy etc.. has
>> been created around it from the community of users and interested
>> parties (in fact we were not really able to officially release it)
>> * a lot of new users start eveluating OFBiz from that instead of the
>> trunk
>> * it is rather old, several new features are missing and also code
>> improvements (that could fix bugs etc)
>>  
> I thought all the bug fixes were retrofitted to the release? Is this
> not true?
>> * because of this, it tends to be less stable than the trunk
>>  
> How could the release be less stable than the trunk if bug fixes are
> applied to the release and the trunk?
>> The main cons of this situations are the following:
>> 1) not real interest in maintaining a release branch means that we
>> will not be able to spend time on it and officially release it: the
>> OFBiz community will miss the advantage of using the marketing
>> channel represented by a new release
>> 2) new users will get the wrong impression that the project is
>> slowing improving if they just get the releases
>>  
> Project committers should consider this behavior pattern: Most people
> evaluating code will not want the latest release. They will patiently
> wait until someone else has taken on the risk (and reward) of
> debugging it. Do not think that just because the project releases a
> new release of OFBiz, that everyone will stampede to get it. Far from
> it. Now if we had download statistics we could verify my claim, but
> I'd be willing to bet real money, that the only people who will jump
> to download this new release will be project committers.
>> 3) it is much easier for a user to stay up to date with the trunk
>> rather than with a release: I mean that there is no guarantee that
>> one day someone will build an upgrade plan from the old release to
>> the new one... users of the old release may be left behind forever
>>
>>  
> I think you mistake "user" with "committer". What "user" is actively
> trying to stay current with the trunk? Just some food for thought.
>> What I suggest is based on the following assumptions:
>> 1) community is not ready or interested in maintaining releases
>>  
> Only the "committers" are not interested. Users out there may have a
> different story to tell. Personally, I'd like to see releases
> "maintained".
>> 2) new users prefer to start evaluating OFBiz with a release instead
>> of the trunk
>> 3) it is good for the project to announce new releases often
>>  
> True. Very true.
>> 4) because our current policies (slowly increasing number of
>> committers, peer reviews, etc...) our trunk is (and will be) more
>> stable than older releases
>>
>>  
> Again, why? I thought bug fixes are committed back to a release if
> appropriate. Is this not the case?
>> Here is what I suggest:
>> A) define an official release plan that says that we officially issue
>> a release every approx 6 months (just to give you an idea): since
>> there is no way to define a set of features that will go in the next
>> release, our releases will be based on dates instead of features; but
>> of course we can discuss the exact time of a release based on what is
>> going on 1-2 weeks before the release date
>>  
> Don't release every 6 months. That's crazy. Once a year is sufficient.
> Put in place a real release plan including features, fixes and upgrade
> instructions in advance and then work towards making OFBiz something
> more than just a developer's playground. Make it "stable" by setting
> out in advance what "stable" means. And then work towards making each
> release meet the "stability" requirements. Just releasing something
> every 6 months or a year does not a "stable" release make.
>> B) there is no guarantee that patches will be backported to releases,
>> that upgrade scripts will be created from release to release
>>
>>  
> If so, then what is the point of even having releases? Just have
> nightly trunk builds and everyone is happy.
>> It is true that the ASF policies ask that a release, that represents
>> the code that is distributed by the ASF to the larger audience of
>> users, is a "stable" deliverable; but if we continue with the current
>> approach, even if it is intended to get a stable and maintained
>> release, what we are really doing is distributing the code in the
>> trunk (this is what we suggest our users to use instead of the
>> release), not the "stable" release.
>>
>>  
> IMHO, one of the true benefits of going with the ASF is the structure
> and stability they enforce on umbrella projects. Why not use these
> "restrictions" to the project's advantage instead of trying to
> circumvent them. I think I'm agreeing with you in that maybe "we"
> should start pointing users to releases instead of trunk code. Just a
> thought.
>
> Ruth
>> What do you think?
>>
>> Jacopo
>>
>>
>>
>>
>>  

[Scott Gray-2]

What would we achieve by cataloging the pieces of the project we feel confident with?  If it's not a serious commitment then how would it differ from what we do right now, aside from having an extra wiki page?

Regards
Scott

HotWax Media
http://www.hotwaxmedia.com

On 16/02/2010, at 12:04 AM, Adrian Crum wrote:

> Or even informal roles.
>
> For example: My employer doesn't use eCommerce, so I am not qualified to be responsible for that. But, I will gladly take on responsibility for areas of the project my employer uses - like Work Effort and Asset Maintenance.
>
> I have been thinking about that lately - each contributor or committer could list the areas they feel comfortable with overseeing. It would be strictly voluntary - not a serious commitment or anything.
>
> The reason I suggest it is because I recognize my own limitations - I can't review and comment on EVERYTHING. I have a feeling other committers are in the same situation. So, why not catalog our strengths, and assume responsibility for pieces of the project we feel confident with - instead of (right or wrong) feeling responsible for the whole project.
>
> W could use the service provider Wiki page as a model - create a Wiki page where everyone advertises what areas of the project they feel knowledgeable in.
>
> -Adrian
>
>
> --- On Mon, 2/15/10, Christopher Snow <[hidden email]> wrote:
>
>> From: Christopher Snow <[hidden email]>
>> Subject: Re: Rethinking our release strategy
>> To: [hidden email]
>> Date: Monday, February 15, 2010, 10:16 PM
>> As part of the release plan, could we
>> create some formal roles responsible for certain aspects for
>> each release?  i.e. people responsible for:
>>
>> - migration from previous release
>> - documentation
>> - patch management
>> - etc
>>
>>
>> David E Jones wrote:
>>> A release plan would be great. How are we going to do
>> that, or what would it look like?
>>>
>>> -David
>>>
>>>
>>> On Feb 15, 2010, at 1:20 PM, Sharan-F wrote:
>>>
>>>    
>>>> Hi
>>>> It sounds like there 's some confusion as to
>> whether the release branches
>>>> are being updated with bug fixes or not. I thought
>> they were.
>>>>
>>>> My focus has been pretty much been on OFBiz
>> documentation and I find it
>>>> very, very hard to document things as they are
>> changing so fast. Features
>>>> seemed to be added with no hint of documentation
>> or even a spec.  The only
>>>> way to find out how things work,  is trial
>> and error and not everyone is
>>>> interested in (or capable of) looking at or
>> understanding the code.
>>>> Personally I'd like to see a yearly release plan
>> so that we could at least
>>>> ensure that we had enough time to make it truly
>> stable and that the right
>>>> documentation is in place to support the release.
>>>>
>>>> Thanks
>>>> Sharan
>>>>
>>>> -- View this message in context: http://n4.nabble.com/Rethinking-our-release-strategy-tp1555976p1556580.html
>>>> Sent from the OFBiz - Dev mailing list archive at
>> Nabble.com.
>>>>      
>>>
>>>    
>>
>>
>
>
>

[Chris Snow-3]

Hi Scott,

It would be very useful for an outsider to see who is "responsible" for
what.

Also, I think we need roles other than "committer" for proper release
management.

Other roles would be useful too, such as "dependency manager" whose goal
is to ensure dependencies are correctly managed.

Thanks,

Chris

Scott Gray wrote:

> What would we achieve by cataloging the pieces of the project we feel confident with?  If it's not a serious commitment then how would it differ from what we do right now, aside from having an extra wiki page?
>
> Regards
> Scott
>
> HotWax Media
> http://www.hotwaxmedia.com
>
> On 16/02/2010, at 12:04 AM, Adrian Crum wrote:
>
>  
>> Or even informal roles.
>>
>> For example: My employer doesn't use eCommerce, so I am not qualified to be responsible for that. But, I will gladly take on responsibility for areas of the project my employer uses - like Work Effort and Asset Maintenance.
>>
>> I have been thinking about that lately - each contributor or committer could list the areas they feel comfortable with overseeing. It would be strictly voluntary - not a serious commitment or anything.
>>
>> The reason I suggest it is because I recognize my own limitations - I can't review and comment on EVERYTHING. I have a feeling other committers are in the same situation. So, why not catalog our strengths, and assume responsibility for pieces of the project we feel confident with - instead of (right or wrong) feeling responsible for the whole project.
>>
>> W could use the service provider Wiki page as a model - create a Wiki page where everyone advertises what areas of the project they feel knowledgeable in.
>>
>> -Adrian
>>    

[Scott Gray-2]

On 16/02/2010, at 12:31 AM, Christopher Snow wrote:

> Hi Scott,
>
> It would be very useful for an outsider to see who is "responsible" for what.

How would it be useful?

> Scott Gray wrote:
>> What would we achieve by cataloging the pieces of the project we feel confident with?  If it's not a serious commitment then how would it differ from what we do right now, aside from having an extra wiki page?
>>
>> Regards
>> Scott
>>
>> HotWax Media
>> http://www.hotwaxmedia.com
>>
>> On 16/02/2010, at 12:04 AM, Adrian Crum wrote:
>>
>>  
>>> Or even informal roles.
>>>
>>> For example: My employer doesn't use eCommerce, so I am not qualified to be responsible for that. But, I will gladly take on responsibility for areas of the project my employer uses - like Work Effort and Asset Maintenance.
>>>
>>> I have been thinking about that lately - each contributor or committer could list the areas they feel comfortable with overseeing. It would be strictly voluntary - not a serious commitment or anything.
>>>
>>> The reason I suggest it is because I recognize my own limitations - I can't review and comment on EVERYTHING. I have a feeling other committers are in the same situation. So, why not catalog our strengths, and assume responsibility for pieces of the project we feel confident with - instead of (right or wrong) feeling responsible for the whole project.
>>>
>>> W could use the service provider Wiki page as a model - create a Wiki page where everyone advertises what areas of the project they feel knowledgeable in.
>>>
>>> -Adrian
>>>    
>