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 * 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
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 >>>> >>> >> >>
