On 22/09/2014 9:51 AM, Jacopo Cappellato wrote:
Some ideas to manage this workflow in a better way:
* if a bug that affects an old release branch is not backported, when we resolve the
ticket we create a new one that is linked to the original and has the field
"affected releases" set the affected old branch; this will be a placeholder for
the ones willing to maintain the old branch
The "current stable release" should be the first place a bug is fixed.
* about the end of life of release branches: when we perceive a decreasing
interest from the community to backport to an old release, we could run a vote
to decide if the community is ok to anticipate the end of life of a release
branch; the ones that vote to keep the branch alive could offer to help in the
backporting process
Very good idea. You might want to think about setting a suggested EOL
date when the release is issued.
It would be helpful to the user community to know that by such and such
a date, this branch will no longer be maintained.
This would allow the user to understand the TCO of switching to it.
I get a sense that :
a) 13.07 took too long to release and got to a point where a lot of the
main contributors are already using it in production and have a business
interest in maintaining it and no business interest in earlier releases.
b) many of the end-users of OFBiz do not have to deal with the project
directly and have SLA's and maintenance commitments from SI companies
that insulate them from the OFBiz project.
Ron
Jacopo
On Sep 22, 2014, at 12:48 PM, Adrian Crum <[email protected]>
wrote:
This discussion seems to be spinning off into a strange direction.
I stated my personal perspective on backporting bug fixes, and the amount of
backporting my free time allows. Others are free to disagree with me.
I might be wrong, but it seems to me you are suggesting the PMC should twist my
arm to do a more thorough job of backporting bug fixes. If that is true, then
you need to understand that is not the PMC's role. Even if it was, I would
reject that attempt and restate my viewpoint: If the bug fix backport is
important enough to someone, then they will do it themselves.
Even if that isn't what you are suggesting, you seem to be TELLING the PMC its
role, instead of LEARNING the PMC's role.
Adrian Crum
Sandglass Software
www.sandglass-software.com
On 9/21/2014 2:45 PM, Ron Wheeler wrote:
The PMC has to manage the team.
It is called a Project MANAGEMENT Committee for a reason.
You are right that the PMC can not order anyone to do anything.
Apache is based on volunteers working together as a team.
That does not mean that the Committee is powerless.
It has to work in a collaborative way to manage the project.
This means setting policy, setting priorities and assigning tasks or
more accurately soliciting volunteers to do tasks that the PMC
identifies as important.
It means agreeing on dates by which tasks will be performed and taking
action when it is clear that volunteers are not going to be able to
finish work that they have agreed to do for whatever reason. This action
may be soliciting additional help, revising dates to match reality or
revising scope or a combination.
The PMC should make sure that the people fixing the bugs understand that
the bugs need to be fixed in all supported versions if that is the
Policy of the PMC.
If they are not willing to follow the direction of the PMC, the the PMC
needs to act.
The "merit" in meritocracy does not just mean code. It also means team
commitment, collaboration skills and management. If someone does not
want to work in a collaborative way and only does the parts of a task
that appeals to them, they should be treated in the same way as someone
who commits code that only fixes the interesting part of the bug and
breaks other code or someone who doesn't want to use the framework and
rewrites code to directly access data rather than using the framework.
Some behaviour is not acceptable to the PMC regardless of how much time
the volunteer is willing to put in.
How often does the PMC meet?
When was the last set of minutes published?
What is the most significant policy decision or other issue that the PMC
is currently working on?
When was the last PMC meeting about the release roadmap?
Ron
On 21/09/2014 8:50 AM, Jacopo Cappellato wrote:
The PMC doesn't manage a team: we can't ask people to work on what we
think is important.
The persons that contribute code to the project (and backport
features) are persons like you and me, and the PMC doesn't have the
authority or will to assign tasks to them.
In fact, I doubt I could ask you to test and backport to 12.04 all the
59 features that the have been committed yesterday :-)
Regards,
Jacopo
On Sep 21, 2014, at 2:31 PM, Ron Wheeler
<[email protected]> wrote:
No one has time to fix all of the bugs by themselves but by managing
the team, it should be possible to get all of the required work done.
The PMC needs to develop a consensus about how bugs are handled in
the official releases and then make lists of things that need doing.
If a bug is found and added to he JIRA, determining which releases it
applies to should be part of the analysis.
If a patch is developed it should be possible to apply it to each
release at the same time.
Ron
On 20/09/2014 12:47 PM, Adrian Crum wrote:
I don't have time to maintain 4 code bases (trunk + 3 branches). I
will fix things in the trunk, and I will backport those fixes to the
most recent branch. I have no interest in older branches. If someone
else is using them, then they can create a patch for them. So, I
have no issues with releasing old branches with missing fixes -
because if anyone really cared about them they would work harder to
maintain them.
Adrian Crum
Sandglass Software
www.sandglass-software.com
On 9/20/2014 5:29 PM, Jacques Le Roux wrote:
It seems a bit weird to me to officially release code with bugs
when we
have already bug fixes in trunk
Jacques
Le 20/09/2014 17:17, Adrian Crum a écrit :
From my perspective, anyone wanting to use older versions can
backport
the changes themselves - either locally, or in the release
branches by
providing a patch.
Adrian Crum
Sandglass Software
www.sandglass-software.com
On 9/20/2014 4:07 PM, Ashish Vijaywargiya wrote:
Hello Jacques,
Thanks for your kind words. We started this event considering the
fact
to provide fixes for trunk and latest release branch which is
13.07. It
will be of great help if someone from community could pick and
back port
the required changes to Release Branch 12.04. In future if we get
time
we will also be taking care of back porting to R12.04.
We didn't back port changes in R11.04 just because it is very old
branch
and very soon will not be maintained. Thanks.
--
Kind Regards
Ashish Vijaywargiya
HotWax Media - est. 1997
ApacheCon US 2014 Silver Sponsor
http://na.apachecon.com/sponsor/our-sponsors
On Saturday 20 September 2014 05:01 PM, Jacques Le Roux wrote:
Le 20/09/2014 13:28, Jacques Le Roux a écrit :
Hi,
It's great to see a second Bug Crush effort!
I have though a question, I see that you (HotWax Media team) only
backport bug fixes to the R13 branch.
I guess it's intended, so why?
I ask this because I already found myself trying to fix issues
in R12
and R11 branches (I know will be soon no longer maintained R11 )
and
found they were already backported in R13
Jacques
--
Ron Wheeler
President
Artifact Software Inc
email: [email protected]
skype: ronaldmwheeler
phone: 866-970-2435, ext 102
--
Ron Wheeler
President
Artifact Software Inc
email: [email protected]
skype: ronaldmwheeler
phone: 866-970-2435, ext 102
