Re: Release Strategy and Branch Support

[Jacques Le Roux <ja...@les7arts.com>]

Ron, I will be brief about this one. I think somebody already kinda answered about the PMC role in another thread.

For me, and it's a widely shared view at the ASF, the PMC roles should be very limited. We should, as much as possible, open discussion to the community.
Voting for new committers, PMC member and discussing about vulnerabilities are a few which can't obviously be open, but the others should (I missed 
some?).

Despite its name the Project Management Committee is not "managing" the project, it's more a shepherd.
So don't expect the PMC to lead the project, it's not its role. Everybody can start something, but then better to be sure you will support this thing...
To start something the best place is this dev ML

You said
 >I think that some of the participants underestimate the strength of a well-run open source project in attracting good people and getting great 
effort from volunteers.
You're absolutely right, the recent rejuvenation of the project shows it!

Jacques

Le 24/09/2014 17:21, Ron Wheeler a écrit :
> Good points.
>
> What I see as missing in the on-going discussion, is an understanding of the role of leadership in consensus building.
>
> There has been a bit of talk about "forcing" and "enforcement".
> The PMC needs to meet regularly to agree on policies and plans that everyone in the PMC thinks is the best way to run the project and produce a high 
> quality product in which users will be comfortable to invest.
>
> Once the memebers of the PMC and the contributors agree on a plan that involves work, the expectation, in an open source project, is that the team 
> members will take on the tasks that need to be done.
> Clearly, some people will have changes in their ordinary workload that prevents them from living up to their agreed commitment and you have to hope 
> that they have enough professionalism to help turn over their tasks to others and that others will step up to take on the tasks.
> People who routinely fail to do the tasks to which  they have committed during the planning phase will drift down the meritocracy.
> Those who step up to perform extra tasks will move up the ladder.
> Companies who require the release may also step up to the plate if the PMC needs additional resources and makes this known.
>
> As many have pointed out, the PMC does not have the traditional management tool of the "Goldern Rule" but this is not a very effective tool in a 
> world where most of your staff can get a pretty good increase in gold by switching jobs.
> The chair of the PMC and the senior "executives" are restricted to concepts like leadership, recognition, mutual respect and the other more 
> effective tools that good managers use in any company that is successful in software development and is able to retain staff.
>
> I think that some of the participants underestimate the strength of a well-run open source project in attracting good people and getting great 
> effort from volunteers.
> Certainly the recent Bug Crush is an impressive display of people and companies being willing to step up to the plate to complete a well-defined and 
> well-communicated task.
>
> The PMC needs to be very transparent about decisions that affect the community.
> To me, important ones are functionality roadmap changes, release roadmap changes, resource requirements and the intermediate term product vision.
>
> The PMC should be meeting to discuss important proposed code changes (framework API changes, major functionality, whatever the PMC thinks is 
> appropriate).
> The proponents should present their case in a way that covers the major issues that will affect the PMC and the product such as integration, 
> features, technology base, maintenance load, etc.
> The PMC and the proposing team should agree on a target release with some deadlines which the proposing team must achieve in order to be included in 
> the target release.
> A written policy and process would probably be helpful.
> Community involvement in the process needs to be focused on key issues and marketing issues in general.
>
> This is just a suggestion about how I would handle this
> The PMC can do what it wants but it needs to be transparent about the process so people don't waste a lot of time and get pissed off at last minute 
> rejection of their ideas.
> They should know ASAP how the PMC views their idea - great for inclusion into the core functionality, could be official OFBiz extension, is more 
> suitable as private extension that the PMC will not warranty, bad idea that would not integrate well with OFBiz for business or technical reasons, etc.
>
> The PMC and community should also clearly understand and dispassionately discuss the projected increase in complexity (dev and user), risk of 
> reduction of reliability, increased cost of on-going maintenance, strength of the team making the proposal for on-going maintenance, delay this 
> would cause in getting a release delivered, etc.
>
> I hope that these ideas help.
>
> Ron
>
> On 23/09/2014 5:26 PM, Jacques Le Roux wrote:
>> Hi Ron,
>>
>> You suggestions are often great, let's see now if the users community if sufficiently interested to help the OFBiz de team in achieving all this....
>>
>> Remember that the Apache way is more about flexiliby and lazy consensus[1]... In other words, as volunteers, we must adapt are the daily reality we 
>> all face...
>>
>> For the sake of OFBiz history, I must say that, not all but at least a good part of the applications at least, has been built in a process of 
>> agglomeration. Contributors (committers or not) work for a client, or their own needs, and decide to give their work to the community. If the 
>> quality is correct and the work is worth it, it's integrated by a committer (with the help of all volunteers). It's not the PMC nor any other group 
>> which really decides of what should be there or not. It's more individual decisions, filtered of course by everybody for the benefit of the 
>> community. Anyone can raise a hand and say his word, that's how it works actually, and it seems you are already aware of that :)
>>
>> I don't say we can't improve, but I doubt that more rules (enforced? how?) would help.
>>
>> For instance, sometimes I even wonder about this page https://cwiki.apache.org/confluence/display/OFBADMIN/OFBiz+Contributors+Best+Practices
>> Even if I still think it's helpful, is it not a bit frightening for a new comers (it's just an exampled not really a question ;)
>>
>> More answers inline...
>>
>> Jacques
>> [1] http://www.apache.org/foundation/voting.html#LazyConsensus
>>
>> Le 23/09/2014 07:40, Ron Wheeler a écrit :
>>> I think that having a discussion about the policy followed by regular (annual or semi-annual) discussions on the roadmap with the PMC and the user 
>>> community will have a couple of effects
>>> - fewer surprises caused by users showing up at the last minute with requests to extend the EOL or EOS (End-Of-Sales->no longer on the download 
>>> page and no longer recommended for new uers) dates.
>>> - more commitment from the user community to help with maintenance or to support sub-projects financially or with resources.
>>>
>>>
>>> I have not been here long enough to know how the PMC decides on what features will be in a new release or how investigation of new sub-projects 
>>> such as the Workflow project, get accepted as "good" ideas or rejected as "out-of-scope" or insufficiently supported by the community.
>>> Is there a formal procedure that I would have to follow to get my favorite feature included in 14.XX??
>> Nope as barely explained above
>>>
>>> How does the PMC close off the 14.XX spec?
>> When it's ready :D By lazy consensus (anybody can raises a hand, but he must be in tune with what happens)
>>> I assume that there is a process that involves the PMS and contributors who will be providing the resources and the user-community that determines 
>>> the pluses and minuses of the proposed change.
>> Nope, we try to avoid "'paper work" as much as possible
>>>
>>> What are the current new features that are being considered for the 2014.XX feature freeze?
>>> Is this discussion documented somewhere?
>> Nope, but Jira can give you more than a hint 
>> https://issues.apache.org/jira/browse/OFBIZ/?selectedTab=com.atlassian.jira.jira-projects-plugin:roadmap-panel
>> This the way we are recently going and it's a huge progress in comparison of what we had before (almost nothing and despite you see: OFBiz is there)
>>>
>>> The people doing the investigation of the Workflow  engine presumably need to know when they have to get their proposal finished to make it into 
>>> the 2014 feature freeze.
>> Obviously, this does not depend on us (OFBiz dev team) but them (to be ready and ask to wait if necessary)
>>>
>>> Are their guidelines about how the form and content of this proposal (features, dependent software , integration issues, resources required, 
>>> estimated time to deliver)?
>> Nope, would you suggest something?
>>
>> Jacques
>>>
>>> Ron
>>>
>>>
>>> On 23/09/2014 12:35 AM, Jacopo Cappellato wrote:
>>>> On Sep 22, 2014, at 9:58 PM, Jacques Le Roux <ja...@les7arts.com> wrote:
>>>>
>>>>> <<the problem is not everybody is aware of bug fixes backported or not. The official download page http://ofbiz.apache.org/download.html, says 
>>>>> that we
>>>>> stabilize releases with bug fixes. It's not quite clear if we are backporting all or only some bug fixes.>>
>>>>>
>>>> A more formal rule would be:
>>>> * commits to the trunk from Jira tickets of type Bugs can and *should* be backported to all the active releases
>>>> * commits to the trunk from Jira tickets of type different from Bugs need an explicit approval from the committers group before they can be 
>>>> backported to a specific active release
>>>>
>>>>> <<I think we should make that clear and expose a way to users for them to more
>>>>> "easily" maintain the releases they use.>>
>>>> +1 see below
>>>>
>>>>> As suggested Ron we could also define our own or refer to http://en.wikipedia.org/wiki/End-of-life_%28product%29 and
>>>> Rather than referring to an external site, in my opinion we could improve (and make more evident) the information we already have in the download 
>>>> page where we already mention a tentative end of life; for example now we have:
>>>>
>>>> • April 2015 - Apache OFBiz 12.04.06 (last release of the 12.04 series)
>>>>
>>>> But when we specify an end of life, we should also make clear a few things:
>>>> * this is a community goal, and the help from the community is required to meet the goal (i.e. it is not guaranteed)
>>>> * the plan is flexible; for example, if a group of interested users will show up today telling us that they want to actively maintain the release 
>>>> branch 11.04 even if the scheduled end of life is passed, I would not object to it; the opposite is also true: if we experience low 
>>>> interest/support (from committers and non committers) in maintaining a given release branch we could vote to modify its end of life
>>>>
>>>>> Now we need to think "technical" and automatize as possible with Jira
>>>> In my opinion it is possible to easily derive this from Jira, after the version configuration refactoring I did a few weeks ago (however the 
>>>> information will be more accurate with new releases).
>>>> The idea is to run a query on Jira with the following constraints:
>>>> project = OFBiz
>>>> type = Bug
>>>> status = not resolved
>>>> version *affected* = the release branch we are interested in (e.g. "release branch 12.04" OR the current latest release in the same branch (e.g. 
>>>> "Release 12.04.05")
>>>>
>>>> The result should be a list of bugs affecting the release branch and/or the latest release in that branch; these are the bugs that are known and 
>>>> outstanding.
>>>> For them we will need help from the community (committers and non committers) to fix the bugs or backport existing fixes.
>>>>
>>>> In the download page, we could add two links (to Jira) next to each available release:
>>>> 1) known bugs (links to the above report)
>>>> 2) release notes (link to the release notes available now)
>>>>
>>>> One technicality is the following: when we release a new release from the branch (e.g. 12.04.06), if there are open tickets with "version 
>>>> affected" set to the current version (e.g. 12.04.05) then we will have to bulk update all of them by adding also the new version (e.g. add 
>>>> "12.04.06" to affected version).
>>>>
>>>>> What I have read so far from Jacopo seems a good start to me
>>>> Thank you for confirming that we are on the same page. This is actually part of the plan I had in mind to maintain better release information 
>>>> when I started the version refactoring in Jira, and this conversation is helping to refine some points.
>>>>
>>>> Jacopo
>>>
>>>
>>
>
>