From morrone2 at llnl.gov Thu Aug 1 23:52:40 2013 From: morrone2 at llnl.gov (Christopher J. Morrone) Date: Thu, 01 Aug 2013 16:52:40 -0700 Subject: [cdwg] Monitoring Ticket Progress In-Reply-To: <51F80475.5070901@llnl.gov> References: <51F80475.5070901@llnl.gov> Message-ID: <51FAF4C8.4010503@llnl.gov> Folks asked on last CDWG for some clarification about the issues that I noted with the proposed gerrit filters. Here are some details. Lets start with the following filter, which is intended to show all patches that have not yet completed the review process. http://review.whamcloud.com/#/q/status:open+age:1mon+Verified%252B1+-Verified-1+-CodeReview-1+-CodeReview-2,n,z We can ignore that it isn't also filtering out other projects and branches other than master. Those are easily fixable. But there are problems that are less easily fixed. For instance, it returns this ticket: http://review.whamcloud.com/#/c/6520/ At the time of writing this email, that has two +1 CodeReviews, and has been sent to the "Gerrit Gatekeeper" for landing. That patch is should not appear in the "waiting for reviews list". Instead it should be on the "reviewed, but not landed" list. But conversely, the "reviewed but not landed" filter is this: http://review.whamcloud.com/#/q/status:open+age:1mon+Verified%252B1+CodeReview%252B2+-Verified-1+-CodeReview-1+-CodeReview-2,n,z and the mentioned ticket does _not_ appear on that list. That filter is, in fact, grossly under reporting the number of patches that are fully reviewed and waiting to land. It only shows the patches that have gotten a +2 CodeReview, which is only a subset of the patches that are reviewed and waiting to land. Chris From denis_kondratenko at xyratex.com Fri Aug 2 11:13:24 2013 From: denis_kondratenko at xyratex.com (Denis Kondratenko) Date: Fri, 2 Aug 2013 14:13:24 +0300 Subject: [cdwg] Monitoring Ticket Progress Message-ID: <91A3A1C9-6017-4CDF-BEA3-C74568416239@xyratex.com> Chris, I see your point now. We are not using gerrit with a way it was designed for (when +2 should be there to submit; seems our gatekeepers doing +2). You are right it is impossible to build search for gatekeeper from plain gerrit without it modification. There are still some ways to workaround that: * http://en.wikibooks.org/wiki/Git/Gerrit_Code_Review (A hook could - for instance - allow a project to install an automated gatekeeper to vote +2 'submit approved' when sufficient +1 votes 'looks good to me' have been received) * http://review.whamcloud.com/Documentation/prolog-cookbook.html#_example_12_1_1_2_code_review (but I don't know if it will get right searches..) * in Xyratex we are using Jira state "Landing" to build filter for gatekeeper. OK, even if we could't separate gatekeeper changes from other, filter is still useful to check issues with no feedback for a long time. Thanks, Denis -- ------------------------------ For additional information including the registered office and the treatment of Xyratex confidential information please visit www.xyratex.com ------------------------------ -------------- next part -------------- An HTML attachment was scrubbed... URL: From morrone2 at llnl.gov Fri Aug 2 20:21:17 2013 From: morrone2 at llnl.gov (Christopher J. Morrone) Date: Fri, 02 Aug 2013 13:21:17 -0700 Subject: [cdwg] ldiskfs build system changes Message-ID: <51FC14BD.7060400@llnl.gov> Hi folks, I want to make people aware of the following ldiskfs patch that I have under review: http://review.whamcloud.com/6850 I don't suspect that anyone other than LLNL has been building ldiskfs externally to lustre. This patch will remove the ability to do "--with-ldiskfs=/some/other/location". My best guess is that no one other than LLNL is effected by this change. With the rest of the changes to the ldiskfs build system and packaging made by this patch, LLNL will be happy to stop using that option. But folks should be aware of that change. If that change will impact you negatively, please let me know. We'll work out a solution that will work for everyone. Chris From morrone2 at llnl.gov Fri Aug 2 22:27:08 2013 From: morrone2 at llnl.gov (Christopher J. Morrone) Date: Fri, 02 Aug 2013 15:27:08 -0700 Subject: [cdwg] Monitoring Ticket Progress In-Reply-To: <91A3A1C9-6017-4CDF-BEA3-C74568416239@xyratex.com> References: <91A3A1C9-6017-4CDF-BEA3-C74568416239@xyratex.com> Message-ID: <51FC323C.10502@llnl.gov> Thanks Denis, those are some great leads! I think it would be excellent to investigate one or both of those links to get gerrit enhanced to match our workflow. I opened ticket LU-3690 as a task to track this. I like the sounds of the prolog-cookbook approach. But I see what you mean, it is not clear to me that making a patch "submitable" is sufficient to give us something that we can use as search term. So that may make the perl "hook for a +2 approval from a simple quorum of +1 votes" a better option. I am not sure that I understood your final comment about a Jira "Landing" state. Chris On 08/02/2013 04:13 AM, Denis Kondratenko wrote: > Chris, > > I see your point now. We are not using gerrit with a way it was designed > for (when +2 should be there to submit; seems our gatekeepers doing +2). > You are right it is impossible to build search for gatekeeper from plain > gerrit without it modification. > > There are still some ways to workaround that: > * http://en.wikibooks.org/wiki/Git/Gerrit_Code_Review (A hook could - > for instance - allow a project to install an automated gatekeeper to > vote +2 'submit approved' when sufficient +1 votes 'looks good to me' > have been received) > * > http://review.whamcloud.com/Documentation/prolog-cookbook.html#_example_12_1_1_2_code_review (but > I don't know if it will get right searches..) > * in Xyratex we are using Jira state "Landing" to build filter for > gatekeeper. > > OK, even if we could't separate gatekeeper changes from other, filter is > still useful to check issues with no feedback for a long time. > > Thanks, > Denis > > > ------------------------------------------------------------------------ > For additional information including the registered office and the treatment of Xyratex confidential information please visitwww.xyratex.com > > ------------------------------------------------------------------------ > > > _______________________________________________ > cdwg mailing list > cdwg at lists.opensfs.org > http://lists.opensfs.org/listinfo.cgi/cdwg-opensfs.org > From peter.a.jones at intel.com Sat Aug 3 00:27:53 2013 From: peter.a.jones at intel.com (Jones, Peter A) Date: Sat, 3 Aug 2013 00:27:53 +0000 Subject: [cdwg] Lustre 2.5 update - August 2nd 2013 Message-ID: Hi there Here is an update on the Lustre 2.5 release. Landings ======== -A number of landings made - see http://git.whamcloud.com/?p=fs/lustre-release.git;a=shortlog;h=refs/heads/master -Now that the Feature Freeze has passed, the full list of features in 2.5 is known Xattr Cache (LU-2869) LNET router improvements (LU-2934/2950) Errno translation (step towards sparc support) (LU-2743) Permanent Parameters option for lctl set_param (LU-3155) Reduce ldlm_poold cpu utilization (LU-2924) HSM (LU-3608) There is still some remaining work for this to be feature complete. As per the discussion on the CDWG call on Wednesday we are going to see we have extended the landing window for these patches only in view of the high interest in this feature and the belief that this work is close to completion. I will send out another update early next week with the final outcome on this. * POSIX Copy tool http://review.whamcloud.com/#/c/4737/ * Disaster Recovery http://review.whamcloud.com/#/c/7027/ * Coordinator http://review.whamcloud.com/#/c/6912/ Testing ======= - Testing on the 2.4.52 tag is complete; testing on the 2.4.53 tag is ongoing Blockers ======== -Full list available at https://jira.hpdd.intel.com/issues/?jql=project%20%3D%20LU%20AND%20fixVersion%20%3D%20%22Lustre%202.5.0%22%20AND%20resolution%20%3D%20Unresolved%20AND%20priority%20%3D%20Blocker%20ORDER%20BY%20key%20DESC -If there are any issues not presently marked as blockers that you believe should be, please let me know Other ===== -We are trialling using the Fix In Release field for the 2.5 release to track work hoped to be included in the release; this means that a fuller picture of the progress on the release can be viewed at https://jira.hpdd.intel.com/browse/LU/fixforversion/10295#selectedTab=com.atlassian.jira.plugin.system.project%3Aversion-issues-panel -Feature Freeze is now in effect and 2.5 has entered its stabilization period. We encourage community members to test out the latest code on master and to use JIRA (https://jira.hpdd.intel.com) to report any bugs encountered -You can also keep up to date with matters relating to the 2.5 release on the CDWG wiki - http://wiki.opensfs.org/Lustre_2.5.0 Thanks Peter From denis_kondratenko at xyratex.com Sat Aug 3 06:43:15 2013 From: denis_kondratenko at xyratex.com (Denis Kondratenko) Date: Sat, 3 Aug 2013 09:43:15 +0300 Subject: [cdwg] Monitoring Ticket Progress In-Reply-To: <51FC323C.10502@llnl.gov> References: <91A3A1C9-6017-4CDF-BEA3-C74568416239@xyratex.com> <51FC323C.10502@llnl.gov> Message-ID: In our Jira workflow we have different states like: Open, In Progress, Review, Landing and etc. It is engineer responsibility to maintain correct state. After engineer see that it has two +1, he/she transfers ticket to state Landing. Gatekeeper has search for all tickets at this state and see what is ready to land. Actually gatekeeper (or other people) could subscribe to search and receive e-mail with it results. Having different states in Jira gives us more clear vision what is the state of the project and where issues are. Using Kanban GreenHopper RapidBoard you even could get many statistical info about time that was spend in each state and other charts/stat. Limiting work in progress in each state you could easily see where you having issues in process. BTW our UpstreamLanding column is always red, that's why we always trying to find a way to improve process of upstream landing. Kanban def: http://www.infoq.com/resource/minibooks/kanban-scrum-minibook/en/pdf/KanbanAndScrumInfoQVersionFINAL.pdf https://www.atlassian.com/software/greenhopper/overview/kanban Maybe having RapidBoard at Intel Jira with such info for sustaining will give to all of us more visibility and stat. But that requires Jira workflow changes and process changes. On Aug 3, 2013 1:27 AM, "Christopher J. Morrone" wrote: > Thanks Denis, those are some great leads! > > I think it would be excellent to investigate one or both of those links to > get gerrit enhanced to match our workflow. I opened ticket LU-3690 as a > task to track this. > > I like the sounds of the prolog-cookbook approach. But I see what you > mean, it is not clear to me that making a patch "submitable" is sufficient > to give us something that we can use as search term. So that may make the > perl "hook for a +2 approval from a simple quorum of +1 votes" a better > option. > > I am not sure that I understood your final comment about a Jira "Landing" > state. > > Chris > > On 08/02/2013 04:13 AM, Denis Kondratenko wrote: > >> Chris, >> >> I see your point now. We are not using gerrit with a way it was designed >> for (when +2 should be there to submit; seems our gatekeepers doing +2). >> You are right it is impossible to build search for gatekeeper from plain >> gerrit without it modification. >> >> There are still some ways to workaround that: >> * http://en.wikibooks.org/wiki/**Git/Gerrit_Code_Review(A hook could - >> for instance - allow a project to install an automated gatekeeper to >> vote +2 'submit approved' when sufficient +1 votes 'looks good to me' >> have been received) >> * >> http://review.whamcloud.com/**Documentation/prolog-cookbook.** >> html#_example_12_1_1_2_code_**review(but >> I don't know if it will get right searches..) >> * in Xyratex we are using Jira state "Landing" to build filter for >> gatekeeper. >> >> OK, even if we could't separate gatekeeper changes from other, filter is >> still useful to check issues with no feedback for a long time. >> >> Thanks, >> Denis >> >> >> ------------------------------**------------------------------** >> ------------ >> For additional information including the registered office and the >> treatment of Xyratex confidential information please visitwww.xyratex.com < >> http://www.xyratex.com/> >> >> ------------------------------**------------------------------** >> ------------ >> >> >> ______________________________**_________________ >> cdwg mailing list >> cdwg at lists.opensfs.org >> http://lists.opensfs.org/**listinfo.cgi/cdwg-opensfs.org >> >> > ______________________________**_________________ > cdwg mailing list > cdwg at lists.opensfs.org > http://lists.opensfs.org/**listinfo.cgi/cdwg-opensfs.org > -- ------------------------------ For additional information including the registered office and the treatment of Xyratex confidential information please visit www.xyratex.com ------------------------------ -------------- next part -------------- An HTML attachment was scrubbed... URL: From keith.mannthey at intel.com Mon Aug 5 18:26:52 2013 From: keith.mannthey at intel.com (Keith Mannthey) Date: Mon, 05 Aug 2013 11:26:52 -0700 Subject: [cdwg] Monitoring Ticket Progress In-Reply-To: References: <91A3A1C9-6017-4CDF-BEA3-C74568416239@xyratex.com> <51FC323C.10502@llnl.gov> Message-ID: <1375727212.2173.413.camel@keith-G75VW> On Sat, 2013-08-03 at 09:43 +0300, Denis Kondratenko wrote: > In our Jira workflow we have different states like: Open, In Progress, > Review, Landing and etc. > It is engineer responsibility to maintain correct state. > After engineer see that it has two +1, he/she transfers ticket to > state Landing. > Gatekeeper has search for all tickets at this state and see what is > ready to land. Actually gatekeeper (or other people) could subscribe > to search and receive e-mail with it results. > > Having different states in Jira gives us more clear vision what is the > state of the project and where issues are. > Using Kanban GreenHopper RapidBoard you even could get many > statistical info about time that was spend in each state and other > charts/stat. > > Limiting work in progress in each state you could easily see where you > having issues in process. BTW our UpstreamLanding column is always > red, that's why we always trying to find a way to improve process of > upstream landing. Hello All, I spend time working to get patches (some of my own some of others) landed and these are some of my observations. I see patches as having 3 general phases of life with regards to landing on Master branch. 1. The patch is created and submitted. It also needs to have a LU and the patch should be linked into the LU. Patches that are not linked to their LU are quite easy to overlook. It would be really nice to have a automatic plugin that linked all new patches to the LUs they are attached to but not the old spam level of information. 2. The patch is reviewed and tested. I consider this the hardest part of a patches life and it many cases more work that just making the patch. It needs to build, pass autotest for ldiskfs and get reviewed. Comments and nacks are part of the review process and most patches will be several versions in before they are accepted, this is mostly an iterative process. 3. The patch is landed. With regards to Master patches this should really happen within a few weeks of #2 being completed. Landing code that tested well a few months ago is tricky, some isolated changes might be safe but many patches will just not cleanly apply and with some the code underneath has changed are a careful evaluation is needed. If git rebase fails for the patch it can't be landed by gatekeeper. Denis, In your UpstreamLanding column to you know which areas are the most troublesome for the patches you are tracking? Automating gatekeeper notifications will only help #3. Thanks, Keith Mannthey Lustre Support and Release > Kanban def: > http://www.infoq.com/resource/minibooks/kanban-scrum-minibook/en/pdf/KanbanAndScrumInfoQVersionFINAL.pdf > https://www.atlassian.com/software/greenhopper/overview/kanban > > Maybe having RapidBoard at Intel Jira with such info for sustaining > will give to all of us more visibility and stat. But that requires > Jira workflow changes and process changes. > > > On Aug 3, 2013 1:27 AM, "Christopher J. Morrone" > wrote: > Thanks Denis, those are some great leads! > > I think it would be excellent to investigate one or both of > those links to get gerrit enhanced to match our workflow. I > opened ticket LU-3690 as a task to track this. > > I like the sounds of the prolog-cookbook approach. But I see > what you mean, it is not clear to me that making a patch > "submitable" is sufficient to give us something that we can > use as search term. So that may make the perl "hook for a +2 > approval from a simple quorum of +1 votes" a better option. > > I am not sure that I understood your final comment about a > Jira "Landing" state. > > Chris > > On 08/02/2013 04:13 AM, Denis Kondratenko wrote: > Chris, > > I see your point now. We are not using gerrit with a > way it was designed > for (when +2 should be there to submit; seems our > gatekeepers doing +2). > You are right it is impossible to build search for > gatekeeper from plain > gerrit without it modification. > > There are still some ways to workaround that: > * http://en.wikibooks.org/wiki/Git/Gerrit_Code_Review > (A hook could - > for instance - allow a project to install an automated > gatekeeper to > vote +2 'submit approved' when sufficient +1 votes > 'looks good to me' > have been received) > * > http://review.whamcloud.com/Documentation/prolog-cookbook.html#_example_12_1_1_2_code_review (but > I don't know if it will get right searches..) > * in Xyratex we are using Jira state "Landing" to > build filter for > gatekeeper. > > OK, even if we could't separate gatekeeper changes > from other, filter is > still useful to check issues with no feedback for a > long time. > > Thanks, > Denis > > > ------------------------------------------------------------------------ > For additional information including the registered > office and the treatment of Xyratex confidential > information please visitwww.xyratex.com > > > ------------------------------------------------------------------------ > > > _______________________________________________ > cdwg mailing list > cdwg at lists.opensfs.org > http://lists.opensfs.org/listinfo.cgi/cdwg-opensfs.org > > > _______________________________________________ > cdwg mailing list > cdwg at lists.opensfs.org > http://lists.opensfs.org/listinfo.cgi/cdwg-opensfs.org > > > ______________________________________________________________________ > For additional information including the registered office and the treatment of Xyratex confidential information please visit www.xyratex.com > > ______________________________________________________________________ > _______________________________________________ > cdwg mailing list > cdwg at lists.opensfs.org > http://lists.opensfs.org/listinfo.cgi/cdwg-opensfs.org From denis_kondratenko at xyratex.com Mon Aug 5 20:05:09 2013 From: denis_kondratenko at xyratex.com (Denis Kondratenko) Date: Mon, 5 Aug 2013 23:05:09 +0300 Subject: [cdwg] Monitoring Ticket Progress In-Reply-To: <1375727212.2173.413.camel@keith-G75VW> References: <91A3A1C9-6017-4CDF-BEA3-C74568416239@xyratex.com> <51FC323C.10502@llnl.gov> <1375727212.2173.413.camel@keith-G75VW> Message-ID: Hi Keith, We are tracking ticket and not patches, actually our Jira states reflect patch lifetime. We have Gerrit for review too and engineer reflects patch review state to ticket state. Our Jira states are: In Progress, Review, Landing, Upstream Landing. So that states somehow cover all stages that you have described. We could see how many patches (ticket) and how long patch is under review, landing and landing upstream. We are limiting all stages to catch issues. Sometime ago we seen a red Review column and changed a process little bit to do review more effectively. Landing never had issues. But our Upstream column is always red. We actually have divided this column by swimlines(in term of Greenhopper): should be submitted to Upstream; was submitted to Upstream. They both have issues, but longest time is spent on 'was submitted'. We are not tracking same stages after submitting it Upstream, that is out of our scope. Thanks, Denis On Aug 5, 2013 9:27 PM, "Keith Mannthey" wrote: > On Sat, 2013-08-03 at 09:43 +0300, Denis Kondratenko wrote: > > In our Jira workflow we have different states like: Open, In Progress, > > Review, Landing and etc. > > It is engineer responsibility to maintain correct state. > > After engineer see that it has two +1, he/she transfers ticket to > > state Landing. > > Gatekeeper has search for all tickets at this state and see what is > > ready to land. Actually gatekeeper (or other people) could subscribe > > to search and receive e-mail with it results. > > > > Having different states in Jira gives us more clear vision what is the > > state of the project and where issues are. > > Using Kanban GreenHopper RapidBoard you even could get many > > statistical info about time that was spend in each state and other > > charts/stat. > > > > Limiting work in progress in each state you could easily see where you > > having issues in process. BTW our UpstreamLanding column is always > > red, that's why we always trying to find a way to improve process of > > upstream landing. > Hello All, > > I spend time working to get patches (some of my own some of others) > landed and these are some of my observations. I see patches as having 3 > general phases of life with regards to landing on Master branch. > > 1. The patch is created and submitted. It also needs to have a LU and > the patch should be linked into the LU. Patches that are not linked to > their LU are quite easy to overlook. It would be really nice to have a > automatic plugin that linked all new patches to the LUs they are > attached to but not the old spam level of information. > > 2. The patch is reviewed and tested. I consider this the hardest part > of a patches life and it many cases more work that just making the > patch. It needs to build, pass autotest for ldiskfs and get reviewed. > Comments and nacks are part of the review process and most patches will > be several versions in before they are accepted, this is mostly an > iterative process. > > 3. The patch is landed. With regards to Master patches this should > really happen within a few weeks of #2 being completed. Landing code > that tested well a few months ago is tricky, some isolated changes might > be safe but many patches will just not cleanly apply and with some the > code underneath has changed are a careful evaluation is needed. If git > rebase fails for the patch it can't be landed by gatekeeper. > > Denis, > In your UpstreamLanding column to you know which areas are the most > troublesome for the patches you are tracking? Automating gatekeeper > notifications will only help #3. > > > Thanks, > Keith Mannthey > Lustre Support and Release > > > Kanban def: > > > http://www.infoq.com/resource/minibooks/kanban-scrum-minibook/en/pdf/KanbanAndScrumInfoQVersionFINAL.pdf > > https://www.atlassian.com/software/greenhopper/overview/kanban > > > > Maybe having RapidBoard at Intel Jira with such info for sustaining > > will give to all of us more visibility and stat. But that requires > > Jira workflow changes and process changes. > > > > > > On Aug 3, 2013 1:27 AM, "Christopher J. Morrone" > > wrote: > > Thanks Denis, those are some great leads! > > > > I think it would be excellent to investigate one or both of > > those links to get gerrit enhanced to match our workflow. I > > opened ticket LU-3690 as a task to track this. > > > > I like the sounds of the prolog-cookbook approach. But I see > > what you mean, it is not clear to me that making a patch > > "submitable" is sufficient to give us something that we can > > use as search term. So that may make the perl "hook for a +2 > > approval from a simple quorum of +1 votes" a better option. > > > > I am not sure that I understood your final comment about a > > Jira "Landing" state. > > > > Chris > > > > On 08/02/2013 04:13 AM, Denis Kondratenko wrote: > > Chris, > > > > I see your point now. We are not using gerrit with a > > way it was designed > > for (when +2 should be there to submit; seems our > > gatekeepers doing +2). > > You are right it is impossible to build search for > > gatekeeper from plain > > gerrit without it modification. > > > > There are still some ways to workaround that: > > * http://en.wikibooks.org/wiki/Git/Gerrit_Code_Review > > (A hook could - > > for instance - allow a project to install an automated > > gatekeeper to > > vote +2 'submit approved' when sufficient +1 votes > > 'looks good to me' > > have been received) > > * > > > http://review.whamcloud.com/Documentation/prolog-cookbook.html#_example_12_1_1_2_code_review(but > > I don't know if it will get right searches..) > > * in Xyratex we are using Jira state "Landing" to > > build filter for > > gatekeeper. > > > > OK, even if we could't separate gatekeeper changes > > from other, filter is > > still useful to check issues with no feedback for a > > long time. > > > > Thanks, > > Denis > > > > > > > ------------------------------------------------------------------------ > > For additional information including the registered > > office and the treatment of Xyratex confidential > > information please visitwww.xyratex.com > > > > > > > ------------------------------------------------------------------------ > > > > > > _______________________________________________ > > cdwg mailing list > > cdwg at lists.opensfs.org > > http://lists.opensfs.org/listinfo.cgi/cdwg-opensfs.org > > > > > > _______________________________________________ > > cdwg mailing list > > cdwg at lists.opensfs.org > > http://lists.opensfs.org/listinfo.cgi/cdwg-opensfs.org > > > > > > ______________________________________________________________________ > > For additional information including the registered office and the > treatment of Xyratex confidential information please visit www.xyratex.com > > > > ______________________________________________________________________ > > _______________________________________________ > > cdwg mailing list > > cdwg at lists.opensfs.org > > http://lists.opensfs.org/listinfo.cgi/cdwg-opensfs.org > > > -- ------------------------------ For additional information including the registered office and the treatment of Xyratex confidential information please visit www.xyratex.com ------------------------------ -------------- next part -------------- An HTML attachment was scrubbed... URL: From andreas.dilger at intel.com Wed Aug 7 08:51:39 2013 From: andreas.dilger at intel.com (Dilger, Andreas) Date: Wed, 7 Aug 2013 08:51:39 +0000 Subject: [cdwg] Monitoring Ticket Progress In-Reply-To: Message-ID: On 2013/08/05 2:05 PM, "Denis Kondratenko" wrote: >Hi Keith, >We are tracking ticket and not patches, actually our Jira states reflect >patch lifetime. >We have Gerrit for review too and engineer reflects patch review state to >ticket state. Our Jira states are: In Progress, Review, Landing, Upstream >Landing. >So that states somehow cover all stages that you have described. We could >see how many patches (ticket) and how long patch is under review, landing >and landing upstream. >We are limiting all stages to catch issues. Sometime ago we seen a red >Review column and changed a process little bit to do review more >effectively. >Landing never had issues. >But our Upstream column is always red. >We actually have divided this column by swimlines(in term of >Greenhopper): should be submitted to Upstream; was submitted to Upstream. >They both have issues, but longest time is spent on 'was submitted'. >We are not tracking same stages after submitting it Upstream, that is out >of our scope. Maybe I am misunderstanding what you are writing here, but in case I am not I think it is a mistake stop tracking patches after they have been submitted upstream. The unfortunate truth is that there are many reasons why a patch might not be landed after it has been submitted. The purpose of patch inspection is to find bugs, either in the patch itself or with potential interactions with other patches. The testing system hits bugs, whether in this patch or in existing code, and this needs to be investigated (either to fix the bugs in the patch or in the existing code). People are busy and have many priorities, so friendly reminders that a patch needs another inspection, needs to be retested (due to a specific and properly attributed external failure) or is ready to land will help the patch to land. Cheers, Andreas >On Aug 5, 2013 9:27 PM, "Keith Mannthey" wrote: > >On Sat, 2013-08-03 at 09:43 +0300, Denis Kondratenko wrote: >> In our Jira workflow we have different states like: Open, In Progress, >> Review, Landing and etc. >> It is engineer responsibility to maintain correct state. >> After engineer see that it has two +1, he/she transfers ticket to >> state Landing. >> Gatekeeper has search for all tickets at this state and see what is >> ready to land. Actually gatekeeper (or other people) could subscribe >> to search and receive e-mail with it results. >> >> Having different states in Jira gives us more clear vision what is the >> state of the project and where issues are. >> Using Kanban GreenHopper RapidBoard you even could get many >> statistical info about time that was spend in each state and other >> charts/stat. >> >> Limiting work in progress in each state you could easily see where you >> having issues in process. BTW our UpstreamLanding column is always >> red, that's why we always trying to find a way to improve process of >> upstream landing. >Hello All, > >I spend time working to get patches (some of my own some of others) >landed and these are some of my observations. I see patches as having 3 >general phases of life with regards to landing on Master branch. > >1. The patch is created and submitted. It also needs to have a LU and >the patch should be linked into the LU. Patches that are not linked to >their LU are quite easy to overlook. It would be really nice to have a >automatic plugin that linked all new patches to the LUs they are >attached to but not the old spam level of information. > >2. The patch is reviewed and tested. I consider this the hardest part >of a patches life and it many cases more work that just making the >patch. It needs to build, pass autotest for ldiskfs and get reviewed. >Comments and nacks are part of the review process and most patches will >be several versions in before they are accepted, this is mostly an >iterative process. > >3. The patch is landed. With regards to Master patches this should >really happen within a few weeks of #2 being completed. Landing code >that tested well a few months ago is tricky, some isolated changes might >be safe but many patches will just not cleanly apply and with some the >code underneath has changed are a careful evaluation is needed. If git >rebase fails for the patch it can't be landed by gatekeeper. > >Denis, > In your UpstreamLanding column to you know which areas are the most >troublesome for the patches you are tracking? Automating gatekeeper >notifications will only help #3. > > >Thanks, > Keith Mannthey > Lustre Support and Release > >> Kanban def: >> >http://www.infoq.com/resource/minibooks/kanban-scrum-minibook/en/pdf/Kanba >nAndScrumInfoQVersionFINAL.pdf >anAndScrumInfoQVersionFINAL.pdf> >> >https://www.atlassian.com/software/greenhopper/overview/kanban > >> >> Maybe having RapidBoard at Intel Jira with such info for sustaining >> will give to all of us more visibility and stat. But that requires >> Jira workflow changes and process changes. >> >> >> On Aug 3, 2013 1:27 AM, "Christopher J. Morrone" >> wrote: >> Thanks Denis, those are some great leads! >> >> I think it would be excellent to investigate one or both of >> those links to get gerrit enhanced to match our workflow. I >> opened ticket LU-3690 as a task to track this. >> >> I like the sounds of the prolog-cookbook approach. But I see >> what you mean, it is not clear to me that making a patch >> "submitable" is sufficient to give us something that we can >> use as search term. So that may make the perl "hook for a +2 >> approval from a simple quorum of +1 votes" a better option. >> >> I am not sure that I understood your final comment about a >> Jira "Landing" state. >> >> Chris >> >> On 08/02/2013 04:13 AM, Denis Kondratenko wrote: >> Chris, >> >> I see your point now. We are not using gerrit with a >> way it was designed >> for (when +2 should be there to submit; seems our >> gatekeepers doing +2). >> You are right it is impossible to build search for >> gatekeeper from plain >> gerrit without it modification. >> >> There are still some ways to workaround that: >> * >http://en.wikibooks.org/wiki/Git/Gerrit_Code_Review > >> (A hook could - >> for instance - allow a project to install an automated >> gatekeeper to >> vote +2 'submit approved' when sufficient +1 votes >> 'looks good to me' >> have been received) >> * >> >http://review.whamcloud.com/Documentation/prolog-cookbook.html#_example_12 >_1_1_2_code_review >2_1_1_2_code_review> (but >> I don't know if it will get right searches..) >> * in Xyratex we are using Jira state "Landing" to >> build filter for >> gatekeeper. >> >> OK, even if we could't separate gatekeeper changes >> from other, filter is >> still useful to check issues with no feedback for a >> long time. >> >> Thanks, >> Denis Cheers, Andreas -- Andreas Dilger Lustre Software Architect Intel High Performance Data Division From denis_kondratenko at xyratex.com Wed Aug 7 12:15:56 2013 From: denis_kondratenko at xyratex.com (Denis Kondratenko) Date: Wed, 7 Aug 2013 15:15:56 +0300 Subject: [cdwg] Monitoring Ticket Progress In-Reply-To: References: Message-ID: We aren't stop tracking, ticket will be in the Upstream state until it will not be submitted to master. There is no sense for us to track same stages for upstream patch (and actually we couldn't influence to process here), because our own just passed testing and review and was committed to our sources . There is still case that patch will be changed during Upstream phase, in this case we are transferring ticket back to Landing and picking up community commit instead of our to have unified source base. All that you are saying about patch lifetime is true, and I am not argue with that. I am just proposing to control this process somehow (now 2 ideas, we could pick one of that): 1. implement Jira process that will reflect patch state and will allow us to have clear visibility on GreenHopper with possibility to measure time and number of tickets for different stages: Testing, Review, Landing. 2. have a Gerrit searches to discuss ticket that are long time under review or ready to submit and discuss them (or part of list) on CDWG to understand why it happens and how we could improve. First is almost the same like second but will give us more visibility and stat for CDWG discussion about Sustaining activities, and will automatically produce board and stat, when second will be done by hand by collecting lists and cut them. Why we need to control that? Because current method doesn't work, engineers don't understand why patches aren't submitted when they were reviewed and tested. It is not a rare occurrence - patches that were submitted 6-12 months after it was first pushed for review. There obviously were some issues with patch and there were 2-5 cycles of review. But because review takes long (or for some other reason, like rebasing and etc) it could take 5 cycles* 2 months = 10 months to close the gap in the code. Proposition is to get that under control and check areas for improvement. Gather some stat and understood how it could be improved or what is done wrong on both sides. Thanks, Denis On 7 авг. 2013, at 11:51, "Dilger, Andreas" wrote: > On 2013/08/05 2:05 PM, "Denis Kondratenko" > wrote: > >> Hi Keith, >> We are tracking ticket and not patches, actually our Jira states reflect >> patch lifetime. >> We have Gerrit for review too and engineer reflects patch review state to >> ticket state. Our Jira states are: In Progress, Review, Landing, Upstream >> Landing. >> So that states somehow cover all stages that you have described. We could >> see how many patches (ticket) and how long patch is under review, landing >> and landing upstream. >> We are limiting all stages to catch issues. Sometime ago we seen a red >> Review column and changed a process little bit to do review more >> effectively. >> Landing never had issues. >> But our Upstream column is always red. >> We actually have divided this column by swimlines(in term of >> Greenhopper): should be submitted to Upstream; was submitted to Upstream. >> They both have issues, but longest time is spent on 'was submitted'. >> We are not tracking same stages after submitting it Upstream, that is out >> of our scope. > > Maybe I am misunderstanding what you are writing here, but in case I am not > I think it is a mistake stop tracking patches after they have been > submitted > upstream. The unfortunate truth is that there are many reasons why a patch > might not be landed after it has been submitted. > > The purpose of patch inspection is to find bugs, either in the patch > itself or > with potential interactions with other patches. The testing system hits > bugs, > whether in this patch or in existing code, and this needs to be > investigated > (either to fix the bugs in the patch or in the existing code). People are > busy > and have many priorities, so friendly reminders that a patch needs another > inspection, needs to be retested (due to a specific and properly attributed > external failure) or is ready to land will help the patch to land. > > Cheers, Andreas > >> On Aug 5, 2013 9:27 PM, "Keith Mannthey" wrote: >> >> On Sat, 2013-08-03 at 09:43 +0300, Denis Kondratenko wrote: >>> In our Jira workflow we have different states like: Open, In Progress, >>> Review, Landing and etc. >>> It is engineer responsibility to maintain correct state. >>> After engineer see that it has two +1, he/she transfers ticket to >>> state Landing. >>> Gatekeeper has search for all tickets at this state and see what is >>> ready to land. Actually gatekeeper (or other people) could subscribe >>> to search and receive e-mail with it results. >>> >>> Having different states in Jira gives us more clear vision what is the >>> state of the project and where issues are. >>> Using Kanban GreenHopper RapidBoard you even could get many >>> statistical info about time that was spend in each state and other >>> charts/stat. >>> >>> Limiting work in progress in each state you could easily see where you >>> having issues in process. BTW our UpstreamLanding column is always >>> red, that's why we always trying to find a way to improve process of >>> upstream landing. >> Hello All, >> >> I spend time working to get patches (some of my own some of others) >> landed and these are some of my observations. I see patches as having 3 >> general phases of life with regards to landing on Master branch. >> >> 1. The patch is created and submitted. It also needs to have a LU and >> the patch should be linked into the LU. Patches that are not linked to >> their LU are quite easy to overlook. It would be really nice to have a >> automatic plugin that linked all new patches to the LUs they are >> attached to but not the old spam level of information. >> >> 2. The patch is reviewed and tested. I consider this the hardest part >> of a patches life and it many cases more work that just making the >> patch. It needs to build, pass autotest for ldiskfs and get reviewed. >> Comments and nacks are part of the review process and most patches will >> be several versions in before they are accepted, this is mostly an >> iterative process. >> >> 3. The patch is landed. With regards to Master patches this should >> really happen within a few weeks of #2 being completed. Landing code >> that tested well a few months ago is tricky, some isolated changes might >> be safe but many patches will just not cleanly apply and with some the >> code underneath has changed are a careful evaluation is needed. If git >> rebase fails for the patch it can't be landed by gatekeeper. >> >> Denis, >> In your UpstreamLanding column to you know which areas are the most >> troublesome for the patches you are tracking? Automating gatekeeper >> notifications will only help #3. >> >> >> Thanks, >> Keith Mannthey >> Lustre Support and Release >> >>> Kanban def: >>> >> http://www.infoq.com/resource/minibooks/kanban-scrum-minibook/en/pdf/Kanba >> nAndScrumInfoQVersionFINAL.pdf >> > anAndScrumInfoQVersionFINAL.pdf> >>> >> https://www.atlassian.com/software/greenhopper/overview/kanban >> >>> >>> Maybe having RapidBoard at Intel Jira with such info for sustaining >>> will give to all of us more visibility and stat. But that requires >>> Jira workflow changes and process changes. >>> >>> >>> On Aug 3, 2013 1:27 AM, "Christopher J. Morrone" >>> wrote: >>> Thanks Denis, those are some great leads! >>> >>> I think it would be excellent to investigate one or both of >>> those links to get gerrit enhanced to match our workflow. I >>> opened ticket LU-3690 as a task to track this. >>> >>> I like the sounds of the prolog-cookbook approach. But I see >>> what you mean, it is not clear to me that making a patch >>> "submitable" is sufficient to give us something that we can >>> use as search term. So that may make the perl "hook for a +2 >>> approval from a simple quorum of +1 votes" a better option. >>> >>> I am not sure that I understood your final comment about a >>> Jira "Landing" state. >>> >>> Chris >>> >>> On 08/02/2013 04:13 AM, Denis Kondratenko wrote: >>> Chris, >>> >>> I see your point now. We are not using gerrit with a >>> way it was designed >>> for (when +2 should be there to submit; seems our >>> gatekeepers doing +2). >>> You are right it is impossible to build search for >>> gatekeeper from plain >>> gerrit without it modification. >>> >>> There are still some ways to workaround that: >>> * >> http://en.wikibooks.org/wiki/Git/Gerrit_Code_Review >> >>> (A hook could - >>> for instance - allow a project to install an automated >>> gatekeeper to >>> vote +2 'submit approved' when sufficient +1 votes >>> 'looks good to me' >>> have been received) >>> * >>> >> http://review.whamcloud.com/Documentation/prolog-cookbook.html#_example_12 >> _1_1_2_code_review >> > 2_1_1_2_code_review> (but >>> I don't know if it will get right searches..) >>> * in Xyratex we are using Jira state "Landing" to >>> build filter for >>> gatekeeper. >>> >>> OK, even if we could't separate gatekeeper changes >>> from other, filter is >>> still useful to check issues with no feedback for a >>> long time. >>> >>> Thanks, >>> Denis > > > Cheers, Andreas > -- > Andreas Dilger > > Lustre Software Architect > Intel High Performance Data Division > > -- ------------------------------ For additional information including the registered office and the treatment of Xyratex confidential information please visit www.xyratex.com ------------------------------ From peter.a.jones at intel.com Wed Aug 7 15:03:24 2013 From: peter.a.jones at intel.com (Jones, Peter A) Date: Wed, 7 Aug 2013 15:03:24 +0000 Subject: [cdwg] Monitoring Ticket Progress In-Reply-To: Message-ID: > >It is not a rare occurrence - patches that were submitted 6-12 months >after it was first pushed for review. Denis, please give me three examples where patches pushed to master have waited 6-12 months after being pushed for review? I take this very seriously. There are certainly busy times when lower priority patches might need to wait but I have not seen anything that long. Feature patches submitted during the feature freeze, but that is usually more like 3-4 months in the worst case scenario. Sometimes people push patches against maintenance branches, which can be useful for the community but if these land it will only be at the time we create a maintenance release against that branch. From denis_kondratenko at xyratex.com Wed Aug 7 15:11:36 2013 From: denis_kondratenko at xyratex.com (Denis Kondratenko) Date: Wed, 7 Aug 2013 18:11:36 +0300 Subject: [cdwg] Monitoring Ticket Progress In-Reply-To: References: Message-ID: OK, I will go and try to search. Maybe I have overestimated that, my apologize for that - will provide you numbers and examples. Point wasn't in that. Point was - we have no numbers - so nothing to analyze and improve. Thanks, Denis On 7 авг. 2013, at 18:03, "Jones, Peter A" wrote: > > >> >> It is not a rare occurrence - patches that were submitted 6-12 months >> after it was first pushed for review. > > Denis, please give me three examples where patches pushed to master have > waited 6-12 months after being pushed for review? > > I take this very seriously. > > There are certainly busy times when lower priority patches might need to > wait but I have not seen anything that long. > > Feature patches submitted during the feature freeze, but that is usually > more like 3-4 months in the worst case scenario. > > Sometimes people push patches against maintenance branches, which can be > useful for the community but if these land it will only be at the time we > create a maintenance release against that branch. > > -- ------------------------------ For additional information including the registered office and the treatment of Xyratex confidential information please visit www.xyratex.com ------------------------------ From peter.a.jones at intel.com Wed Aug 7 16:07:33 2013 From: peter.a.jones at intel.com (Jones, Peter A) Date: Wed, 7 Aug 2013 16:07:33 +0000 Subject: [cdwg] Monitoring Ticket Progress In-Reply-To: Message-ID: Thanks Denis I would appreciate it. I absolutely agree that this needs to be an iterative process and that we need data to analyze and improve. The last time this concern was raised (just before ISC) I did complete an analysis of every single Xyratex patch submitted against master and (other than a couple of feature patches that had been delayed by the 2.4 feature freeze) the longest wait that I saw at that time was only a few weeks. Xyratex committed at that time to provide a consolidated list of issues that are a concern. I suggest that we focus on that as a first step before getting into possible process changes so that we can be sure that our process reflects the actual situation. On 8/7/13 8:11 AM, "Denis Kondratenko" wrote: >OK, I will go and try to search. > >Maybe I have overestimated that, my apologize for that - will provide you >numbers and examples. >Point wasn't in that. > >Point was - we have no numbers - so nothing to analyze and improve. > >Thanks, >Denis > >On 7 авг. 2013, at 18:03, "Jones, Peter A" >wrote: > >> >> >>> >>> It is not a rare occurrence - patches that were submitted 6-12 months >>> after it was first pushed for review. >> >> Denis, please give me three examples where patches pushed to master have >> waited 6-12 months after being pushed for review? >> >> I take this very seriously. >> >> There are certainly busy times when lower priority patches might need to >> wait but I have not seen anything that long. >> >> Feature patches submitted during the feature freeze, but that is usually >> more like 3-4 months in the worst case scenario. >> >> Sometimes people push patches against maintenance branches, which can be >> useful for the community but if these land it will only be at the time >>we >> create a maintenance release against that branch. >> >> > > >-- > > >------------------------------ >For additional information including the registered office and the >treatment of Xyratex confidential information please visit www.xyratex.com > >------------------------------ >_______________________________________________ >cdwg mailing list >cdwg at lists.opensfs.org >http://lists.opensfs.org/listinfo.cgi/cdwg-opensfs.org From denis_kondratenko at xyratex.com Thu Aug 8 11:10:03 2013 From: denis_kondratenko at xyratex.com (Denis Kondratenko) Date: Thu, 8 Aug 2013 14:10:03 +0300 Subject: [cdwg] Monitoring Ticket Progress In-Reply-To: References: Message-ID: <30DB9AF1-0C4F-4A9B-A37F-86AF12A8FABE@xyratex.com> Hi Peter, I wasn't been searching for gerrit (search isn't brilliant and I can't build search that will show me tickets that were under review for long time, I need to go to each ticket and check), just looked to my stared changes, issues that I had some internal relation. Couple of examples: http://review.whamcloud.com/#/c/3553/ http://review.whamcloud.com/#/c/3277/ http://review.whamcloud.com/#/c/5213/ http://review.whamcloud.com/#/c/4372/ http://review.whamcloud.com/#/c/4641/ http://review.whamcloud.com/#/c/4664/ http://review.whamcloud.com/#/c/3725/ http://review.whamcloud.com/#/c/2406/ Again, I don't want to start any war or discussion about those tickets, or about some other. I don't want to blame anyone about something. But for me obviously some problems exit. Those tickets are probably all have good explanation why. My suggestion was to build process, that will resolve such issues automatically and will provide us stat and info about Sustaining review activities. What I don't want is to do it manually. What we propose is to define all stages of Sustaining process to gather all needed info to understand where we have most problems: * review resources * incorrect test failures * rebases * code freeze * some other… Process for all, not just Xyratex, but for all reviews. That will give us more visibility and possibility to improve. We are not saint and we need to improve too. We have issues with upstream submission too and there are no fault here in this discussion. Right now we know that only based on our experience in our heads, intuitively. Of course we could use any suggestions. If we all think that just e-mail with list will resolve this situation - we will use that. I just started this topic to share our process that could be useful, and gather other feedbacks - what could be done. Thanks, Denis On 7 авг. 2013, at 19:07, "Jones, Peter A" wrote: > Thanks Denis I would appreciate it. I absolutely agree that this needs to > be an iterative process and that we need data to analyze and improve. > > The last time this concern was raised (just before ISC) I did complete an > analysis of every single Xyratex patch submitted against master and (other > than a couple of feature patches that had been delayed by the 2.4 feature > freeze) the longest wait that I saw at that time was only a few weeks. > > Xyratex committed at that time to provide a consolidated list of issues > that are a concern. I suggest that we focus on that as a first step before > getting into possible process changes so that we can be sure that our > process reflects the actual situation. > > > On 8/7/13 8:11 AM, "Denis Kondratenko" > wrote: > >> OK, I will go and try to search. >> >> Maybe I have overestimated that, my apologize for that - will provide you >> numbers and examples. >> Point wasn't in that. >> >> Point was - we have no numbers - so nothing to analyze and improve. >> >> Thanks, >> Denis >> >> On 7 авг. 2013, at 18:03, "Jones, Peter A" >> wrote: >> >>> >>> >>>> >>>> It is not a rare occurrence - patches that were submitted 6-12 months >>>> after it was first pushed for review. >>> >>> Denis, please give me three examples where patches pushed to master have >>> waited 6-12 months after being pushed for review? >>> >>> I take this very seriously. >>> >>> There are certainly busy times when lower priority patches might need to >>> wait but I have not seen anything that long. >>> >>> Feature patches submitted during the feature freeze, but that is usually >>> more like 3-4 months in the worst case scenario. >>> >>> Sometimes people push patches against maintenance branches, which can be >>> useful for the community but if these land it will only be at the time >>> we >>> create a maintenance release against that branch. >>> >>> >> >> >> -- >> >> >> ------------------------------ >> For additional information including the registered office and the >> treatment of Xyratex confidential information please visit www.xyratex.com >> >> ------------------------------ >> _______________________________________________ >> cdwg mailing list >> cdwg at lists.opensfs.org >> http://lists.opensfs.org/listinfo.cgi/cdwg-opensfs.org > -- ------------------------------ For additional information including the registered office and the treatment of Xyratex confidential information please visit www.xyratex.com ------------------------------ -------------- next part -------------- An HTML attachment was scrubbed... URL: From peter.a.jones at intel.com Thu Aug 8 15:08:09 2013 From: peter.a.jones at intel.com (Jones, Peter A) Date: Thu, 8 Aug 2013 15:08:09 +0000 Subject: [cdwg] Monitoring Ticket Progress In-Reply-To: <30DB9AF1-0C4F-4A9B-A37F-86AF12A8FABE@xyratex.com> Message-ID: Thank you for providing a list. Seeing your examples really helps me to understand the source of the disconnect. This list contains several examples of patches pushed against maintenance branches. I think that this is one of the major sources of the communication breakdown. The focus for upstreaming is master. We create maintenance releases for our customers and rather than do continuous landings as we do for master. We only land to maintenance branches shortly before we plan to issue a release on such a branch, and landings are limited to fixes that are needed by our customers. This same misunderstanding has come up a number of times with Xyratex which is why I specifically called it out below. I also do not want this to be an adversarial discussion, but my feeling is that if you reset your expectations regarding patches pushed against maintenance branches, are clear about significant release dates (feature freeze etc) and you take a fresh look at the data, then you should have a different take on the situation. I am not claiming that we are saints either – it is true that the flock patch (now landed, thankfully) did take a long time to land, for example, but - rather than your initial statement that delays of 3-6 months being commonplace -what I see is that there can be delays of a couple of months for reviews at busy times (and conversely, multiple month periods for submitters to respond to review feedback), and there is the occasional "difficult" patch that we are more cautious about landing. What is puzzling to me is, given the evident strength of feeling you have had about this situation, why were none of the below examples ever raised during CDWG meetings? If that had happened then we should have been able to have corrected misunderstandings long ago and perhaps been able to more quickly come to an acceptable approach for more "problematic" issues like the flock patch. I appreciate that the meetings are not at a convenient time for you personally, but Chris keeps good meeting minutes at http://wiki.opensfs.org/Community_Development_Working_Group and I encourage you to ensure that the Xyratex representative in these meetings is representing anything that you want to raise. On 8/8/13 4:10 AM, "Denis Kondratenko" > wrote: Hi Peter, I wasn't been searching for gerrit (search isn't brilliant and I can't build search that will show me tickets that were under review for long time, I need to go to each ticket and check), just looked to my stared changes, issues that I had some internal relation. Couple of examples: http://review.whamcloud.com/#/c/3553/ http://review.whamcloud.com/#/c/3277/ http://review.whamcloud.com/#/c/5213/ http://review.whamcloud.com/#/c/4372/ http://review.whamcloud.com/#/c/4641/ http://review.whamcloud.com/#/c/4664/ http://review.whamcloud.com/#/c/3725/ http://review.whamcloud.com/#/c/2406/ Again, I don't want to start any war or discussion about those tickets, or about some other. I don't want to blame anyone about something. But for me obviously some problems exit. Those tickets are probably all have good explanation why. My suggestion was to build process, that will resolve such issues automatically and will provide us stat and info about Sustaining review activities. What I don't want is to do it manually. What we propose is to define all stages of Sustaining process to gather all needed info to understand where we have most problems: * review resources * incorrect test failures * rebases * code freeze * some other… Process for all, not just Xyratex, but for all reviews. That will give us more visibility and possibility to improve. We are not saint and we need to improve too. We have issues with upstream submission too and there are no fault here in this discussion. Right now we know that only based on our experience in our heads, intuitively. Of course we could use any suggestions. If we all think that just e-mail with list will resolve this situation - we will use that. I just started this topic to share our process that could be useful, and gather other feedbacks - what could be done. Thanks, Denis On 7 авг. 2013, at 19:07, "Jones, Peter A" > wrote: Thanks Denis I would appreciate it. I absolutely agree that this needs to be an iterative process and that we need data to analyze and improve. The last time this concern was raised (just before ISC) I did complete an analysis of every single Xyratex patch submitted against master and (other than a couple of feature patches that had been delayed by the 2.4 feature freeze) the longest wait that I saw at that time was only a few weeks. Xyratex committed at that time to provide a consolidated list of issues that are a concern. I suggest that we focus on that as a first step before getting into possible process changes so that we can be sure that our process reflects the actual situation. On 8/7/13 8:11 AM, "Denis Kondratenko" > wrote: OK, I will go and try to search. Maybe I have overestimated that, my apologize for that - will provide you numbers and examples. Point wasn't in that. Point was - we have no numbers - so nothing to analyze and improve. Thanks, Denis On 7 авг. 2013, at 18:03, "Jones, Peter A" > wrote: It is not a rare occurrence - patches that were submitted 6-12 months after it was first pushed for review. Denis, please give me three examples where patches pushed to master have waited 6-12 months after being pushed for review? I take this very seriously. There are certainly busy times when lower priority patches might need to wait but I have not seen anything that long. Feature patches submitted during the feature freeze, but that is usually more like 3-4 months in the worst case scenario. Sometimes people push patches against maintenance branches, which can be useful for the community but if these land it will only be at the time we create a maintenance release against that branch. -- ------------------------------ For additional information including the registered office and the treatment of Xyratex confidential information please visit www.xyratex.com ------------------------------ _______________________________________________ cdwg mailing list cdwg at lists.opensfs.org http://lists.opensfs.org/listinfo.cgi/cdwg-opensfs.org ________________________________ For additional information including the registered office and the treatment of Xyratex confidential information please visit www.xyratex.com ________________________________ From denis_kondratenko at xyratex.com Thu Aug 8 16:06:52 2013 From: denis_kondratenko at xyratex.com (Denis Kondratenko) Date: Thu, 8 Aug 2013 19:06:52 +0300 Subject: [cdwg] Monitoring Ticket Progress In-Reply-To: References: Message-ID: That how this hole thread was started - we do want to do this under CDWG and just searching right way to do it. E-mailing list was very simple suggestion. Then we started to think about that generally - gerrit searches and not only Xyratex ticket. Then I come with my suggestions about process and etc. Seems that we will start with simple list before CDWG and discussed, maybe later we will come with more general way. But not bad to know all possible ways. Thanks, Denis On 8 авг. 2013, at 18:08, "Jones, Peter A" wrote: > Thank you for providing a list. Seeing your examples really helps me to understand the source of the disconnect. > > This list contains several examples of patches pushed against maintenance branches. I think that this is one of the major sources of the communication breakdown. > > The focus for upstreaming is master. We create maintenance releases for our customers and rather than do continuous landings as we do for master. We only land to maintenance branches shortly before we plan to issue a release on such a branch, and landings are limited to fixes that are needed by our customers. > > This same misunderstanding has come up a number of times with Xyratex which is why I specifically called it out below. > > I also do not want this to be an adversarial discussion, but my feeling is that if you reset your expectations regarding patches pushed against maintenance branches, are clear about significant release dates (feature freeze etc) and you take a fresh look at the data, then you should have a different take on the situation. > > I am not claiming that we are saints either – it is true that the flock patch (now landed, thankfully) did take a long time to land, for example, but - rather than your initial statement that delays of 3-6 months being commonplace -what I see is that there can be delays of a couple of months for reviews at busy times (and conversely, multiple month periods for submitters to respond to review feedback), and there is the occasional "difficult" patch that we are more cautious about landing. > > What is puzzling to me is, given the evident strength of feeling you have had about this situation, why were none of the below examples ever raised during CDWG meetings? If that had happened then we should have been able to have corrected misunderstandings long ago and perhaps been able to more quickly come to an acceptable approach for more "problematic" issues like the flock patch. > > I appreciate that the meetings are not at a convenient time for you personally, but Chris keeps good meeting minutes at http://wiki.opensfs.org/Community_Development_Working_Group and I encourage you to ensure that the Xyratex representative in these meetings is representing anything that you want to raise. > > > > > On 8/8/13 4:10 AM, "Denis Kondratenko" > wrote: > > Hi Peter, > > I wasn't been searching for gerrit (search isn't brilliant and I can't build search that will show me tickets that were under review for long time, I need to go to each ticket and check), just looked to my stared changes, issues that I had some internal relation. > Couple of examples: > > http://review.whamcloud.com/#/c/3553/ > http://review.whamcloud.com/#/c/3277/ > http://review.whamcloud.com/#/c/5213/ > http://review.whamcloud.com/#/c/4372/ > http://review.whamcloud.com/#/c/4641/ > http://review.whamcloud.com/#/c/4664/ > http://review.whamcloud.com/#/c/3725/ > http://review.whamcloud.com/#/c/2406/ > > Again, I don't want to start any war or discussion about those tickets, or about some other. > I don't want to blame anyone about something. But for me obviously some problems exit. > > Those tickets are probably all have good explanation why. > My suggestion was to build process, that will resolve such issues automatically and will provide us stat and info about Sustaining review activities. > What I don't want is to do it manually. > > What we propose is to define all stages of Sustaining process to gather all needed info to understand where we have most problems: > * review resources > * incorrect test failures > * rebases > * code freeze > * some other… > > Process for all, not just Xyratex, but for all reviews. > > That will give us more visibility and possibility to improve. > We are not saint and we need to improve too. We have issues with upstream submission too and there are no fault here in this discussion. > > Right now we know that only based on our experience in our heads, intuitively. > > Of course we could use any suggestions. If we all think that just e-mail with list will resolve this situation - we will use that. > > I just started this topic to share our process that could be useful, and gather other feedbacks - what could be done. > > Thanks, > Denis > > On 7 авг. 2013, at 19:07, "Jones, Peter A" > wrote: > > Thanks Denis I would appreciate it. I absolutely agree that this needs to > be an iterative process and that we need data to analyze and improve. > > The last time this concern was raised (just before ISC) I did complete an > analysis of every single Xyratex patch submitted against master and (other > than a couple of feature patches that had been delayed by the 2.4 feature > freeze) the longest wait that I saw at that time was only a few weeks. > > Xyratex committed at that time to provide a consolidated list of issues > that are a concern. I suggest that we focus on that as a first step before > getting into possible process changes so that we can be sure that our > process reflects the actual situation. > > > On 8/7/13 8:11 AM, "Denis Kondratenko" > > wrote: > > OK, I will go and try to search. > > Maybe I have overestimated that, my apologize for that - will provide you > numbers and examples. > Point wasn't in that. > > Point was - we have no numbers - so nothing to analyze and improve. > > Thanks, > Denis > > On 7 авг. 2013, at 18:03, "Jones, Peter A" > > wrote: > > > > > It is not a rare occurrence - patches that were submitted 6-12 months > after it was first pushed for review. > > Denis, please give me three examples where patches pushed to master have > waited 6-12 months after being pushed for review? > > I take this very seriously. > > There are certainly busy times when lower priority patches might need to > wait but I have not seen anything that long. > > Feature patches submitted during the feature freeze, but that is usually > more like 3-4 months in the worst case scenario. > > Sometimes people push patches against maintenance branches, which can be > useful for the community but if these land it will only be at the time > we > create a maintenance release against that branch. > > > > > -- > > > ------------------------------ > For additional information including the registered office and the > treatment of Xyratex confidential information please visit www.xyratex.com > > ------------------------------ > _______________________________________________ > cdwg mailing list > cdwg at lists.opensfs.org > http://lists.opensfs.org/listinfo.cgi/cdwg-opensfs.org > > > > > ________________________________ > For additional information including the registered office and the treatment of Xyratex confidential information please visit www.xyratex.com > > ________________________________ -- ------------------------------ For additional information including the registered office and the treatment of Xyratex confidential information please visit www.xyratex.com ------------------------------ From peter.a.jones at intel.com Thu Aug 8 18:19:48 2013 From: peter.a.jones at intel.com (Jones, Peter A) Date: Thu, 8 Aug 2013 18:19:48 +0000 Subject: [cdwg] Monitoring Ticket Progress In-Reply-To: Message-ID: Denis Yes, absolutely, this thread has spawned from the CDWG meeting two weeks ago. I hope that this discussion is proving useful in working through some misunderstandings, evaluating priorities and giving those not able to make the call a chance to participate in the discussion. Regards Peter PS/ Perhaps I will see you at LAD again this year? On 8/8/13 9:06 AM, "Denis Kondratenko" wrote: >That how this hole thread was started - we do want to do this under CDWG >and just searching right way to do it. > >E-mailing list was very simple suggestion. > >Then we started to think about that generally - gerrit searches and not >only Xyratex ticket. >Then I come with my suggestions about process and etc. > >Seems that we will start with simple list before CDWG and discussed, >maybe later we will come with more general way. But not bad to know all >possible ways. > >Thanks, >Denis > >On 8 авг. 2013, at 18:08, "Jones, Peter A" >wrote: > >> Thank you for providing a list. Seeing your examples really helps me to >>understand the source of the disconnect. >> >> This list contains several examples of patches pushed against >>maintenance branches. I think that this is one of the major sources of >>the communication breakdown. >> >> The focus for upstreaming is master. We create maintenance releases for >>our customers and rather than do continuous landings as we do for >>master. We only land to maintenance branches shortly before we plan to >>issue a release on such a branch, and landings are limited to fixes that >>are needed by our customers. >> >> This same misunderstanding has come up a number of times with Xyratex >>which is why I specifically called it out below. >> >> I also do not want this to be an adversarial discussion, but my feeling >>is that if you reset your expectations regarding patches pushed against >>maintenance branches, are clear about significant release dates (feature >>freeze etc) and you take a fresh look at the data, then you should have >>a different take on the situation. >> >> I am not claiming that we are saints either – it is true that the flock >>patch (now landed, thankfully) did take a long time to land, for >>example, but - rather than your initial statement that delays of 3-6 >>months being commonplace -what I see is that there can be delays of a >>couple of months for reviews at busy times (and conversely, multiple >>month periods for submitters to respond to review feedback), and there >>is the occasional "difficult" patch that we are more cautious about >>landing. >> >> What is puzzling to me is, given the evident strength of feeling you >>have had about this situation, why were none of the below examples ever >>raised during CDWG meetings? If that had happened then we should have >>been able to have corrected misunderstandings long ago and perhaps been >>able to more quickly come to an acceptable approach for more >>"problematic" issues like the flock patch. >> >> I appreciate that the meetings are not at a convenient time for you >>personally, but Chris keeps good meeting minutes at >>http://wiki.opensfs.org/Community_Development_Working_Group and I >>encourage you to ensure that the Xyratex representative in these >>meetings is representing anything that you want to raise. >> >> >> >> >> On 8/8/13 4:10 AM, "Denis Kondratenko" >>> >>wrote: >> >> Hi Peter, >> >> I wasn't been searching for gerrit (search isn't brilliant and I can't >>build search that will show me tickets that were under review for long >>time, I need to go to each ticket and check), just looked to my stared >>changes, issues that I had some internal relation. >> Couple of examples: >> >> http://review.whamcloud.com/#/c/3553/ >> http://review.whamcloud.com/#/c/3277/ >> http://review.whamcloud.com/#/c/5213/ >> http://review.whamcloud.com/#/c/4372/ >> http://review.whamcloud.com/#/c/4641/ >> http://review.whamcloud.com/#/c/4664/ >> http://review.whamcloud.com/#/c/3725/ >> http://review.whamcloud.com/#/c/2406/ >> >> Again, I don't want to start any war or discussion about those tickets, >>or about some other. >> I don't want to blame anyone about something. But for me obviously some >>problems exit. >> >> Those tickets are probably all have good explanation why. >> My suggestion was to build process, that will resolve such issues >>automatically and will provide us stat and info about Sustaining review >>activities. >> What I don't want is to do it manually. >> >> What we propose is to define all stages of Sustaining process to gather >>all needed info to understand where we have most problems: >> * review resources >> * incorrect test failures >> * rebases >> * code freeze >> * some other… >> >> Process for all, not just Xyratex, but for all reviews. >> >> That will give us more visibility and possibility to improve. >> We are not saint and we need to improve too. We have issues with >>upstream submission too and there are no fault here in this discussion. >> >> Right now we know that only based on our experience in our heads, >>intuitively. >> >> Of course we could use any suggestions. If we all think that just >>e-mail with list will resolve this situation - we will use that. >> >> I just started this topic to share our process that could be useful, >>and gather other feedbacks - what could be done. >> >> Thanks, >> Denis >> >> On 7 авг. 2013, at 19:07, "Jones, Peter A" >>> wrote: >> >> Thanks Denis I would appreciate it. I absolutely agree that this needs >>to >> be an iterative process and that we need data to analyze and improve. >> >> The last time this concern was raised (just before ISC) I did complete >>an >> analysis of every single Xyratex patch submitted against master and >>(other >> than a couple of feature patches that had been delayed by the 2.4 >>feature >> freeze) the longest wait that I saw at that time was only a few weeks. >> >> Xyratex committed at that time to provide a consolidated list of issues >> that are a concern. I suggest that we focus on that as a first step >>before >> getting into possible process changes so that we can be sure that our >> process reflects the actual situation. >> >> >> On 8/7/13 8:11 AM, "Denis Kondratenko" >>> >> wrote: >> >> OK, I will go and try to search. >> >> Maybe I have overestimated that, my apologize for that - will provide >>you >> numbers and examples. >> Point wasn't in that. >> >> Point was - we have no numbers - so nothing to analyze and improve. >> >> Thanks, >> Denis >> >> On 7 авг. 2013, at 18:03, "Jones, Peter A" >>> >> wrote: >> >> >> >> >> It is not a rare occurrence - patches that were submitted 6-12 months >> after it was first pushed for review. >> >> Denis, please give me three examples where patches pushed to master have >> waited 6-12 months after being pushed for review? >> >> I take this very seriously. >> >> There are certainly busy times when lower priority patches might need to >> wait but I have not seen anything that long. >> >> Feature patches submitted during the feature freeze, but that is usually >> more like 3-4 months in the worst case scenario. >> >> Sometimes people push patches against maintenance branches, which can be >> useful for the community but if these land it will only be at the time >> we >> create a maintenance release against that branch. >> >> >> >> >> -- >> >> >> ------------------------------ >> For additional information including the registered office and the >> treatment of Xyratex confidential information please visit >>www.xyratex.com >> >> ------------------------------ >> _______________________________________________ >> cdwg mailing list >> cdwg at lists.opensfs.org >> http://lists.opensfs.org/listinfo.cgi/cdwg-opensfs.org >> >> >> >> >> ________________________________ >> For additional information including the registered office and the >>treatment of Xyratex confidential information please visit >>www.xyratex.com >> >> ________________________________ > > >-- > > >------------------------------ >For additional information including the registered office and the >treatment of Xyratex confidential information please visit www.xyratex.com > >------------------------------ >_______________________________________________ >cdwg mailing list >cdwg at lists.opensfs.org >http://lists.opensfs.org/listinfo.cgi/cdwg-opensfs.org From morrone2 at llnl.gov Fri Aug 9 01:14:55 2013 From: morrone2 at llnl.gov (Christopher J. Morrone) Date: Thu, 08 Aug 2013 18:14:55 -0700 Subject: [cdwg] Monitoring Ticket Progress In-Reply-To: References: Message-ID: <5204428F.3090808@llnl.gov> On 08/08/2013 09:06 AM, Denis Kondratenko wrote: > That how this hole thread was started - we do want to do this under CDWG and just searching right way to do it. Great! I believe the right way to do it is for the patch submitter to keep track of his/her submissions. If a submitted patch needs attention, they should raise the issue in the associated Jira ticket. I find that often just a friendly reminder is all it takes to get attention on a patch, or an explanation of why the patch needs to wait. If that does not solve the problem, the next step is to raise the issue on the CDWG mailing list. List the specific patch(es) that you think need attention. We will discuss and come to a decision together. Lets try it out with the list that you supplied: >> http://review.whamcloud.com/#/c/3553/ Landed on master, August 6, 2013. No action needed. >> http://review.whamcloud.com/#/c/3277/ Landed on master, June 21, 2013. No action needed. >> http://review.whamcloud.com/#/c/5213/ -1 code review from Andreas, 30 inline comments. Waiting on Xyratex to fix and push next version for review. >> http://review.whamcloud.com/#/c/4372/ Landed on master, June 13, 2013. No action needed. >> http://review.whamcloud.com/#/c/4641/ Landed on b2_1, May 20, 2013. Out of scope for OpenSFS "tree contract", but nevertheless, no action needed. >> http://review.whamcloud.com/#/c/4664/ This is probably a good example of one that has sat a while. We could chat about what happened here. If you go to the associated jira ticket: https://jira.hpdd.intel.com/browse/LU-2377 it seems clear to me that Intel's opinion was that upstream ext4 was a more appropriate place for this patch than carrying it in the ldiskfs patch stack. Conversation between Xyratex and Intel looks like it went nicely. Did Xyratex follow through with sending this patch to the upstream ext4 developers? >> http://review.whamcloud.com/#/c/3725/ Patch is for b2_2. There are no community endorsed b2_2 maintenance releases. No action should be expected on this patch. If this is a problem that still exists on master, Xyratex should submit a patch to master. >> http://review.whamcloud.com/#/c/2406/ Patch is for b1_8. There are no longer any community endorsed b1_8 maintenance releases (some Lustre vendors offer their customers maintenance releases as they see fit). No action should be expected on this patch. ----- That is how I would envision the process going in the future. When developer feels that a patch isn't making enough progress, and didn't get an adequate explanation in Jira, they raise here with the CDWG. I will look it over as Technical Representative on the tree contract, along with anyone else in the CDWG that wants to contribute. Together with the interested party and Intel, we will decide on the needed course of action. > Again, I don't want to start any war or discussion about those tickets, or about some other. > I don't want to blame anyone about something. But for me obviously some problems exit. Ok, maybe those patches are not the right ones to discuss. But you really should start discussions about patches that are currently a problem. Bringing a problem to our attention should not be the start of a war. It should be the start of a discussion, which will result in a plan of action, which will guide us to a solution. Chris >> http://review.whamcloud.com/#/c/3553/ >> http://review.whamcloud.com/#/c/3277/ >> http://review.whamcloud.com/#/c/5213/ >> http://review.whamcloud.com/#/c/4372/ >> http://review.whamcloud.com/#/c/4641/ >> http://review.whamcloud.com/#/c/4664/ >> http://review.whamcloud.com/#/c/3725/ >> http://review.whamcloud.com/#/c/2406/ >> >> Again, I don't want to start any war or discussion about those tickets, or about some other. >> I don't want to blame anyone about something. But for me obviously some problems exit. >> >> Those tickets are probably all have good explanation why. >> My suggestion was to build process, that will resolve such issues automatically and will provide us stat and info about Sustaining review activities. >> What I don't want is to do it manually. >> >> What we propose is to define all stages of Sustaining process to gather all needed info to understand where we have most problems: >> * review resources >> * incorrect test failures >> * rebases >> * code freeze >> * some other… >> >> Process for all, not just Xyratex, but for all reviews. >> >> That will give us more visibility and possibility to improve. >> We are not saint and we need to improve too. We have issues with upstream submission too and there are no fault here in this discussion. >> >> Right now we know that only based on our experience in our heads, intuitively. >> >> Of course we could use any suggestions. If we all think that just e-mail with list will resolve this situation - we will use that. >> >> I just started this topic to share our process that could be useful, and gather other feedbacks - what could be done. >> >> Thanks, >> Denis >> >> On 7 авг. 2013, at 19:07, "Jones, Peter A" > wrote: >> >> Thanks Denis I would appreciate it. I absolutely agree that this needs to >> be an iterative process and that we need data to analyze and improve. >> >> The last time this concern was raised (just before ISC) I did complete an >> analysis of every single Xyratex patch submitted against master and (other >> than a couple of feature patches that had been delayed by the 2.4 feature >> freeze) the longest wait that I saw at that time was only a few weeks. >> >> Xyratex committed at that time to provide a consolidated list of issues >> that are a concern. I suggest that we focus on that as a first step before >> getting into possible process changes so that we can be sure that our >> process reflects the actual situation. >> >> >> On 8/7/13 8:11 AM, "Denis Kondratenko" > >> wrote: >> >> OK, I will go and try to search. >> >> Maybe I have overestimated that, my apologize for that - will provide you >> numbers and examples. >> Point wasn't in that. >> >> Point was - we have no numbers - so nothing to analyze and improve. >> >> Thanks, >> Denis >> >> On 7 авг. 2013, at 18:03, "Jones, Peter A" > >> wrote: >> >> >> >> >> It is not a rare occurrence - patches that were submitted 6-12 months >> after it was first pushed for review. >> >> Denis, please give me three examples where patches pushed to master have >> waited 6-12 months after being pushed for review? >> >> I take this very seriously. >> >> There are certainly busy times when lower priority patches might need to >> wait but I have not seen anything that long. >> >> Feature patches submitted during the feature freeze, but that is usually >> more like 3-4 months in the worst case scenario. >> >> Sometimes people push patches against maintenance branches, which can be >> useful for the community but if these land it will only be at the time >> we >> create a maintenance release against that branch. >> >> >> >> >> -- >> >> >> ------------------------------ >> For additional information including the registered office and the >> treatment of Xyratex confidential information please visit www.xyratex.com >> >> ------------------------------ >> _______________________________________________ >> cdwg mailing list >> cdwg at lists.opensfs.org >> http://lists.opensfs.org/listinfo.cgi/cdwg-opensfs.org >> >> >> >> >> ________________________________ >> For additional information including the registered office and the treatment of Xyratex confidential information please visit www.xyratex.com >> >> ________________________________ > > From kevin_canady at xyratex.com Fri Aug 9 02:44:00 2013 From: kevin_canady at xyratex.com (Kevin Canady) Date: Thu, 8 Aug 2013 19:44:00 -0700 Subject: [cdwg] Monitoring Ticket Progress In-Reply-To: <5204428F.3090808@llnl.gov> References: <5204428F.3090808@llnl.gov> Message-ID: <6C16DA71-D062-44AE-BC4D-766F0150C82B@xyratex.com> Chris, Peter and you continue to miss the main point Denis was making. There never was any implication of animosity, so no need to be defensive or stir such topic. There is no conflict. Somehow, and quite unfortunately, this thread continues to be stuck on the defense of specific patch activity when the main point that was being made was… >> Those tickets are probably all have good explanation why. >> My suggestion was to build process, that will resolve such issues automatically and will provide us stat and info about Sustaining review activities. >> What I don't want is to do it manually. >> >> What we propose is to define all stages of Sustaining process to gather all needed info to understand where we have most problems: >> * review resources >> * incorrect test failures >> * rebases >> * code freeze >> * some other… >> >> Process for all, not just Xyratex, but for all reviews. >> >> That will give us more visibility and possibility to improve. >> We are not saint and we need to improve too. We have issues with upstream submission too and there are no fault here in this discussion. >> >> Right now we know that only based on our experience in our heads, intuitively. >> >> Of course we could use any suggestions. If we all think that just e-mail with list will resolve this situation - we will use that. >> >> I just started this topic to share our process that could be useful, and gather other feedbacks - what could be done. It would be extremely helpful if we can remain centered on these discussions to make this a productive dialog. Kevin On Aug 8, 2013, at 6:14 PM, Christopher J. Morrone wrote: > On 08/08/2013 09:06 AM, Denis Kondratenko wrote: >> That how this hole thread was started - we do want to do this under CDWG and just searching right way to do it. > > Great! > > I believe the right way to do it is for the patch submitter to keep track of his/her submissions. If a submitted patch needs attention, they should raise the issue in the associated Jira ticket. I find that often just a friendly reminder is all it takes to get attention on a patch, or an explanation of why the patch needs to wait. > > If that does not solve the problem, the next step is to raise the issue on the CDWG mailing list. List the specific patch(es) that you think need attention. We will discuss and come to a decision together. > > Lets try it out with the list that you supplied: > > >> http://review.whamcloud.com/#/c/3553/ > > Landed on master, August 6, 2013. > No action needed. > > >> http://review.whamcloud.com/#/c/3277/ > > Landed on master, June 21, 2013. > No action needed. > > >> http://review.whamcloud.com/#/c/5213/ > > -1 code review from Andreas, 30 inline comments. > Waiting on Xyratex to fix and push next version for review. > > >> http://review.whamcloud.com/#/c/4372/ > > Landed on master, June 13, 2013. > No action needed. > > >> http://review.whamcloud.com/#/c/4641/ > > Landed on b2_1, May 20, 2013. > Out of scope for OpenSFS "tree contract", but nevertheless, no action needed. > > >> http://review.whamcloud.com/#/c/4664/ > > This is probably a good example of one that has sat a while. We could chat about what happened here. If you go to the associated jira ticket: > > https://jira.hpdd.intel.com/browse/LU-2377 > > it seems clear to me that Intel's opinion was that upstream ext4 was a more appropriate place for this patch than carrying it in the ldiskfs patch stack. > > Conversation between Xyratex and Intel looks like it went nicely. > > Did Xyratex follow through with sending this patch to the upstream ext4 developers? > > >> http://review.whamcloud.com/#/c/3725/ > > Patch is for b2_2. There are no community endorsed b2_2 maintenance releases. No action should be expected on this patch. > > If this is a problem that still exists on master, Xyratex should submit a patch to master. > > >> http://review.whamcloud.com/#/c/2406/ > > Patch is for b1_8. There are no longer any community endorsed b1_8 maintenance releases (some Lustre vendors offer their customers maintenance releases as they see fit). No action should be expected on this patch. > > ----- > > That is how I would envision the process going in the future. When developer feels that a patch isn't making enough progress, and didn't get an adequate explanation in Jira, they raise here with the CDWG. I will look it over as Technical Representative on the tree contract, along with anyone else in the CDWG that wants to contribute. > > Together with the interested party and Intel, we will decide on the needed course of action. > > > Again, I don't want to start any war or discussion about those tickets, or about some other. > > I don't want to blame anyone about something. But for me obviously some problems exit. > > Ok, maybe those patches are not the right ones to discuss. But you really should start discussions about patches that are currently a problem. Bringing a problem to our attention should not be the start of a war. It should be the start of a discussion, which will result in a plan of action, which will guide us to a solution. > > Chris > > >>> http://review.whamcloud.com/#/c/3553/ >>> http://review.whamcloud.com/#/c/3277/ >>> http://review.whamcloud.com/#/c/5213/ >>> http://review.whamcloud.com/#/c/4372/ >>> http://review.whamcloud.com/#/c/4641/ >>> http://review.whamcloud.com/#/c/4664/ >>> http://review.whamcloud.com/#/c/3725/ >>> http://review.whamcloud.com/#/c/2406/ >>> >>> Again, I don't want to start any war or discussion about those tickets, or about some other. >>> I don't want to blame anyone about something. But for me obviously some problems exit. >>> >>> Those tickets are probably all have good explanation why. >>> My suggestion was to build process, that will resolve such issues automatically and will provide us stat and info about Sustaining review activities. >>> What I don't want is to do it manually. >>> >>> What we propose is to define all stages of Sustaining process to gather all needed info to understand where we have most problems: >>> * review resources >>> * incorrect test failures >>> * rebases >>> * code freeze >>> * some other… >>> >>> Process for all, not just Xyratex, but for all reviews. >>> >>> That will give us more visibility and possibility to improve. >>> We are not saint and we need to improve too. We have issues with upstream submission too and there are no fault here in this discussion. >>> >>> Right now we know that only based on our experience in our heads, intuitively. >>> >>> Of course we could use any suggestions. If we all think that just e-mail with list will resolve this situation - we will use that. >>> >>> I just started this topic to share our process that could be useful, and gather other feedbacks - what could be done. >>> >>> Thanks, >>> Denis >>> >>> On 7 авг. 2013, at 19:07, "Jones, Peter A" > wrote: >>> >>> Thanks Denis I would appreciate it. I absolutely agree that this needs to >>> be an iterative process and that we need data to analyze and improve. >>> >>> The last time this concern was raised (just before ISC) I did complete an >>> analysis of every single Xyratex patch submitted against master and (other >>> than a couple of feature patches that had been delayed by the 2.4 feature >>> freeze) the longest wait that I saw at that time was only a few weeks. >>> >>> Xyratex committed at that time to provide a consolidated list of issues >>> that are a concern. I suggest that we focus on that as a first step before >>> getting into possible process changes so that we can be sure that our >>> process reflects the actual situation. >>> >>> >>> On 8/7/13 8:11 AM, "Denis Kondratenko" > >>> wrote: >>> >>> OK, I will go and try to search. >>> >>> Maybe I have overestimated that, my apologize for that - will provide you >>> numbers and examples. >>> Point wasn't in that. >>> >>> Point was - we have no numbers - so nothing to analyze and improve. >>> >>> Thanks, >>> Denis >>> >>> On 7 авг. 2013, at 18:03, "Jones, Peter A" > >>> wrote: >>> >>> >>> >>> >>> It is not a rare occurrence - patches that were submitted 6-12 months >>> after it was first pushed for review. >>> >>> Denis, please give me three examples where patches pushed to master have >>> waited 6-12 months after being pushed for review? >>> >>> I take this very seriously. >>> >>> There are certainly busy times when lower priority patches might need to >>> wait but I have not seen anything that long. >>> >>> Feature patches submitted during the feature freeze, but that is usually >>> more like 3-4 months in the worst case scenario. >>> >>> Sometimes people push patches against maintenance branches, which can be >>> useful for the community but if these land it will only be at the time >>> we >>> create a maintenance release against that branch. >>> >>> >>> >>> >>> -- >>> >>> >>> ------------------------------ >>> For additional information including the registered office and the >>> treatment of Xyratex confidential information please visit www.xyratex.com >>> >>> ------------------------------ >>> _______________________________________________ >>> cdwg mailing list >>> cdwg at lists.opensfs.org >>> http://lists.opensfs.org/listinfo.cgi/cdwg-opensfs.org >>> >>> >>> >>> >>> ________________________________ >>> For additional information including the registered office and the treatment of Xyratex confidential information please visit www.xyratex.com >>> >>> ________________________________ >> >> > > _______________________________________________ > cdwg mailing list > cdwg at lists.opensfs.org > http://lists.opensfs.org/listinfo.cgi/cdwg-opensfs.org From peter.a.jones at intel.com Fri Aug 9 05:08:50 2013 From: peter.a.jones at intel.com (Jones, Peter A) Date: Fri, 9 Aug 2013 05:08:50 +0000 Subject: [cdwg] Monitoring Ticket Progress In-Reply-To: <6C16DA71-D062-44AE-BC4D-766F0150C82B@xyratex.com> Message-ID: Hi Kevin I did understand what Denis was proposing and my only objection to it was that it would take time to set this up and I personally feel that this time could be better spent elsewhere. I think that it is perfectly healthy to discuss this and I do not think that you should feel threatened by such dialog. In my view, this thread has been quite productive in that Denis has had a flawed assumption clarified. >From what I have seen of Denis's work, I would expect him to respond to that in a positive manner. Regards Peter On 8/8/13 7:44 PM, "Kevin Canady" wrote: >Chris, >Peter and you continue to miss the main point Denis was making. There >never was any implication of animosity, so no need to be defensive or >stir such topic. There is no conflict. Somehow, and quite >unfortunately, this thread continues to be stuck on the defense of >specific patch activity when the main point that was being made was… > >>> Those tickets are probably all have good explanation why. >>> My suggestion was to build process, that will resolve such issues >>>automatically and will provide us stat and info about Sustaining review >>>activities. >>> What I don't want is to do it manually. >>> >>> What we propose is to define all stages of Sustaining process to >>>gather all needed info to understand where we have most problems: >>> * review resources >>> * incorrect test failures >>> * rebases >>> * code freeze >>> * some other… >>> >>> Process for all, not just Xyratex, but for all reviews. >>> >>> That will give us more visibility and possibility to improve. >>> We are not saint and we need to improve too. We have issues with >>>upstream submission too and there are no fault here in this discussion. >>> >>> Right now we know that only based on our experience in our heads, >>>intuitively. >>> >>> Of course we could use any suggestions. If we all think that just >>>e-mail with list will resolve this situation - we will use that. >>> >>> I just started this topic to share our process that could be useful, >>>and gather other feedbacks - what could be done. > >It would be extremely helpful if we can remain centered on these >discussions to make this a productive dialog. > >Kevin > >On Aug 8, 2013, at 6:14 PM, Christopher J. Morrone >wrote: > >> On 08/08/2013 09:06 AM, Denis Kondratenko wrote: >>> That how this hole thread was started - we do want to do this under >>>CDWG and just searching right way to do it. >> >> Great! >> >> I believe the right way to do it is for the patch submitter to keep >>track of his/her submissions. If a submitted patch needs attention, >>they should raise the issue in the associated Jira ticket. I find that >>often just a friendly reminder is all it takes to get attention on a >>patch, or an explanation of why the patch needs to wait. >> >> If that does not solve the problem, the next step is to raise the issue >>on the CDWG mailing list. List the specific patch(es) that you think >>need attention. We will discuss and come to a decision together. >> >> Lets try it out with the list that you supplied: >> >> >> http://review.whamcloud.com/#/c/3553/ >> >> Landed on master, August 6, 2013. >> No action needed. >> >> >> http://review.whamcloud.com/#/c/3277/ >> >> Landed on master, June 21, 2013. >> No action needed. >> >> >> http://review.whamcloud.com/#/c/5213/ >> >> -1 code review from Andreas, 30 inline comments. >> Waiting on Xyratex to fix and push next version for review. >> >> >> http://review.whamcloud.com/#/c/4372/ >> >> Landed on master, June 13, 2013. >> No action needed. >> >> >> http://review.whamcloud.com/#/c/4641/ >> >> Landed on b2_1, May 20, 2013. >> Out of scope for OpenSFS "tree contract", but nevertheless, no action >>needed. >> >> >> http://review.whamcloud.com/#/c/4664/ >> >> This is probably a good example of one that has sat a while. We could >>chat about what happened here. If you go to the associated jira ticket: >> >> https://jira.hpdd.intel.com/browse/LU-2377 >> >> it seems clear to me that Intel's opinion was that upstream ext4 was a >>more appropriate place for this patch than carrying it in the ldiskfs >>patch stack. >> >> Conversation between Xyratex and Intel looks like it went nicely. >> >> Did Xyratex follow through with sending this patch to the upstream ext4 >>developers? >> >> >> http://review.whamcloud.com/#/c/3725/ >> >> Patch is for b2_2. There are no community endorsed b2_2 maintenance >>releases. No action should be expected on this patch. >> >> If this is a problem that still exists on master, Xyratex should submit >>a patch to master. >> >> >> http://review.whamcloud.com/#/c/2406/ >> >> Patch is for b1_8. There are no longer any community endorsed b1_8 >>maintenance releases (some Lustre vendors offer their customers >>maintenance releases as they see fit). No action should be expected on >>this patch. >> >> ----- >> >> That is how I would envision the process going in the future. When >>developer feels that a patch isn't making enough progress, and didn't >>get an adequate explanation in Jira, they raise here with the CDWG. I >>will look it over as Technical Representative on the tree contract, >>along with anyone else in the CDWG that wants to contribute. >> >> Together with the interested party and Intel, we will decide on the >>needed course of action. >> >> > Again, I don't want to start any war or discussion about those >>tickets, or about some other. >> > I don't want to blame anyone about something. But for me obviously >>some problems exit. >> >> Ok, maybe those patches are not the right ones to discuss. But you >>really should start discussions about patches that are currently a >>problem. Bringing a problem to our attention should not be the start of >>a war. It should be the start of a discussion, which will result in a >>plan of action, which will guide us to a solution. >> >> Chris >> >> >>>> http://review.whamcloud.com/#/c/3553/ >>>> http://review.whamcloud.com/#/c/3277/ >>>> http://review.whamcloud.com/#/c/5213/ >>>> http://review.whamcloud.com/#/c/4372/ >>>> http://review.whamcloud.com/#/c/4641/ >>>> http://review.whamcloud.com/#/c/4664/ >>>> http://review.whamcloud.com/#/c/3725/ >>>> http://review.whamcloud.com/#/c/2406/ >>>> >>>> Again, I don't want to start any war or discussion about those >>>>tickets, or about some other. >>>> I don't want to blame anyone about something. But for me obviously >>>>some problems exit. >>>> >>>> Those tickets are probably all have good explanation why. >>>> My suggestion was to build process, that will resolve such issues >>>>automatically and will provide us stat and info about Sustaining >>>>review activities. >>>> What I don't want is to do it manually. >>>> >>>> What we propose is to define all stages of Sustaining process to >>>>gather all needed info to understand where we have most problems: >>>> * review resources >>>> * incorrect test failures >>>> * rebases >>>> * code freeze >>>> * some other… >>>> >>>> Process for all, not just Xyratex, but for all reviews. >>>> >>>> That will give us more visibility and possibility to improve. >>>> We are not saint and we need to improve too. We have issues with >>>>upstream submission too and there are no fault here in this discussion. >>>> >>>> Right now we know that only based on our experience in our heads, >>>>intuitively. >>>> >>>> Of course we could use any suggestions. If we all think that just >>>>e-mail with list will resolve this situation - we will use that. >>>> >>>> I just started this topic to share our process that could be useful, >>>>and gather other feedbacks - what could be done. >>>> >>>> Thanks, >>>> Denis >>>> >>>> On 7 авг. 2013, at 19:07, "Jones, Peter A" >>>>> wrote: >>>> >>>> Thanks Denis I would appreciate it. I absolutely agree that this >>>>needs to >>>> be an iterative process and that we need data to analyze and improve. >>>> >>>> The last time this concern was raised (just before ISC) I did >>>>complete an >>>> analysis of every single Xyratex patch submitted against master and >>>>(other >>>> than a couple of feature patches that had been delayed by the 2.4 >>>>feature >>>> freeze) the longest wait that I saw at that time was only a few weeks. >>>> >>>> Xyratex committed at that time to provide a consolidated list of >>>>issues >>>> that are a concern. I suggest that we focus on that as a first step >>>>before >>>> getting into possible process changes so that we can be sure that our >>>> process reflects the actual situation. >>>> >>>> >>>> On 8/7/13 8:11 AM, "Denis Kondratenko" >>>>> >>>> wrote: >>>> >>>> OK, I will go and try to search. >>>> >>>> Maybe I have overestimated that, my apologize for that - will provide >>>>you >>>> numbers and examples. >>>> Point wasn't in that. >>>> >>>> Point was - we have no numbers - so nothing to analyze and improve. >>>> >>>> Thanks, >>>> Denis >>>> >>>> On 7 авг. 2013, at 18:03, "Jones, Peter A" >>>>> >>>> wrote: >>>> >>>> >>>> >>>> >>>> It is not a rare occurrence - patches that were submitted 6-12 months >>>> after it was first pushed for review. >>>> >>>> Denis, please give me three examples where patches pushed to master >>>>have >>>> waited 6-12 months after being pushed for review? >>>> >>>> I take this very seriously. >>>> >>>> There are certainly busy times when lower priority patches might need >>>>to >>>> wait but I have not seen anything that long. >>>> >>>> Feature patches submitted during the feature freeze, but that is >>>>usually >>>> more like 3-4 months in the worst case scenario. >>>> >>>> Sometimes people push patches against maintenance branches, which can >>>>be >>>> useful for the community but if these land it will only be at the time >>>> we >>>> create a maintenance release against that branch. >>>> >>>> >>>> >>>> >>>> -- >>>> >>>> >>>> ------------------------------ >>>> For additional information including the registered office and the >>>> treatment of Xyratex confidential information please visit >>>>www.xyratex.com >>>> >>>> ------------------------------ >>>> _______________________________________________ >>>> cdwg mailing list >>>> cdwg at lists.opensfs.org >>>> http://lists.opensfs.org/listinfo.cgi/cdwg-opensfs.org >>>> >>>> >>>> >>>> >>>> ________________________________ >>>> For additional information including the registered office and the >>>>treatment of Xyratex confidential information please visit >>>>www.xyratex.com >>>> >>>> ________________________________ >>> >>> >> >> _______________________________________________ >> cdwg mailing list >> cdwg at lists.opensfs.org >> http://lists.opensfs.org/listinfo.cgi/cdwg-opensfs.org > >_______________________________________________ >cdwg mailing list >cdwg at lists.opensfs.org >http://lists.opensfs.org/listinfo.cgi/cdwg-opensfs.org From denis_kondratenko at xyratex.com Fri Aug 9 06:14:04 2013 From: denis_kondratenko at xyratex.com (Denis Kondratenko) Date: Fri, 9 Aug 2013 09:14:04 +0300 Subject: [cdwg] Monitoring Ticket Progress In-Reply-To: References: <6C16DA71-D062-44AE-BC4D-766F0150C82B@xyratex.com> Message-ID: Hi Team, I would like to end this thread for a while to take time, to think and to lower it temperature. We have shared our thoughts and process with free will and not bearing secret malice against someone. That's a way I thought team work should be done - sharing great experience and learn something new from others. My examples were not full and not for discussion in details. I should be more careful with my statements either. Red column were just an example and not a way to blame someone. I haven't hear before that Sustaining was a part of discussion at CDWG, when it is important part of SW life cycle. We are in Xyratex taking this part very seriously and having mature and good process, that works for us. We have shared a piece of it to understand how we could make quality of Lustre better by understanding some of it parameters greater. And that is not just for us but for community. I would like to shake your hands and left all misunderstanding behind us. Any community need to grow to it maturity state, because there are to many people with different opinions. So everything OK :-) Thanks, Denis On Aug 9, 2013 8:08 AM, "Jones, Peter A" wrote: > Hi Kevin > > I did understand what Denis was proposing and my only objection to it was > that it would take time to set this up and I personally feel that this > time could be better spent elsewhere. > > I think that it is perfectly healthy to discuss this and I do not think > that you should feel threatened by such dialog. > > In my view, this thread has been quite productive in that Denis has had a > flawed assumption clarified. > > From what I have seen of Denis's work, I would expect him to respond to > that in a positive manner. > > Regards > > Peter > > On 8/8/13 7:44 PM, "Kevin Canady" wrote: > > >Chris, > >Peter and you continue to miss the main point Denis was making. There > >never was any implication of animosity, so no need to be defensive or > >stir such topic. There is no conflict. Somehow, and quite > >unfortunately, this thread continues to be stuck on the defense of > >specific patch activity when the main point that was being made was… > > > >>> Those tickets are probably all have good explanation why. > >>> My suggestion was to build process, that will resolve such issues > >>>automatically and will provide us stat and info about Sustaining review > >>>activities. > >>> What I don't want is to do it manually. > >>> > >>> What we propose is to define all stages of Sustaining process to > >>>gather all needed info to understand where we have most problems: > >>> * review resources > >>> * incorrect test failures > >>> * rebases > >>> * code freeze > >>> * some other… > >>> > >>> Process for all, not just Xyratex, but for all reviews. > >>> > >>> That will give us more visibility and possibility to improve. > >>> We are not saint and we need to improve too. We have issues with > >>>upstream submission too and there are no fault here in this discussion. > >>> > >>> Right now we know that only based on our experience in our heads, > >>>intuitively. > >>> > >>> Of course we could use any suggestions. If we all think that just > >>>e-mail with list will resolve this situation - we will use that. > >>> > >>> I just started this topic to share our process that could be useful, > >>>and gather other feedbacks - what could be done. > > > >It would be extremely helpful if we can remain centered on these > >discussions to make this a productive dialog. > > > >Kevin > > > >On Aug 8, 2013, at 6:14 PM, Christopher J. Morrone > >wrote: > > > >> On 08/08/2013 09:06 AM, Denis Kondratenko wrote: > >>> That how this hole thread was started - we do want to do this under > >>>CDWG and just searching right way to do it. > >> > >> Great! > >> > >> I believe the right way to do it is for the patch submitter to keep > >>track of his/her submissions. If a submitted patch needs attention, > >>they should raise the issue in the associated Jira ticket. I find that > >>often just a friendly reminder is all it takes to get attention on a > >>patch, or an explanation of why the patch needs to wait. > >> > >> If that does not solve the problem, the next step is to raise the issue > >>on the CDWG mailing list. List the specific patch(es) that you think > >>need attention. We will discuss and come to a decision together. > >> > >> Lets try it out with the list that you supplied: > >> > >> >> http://review.whamcloud.com/#/c/3553/ > >> > >> Landed on master, August 6, 2013. > >> No action needed. > >> > >> >> http://review.whamcloud.com/#/c/3277/ > >> > >> Landed on master, June 21, 2013. > >> No action needed. > >> > >> >> http://review.whamcloud.com/#/c/5213/ > >> > >> -1 code review from Andreas, 30 inline comments. > >> Waiting on Xyratex to fix and push next version for review. > >> > >> >> http://review.whamcloud.com/#/c/4372/ > >> > >> Landed on master, June 13, 2013. > >> No action needed. > >> > >> >> http://review.whamcloud.com/#/c/4641/ > >> > >> Landed on b2_1, May 20, 2013. > >> Out of scope for OpenSFS "tree contract", but nevertheless, no action > >>needed. > >> > >> >> http://review.whamcloud.com/#/c/4664/ > >> > >> This is probably a good example of one that has sat a while. We could > >>chat about what happened here. If you go to the associated jira ticket: > >> > >> https://jira.hpdd.intel.com/browse/LU-2377 > >> > >> it seems clear to me that Intel's opinion was that upstream ext4 was a > >>more appropriate place for this patch than carrying it in the ldiskfs > >>patch stack. > >> > >> Conversation between Xyratex and Intel looks like it went nicely. > >> > >> Did Xyratex follow through with sending this patch to the upstream ext4 > >>developers? > >> > >> >> http://review.whamcloud.com/#/c/3725/ > >> > >> Patch is for b2_2. There are no community endorsed b2_2 maintenance > >>releases. No action should be expected on this patch. > >> > >> If this is a problem that still exists on master, Xyratex should submit > >>a patch to master. > >> > >> >> http://review.whamcloud.com/#/c/2406/ > >> > >> Patch is for b1_8. There are no longer any community endorsed b1_8 > >>maintenance releases (some Lustre vendors offer their customers > >>maintenance releases as they see fit). No action should be expected on > >>this patch. > >> > >> ----- > >> > >> That is how I would envision the process going in the future. When > >>developer feels that a patch isn't making enough progress, and didn't > >>get an adequate explanation in Jira, they raise here with the CDWG. I > >>will look it over as Technical Representative on the tree contract, > >>along with anyone else in the CDWG that wants to contribute. > >> > >> Together with the interested party and Intel, we will decide on the > >>needed course of action. > >> > >> > Again, I don't want to start any war or discussion about those > >>tickets, or about some other. > >> > I don't want to blame anyone about something. But for me obviously > >>some problems exit. > >> > >> Ok, maybe those patches are not the right ones to discuss. But you > >>really should start discussions about patches that are currently a > >>problem. Bringing a problem to our attention should not be the start of > >>a war. It should be the start of a discussion, which will result in a > >>plan of action, which will guide us to a solution. > >> > >> Chris > >> > >> > >>>> http://review.whamcloud.com/#/c/3553/ > >>>> http://review.whamcloud.com/#/c/3277/ > >>>> http://review.whamcloud.com/#/c/5213/ > >>>> http://review.whamcloud.com/#/c/4372/ > >>>> http://review.whamcloud.com/#/c/4641/ > >>>> http://review.whamcloud.com/#/c/4664/ > >>>> http://review.whamcloud.com/#/c/3725/ > >>>> http://review.whamcloud.com/#/c/2406/ > >>>> > >>>> Again, I don't want to start any war or discussion about those > >>>>tickets, or about some other. > >>>> I don't want to blame anyone about something. But for me obviously > >>>>some problems exit. > >>>> > >>>> Those tickets are probably all have good explanation why. > >>>> My suggestion was to build process, that will resolve such issues > >>>>automatically and will provide us stat and info about Sustaining > >>>>review activities. > >>>> What I don't want is to do it manually. > >>>> > >>>> What we propose is to define all stages of Sustaining process to > >>>>gather all needed info to understand where we have most problems: > >>>> * review resources > >>>> * incorrect test failures > >>>> * rebases > >>>> * code freeze > >>>> * some other… > >>>> > >>>> Process for all, not just Xyratex, but for all reviews. > >>>> > >>>> That will give us more visibility and possibility to improve. > >>>> We are not saint and we need to improve too. We have issues with > >>>>upstream submission too and there are no fault here in this discussion. > >>>> > >>>> Right now we know that only based on our experience in our heads, > >>>>intuitively. > >>>> > >>>> Of course we could use any suggestions. If we all think that just > >>>>e-mail with list will resolve this situation - we will use that. > >>>> > >>>> I just started this topic to share our process that could be useful, > >>>>and gather other feedbacks - what could be done. > >>>> > >>>> Thanks, > >>>> Denis > >>>> > >>>> On 7 авг. 2013, at 19:07, "Jones, Peter A" > >>>>> wrote: > >>>> > >>>> Thanks Denis I would appreciate it. I absolutely agree that this > >>>>needs to > >>>> be an iterative process and that we need data to analyze and improve. > >>>> > >>>> The last time this concern was raised (just before ISC) I did > >>>>complete an > >>>> analysis of every single Xyratex patch submitted against master and > >>>>(other > >>>> than a couple of feature patches that had been delayed by the 2.4 > >>>>feature > >>>> freeze) the longest wait that I saw at that time was only a few weeks. > >>>> > >>>> Xyratex committed at that time to provide a consolidated list of > >>>>issues > >>>> that are a concern. I suggest that we focus on that as a first step > >>>>before > >>>> getting into possible process changes so that we can be sure that our > >>>> process reflects the actual situation. > >>>> > >>>> > >>>> On 8/7/13 8:11 AM, "Denis Kondratenko" > >>>>> > >>>> wrote: > >>>> > >>>> OK, I will go and try to search. > >>>> > >>>> Maybe I have overestimated that, my apologize for that - will provide > >>>>you > >>>> numbers and examples. > >>>> Point wasn't in that. > >>>> > >>>> Point was - we have no numbers - so nothing to analyze and improve. > >>>> > >>>> Thanks, > >>>> Denis > >>>> > >>>> On 7 авг. 2013, at 18:03, "Jones, Peter A" > >>>>> > >>>> wrote: > >>>> > >>>> > >>>> > >>>> > >>>> It is not a rare occurrence - patches that were submitted 6-12 months > >>>> after it was first pushed for review. > >>>> > >>>> Denis, please give me three examples where patches pushed to master > >>>>have > >>>> waited 6-12 months after being pushed for review? > >>>> > >>>> I take this very seriously. > >>>> > >>>> There are certainly busy times when lower priority patches might need > >>>>to > >>>> wait but I have not seen anything that long. > >>>> > >>>> Feature patches submitted during the feature freeze, but that is > >>>>usually > >>>> more like 3-4 months in the worst case scenario. > >>>> > >>>> Sometimes people push patches against maintenance branches, which can > >>>>be > >>>> useful for the community but if these land it will only be at the time > >>>> we > >>>> create a maintenance release against that branch. > >>>> > >>>> > >>>> > >>>> > >>>> -- > >>>> > >>>> > >>>> ------------------------------ > >>>> For additional information including the registered office and the > >>>> treatment of Xyratex confidential information please visit > >>>>www.xyratex.com > >>>> > >>>> ------------------------------ > >>>> _______________________________________________ > >>>> cdwg mailing list > >>>> cdwg at lists.opensfs.org > >>>> http://lists.opensfs.org/listinfo.cgi/cdwg-opensfs.org > >>>> > >>>> > >>>> > >>>> > >>>> ________________________________ > >>>> For additional information including the registered office and the > >>>>treatment of Xyratex confidential information please visit > >>>>www.xyratex.com > >>>> > >>>> ________________________________ > >>> > >>> > >> > >> _______________________________________________ > >> cdwg mailing list > >> cdwg at lists.opensfs.org > >> http://lists.opensfs.org/listinfo.cgi/cdwg-opensfs.org > > > >_______________________________________________ > >cdwg mailing list > >cdwg at lists.opensfs.org > >http://lists.opensfs.org/listinfo.cgi/cdwg-opensfs.org > > _______________________________________________ > cdwg mailing list > cdwg at lists.opensfs.org > http://lists.opensfs.org/listinfo.cgi/cdwg-opensfs.org > -- ------------------------------ For additional information including the registered office and the treatment of Xyratex confidential information please visit www.xyratex.com ------------------------------ -------------- next part -------------- An HTML attachment was scrubbed... URL: From peter.a.jones at intel.com Fri Aug 9 12:04:50 2013 From: peter.a.jones at intel.com (Jones, Peter A) Date: Fri, 9 Aug 2013 12:04:50 +0000 Subject: [cdwg] Monitoring Ticket Progress In-Reply-To: Message-ID: Kevin Re-reading this email sent at the end of a long day, I wonder if it does not come across in the spirit that it was intended. Sorry if that is the case and I will try and make amends now. I appreciate that this is not really your area, so you must feel pretty concerned to step in like this, so I really hope that I can set your mind at ease here. I think that you have picked out a very useful part of the thread. I would absolutely love to have some better tools that allowed me to quickly spot patterns and anomalies amongst all the hundreds of patches flowing through the system. The current mechanisms are a little crude and definitely not intuitive. There is also a lack of metrics for us to track our effectiveness over time. Ultimately, though, such a system is simply a tool to help us improve the patch landing process itself. It will enable us to identify patches where things are not running smoothly for whatever reason, review them, and take corrective action. It is by this iterative process that will help us improve over time. My concern is that I do not want us to wait until we have an improved tracking system in place before we start other improvements to our processes. While not needing to dwell on the specifics of the tickets, my takeaway was that there was low hanging fruit in this area across the board, so I think that it illustrates the value of using the options at our disposal today to improve things in parallel to any longer-term initiative to have a more automated mechanism in place. John Forgan of Xyratex sent out some filters which could generate some possible candidates for discussion and, to my mind, each individual engineer has a more manageable number of patches that they authored and know intimately and so should be able to flag situations where closer attention seems warranted. Discussing such matters has been a long-standing - but rarely used - function of the CDWG and I really think that we would all benefit from taking better advantage of this. I hope that this clarifies things for you. If not, then please feel free to call me and let's talk this over or, of course, we can talk about this on next week's CDWG call. Regards Peter On 8/8/13 10:08 PM, "Jones, Peter A" wrote: >Hi Kevin > >I did understand what Denis was proposing and my only objection to it was >that it would take time to set this up and I personally feel that this >time could be better spent elsewhere. > >I think that it is perfectly healthy to discuss this and I do not think >that you should feel threatened by such dialog. > >In my view, this thread has been quite productive in that Denis has had a >flawed assumption clarified. > >From what I have seen of Denis's work, I would expect him to respond to >that in a positive manner. > >Regards > >Peter > >On 8/8/13 7:44 PM, "Kevin Canady" wrote: > >>Chris, >>Peter and you continue to miss the main point Denis was making. There >>never was any implication of animosity, so no need to be defensive or >>stir such topic. There is no conflict. Somehow, and quite >>unfortunately, this thread continues to be stuck on the defense of >>specific patch activity when the main point that was being made was… >> >>>> Those tickets are probably all have good explanation why. >>>> My suggestion was to build process, that will resolve such issues >>>>automatically and will provide us stat and info about Sustaining review >>>>activities. >>>> What I don't want is to do it manually. >>>> >>>> What we propose is to define all stages of Sustaining process to >>>>gather all needed info to understand where we have most problems: >>>> * review resources >>>> * incorrect test failures >>>> * rebases >>>> * code freeze >>>> * some other… >>>> >>>> Process for all, not just Xyratex, but for all reviews. >>>> >>>> That will give us more visibility and possibility to improve. >>>> We are not saint and we need to improve too. We have issues with >>>>upstream submission too and there are no fault here in this discussion. >>>> >>>> Right now we know that only based on our experience in our heads, >>>>intuitively. >>>> >>>> Of course we could use any suggestions. If we all think that just >>>>e-mail with list will resolve this situation - we will use that. >>>> >>>> I just started this topic to share our process that could be useful, >>>>and gather other feedbacks - what could be done. >> >>It would be extremely helpful if we can remain centered on these >>discussions to make this a productive dialog. >> >>Kevin >> >>On Aug 8, 2013, at 6:14 PM, Christopher J. Morrone >>wrote: >> >>> On 08/08/2013 09:06 AM, Denis Kondratenko wrote: >>>> That how this hole thread was started - we do want to do this under >>>>CDWG and just searching right way to do it. >>> >>> Great! >>> >>> I believe the right way to do it is for the patch submitter to keep >>>track of his/her submissions. If a submitted patch needs attention, >>>they should raise the issue in the associated Jira ticket. I find that >>>often just a friendly reminder is all it takes to get attention on a >>>patch, or an explanation of why the patch needs to wait. >>> >>> If that does not solve the problem, the next step is to raise the issue >>>on the CDWG mailing list. List the specific patch(es) that you think >>>need attention. We will discuss and come to a decision together. >>> >>> Lets try it out with the list that you supplied: >>> >>> >> http://review.whamcloud.com/#/c/3553/ >>> >>> Landed on master, August 6, 2013. >>> No action needed. >>> >>> >> http://review.whamcloud.com/#/c/3277/ >>> >>> Landed on master, June 21, 2013. >>> No action needed. >>> >>> >> http://review.whamcloud.com/#/c/5213/ >>> >>> -1 code review from Andreas, 30 inline comments. >>> Waiting on Xyratex to fix and push next version for review. >>> >>> >> http://review.whamcloud.com/#/c/4372/ >>> >>> Landed on master, June 13, 2013. >>> No action needed. >>> >>> >> http://review.whamcloud.com/#/c/4641/ >>> >>> Landed on b2_1, May 20, 2013. >>> Out of scope for OpenSFS "tree contract", but nevertheless, no action >>>needed. >>> >>> >> http://review.whamcloud.com/#/c/4664/ >>> >>> This is probably a good example of one that has sat a while. We could >>>chat about what happened here. If you go to the associated jira ticket: >>> >>> https://jira.hpdd.intel.com/browse/LU-2377 >>> >>> it seems clear to me that Intel's opinion was that upstream ext4 was a >>>more appropriate place for this patch than carrying it in the ldiskfs >>>patch stack. >>> >>> Conversation between Xyratex and Intel looks like it went nicely. >>> >>> Did Xyratex follow through with sending this patch to the upstream ext4 >>>developers? >>> >>> >> http://review.whamcloud.com/#/c/3725/ >>> >>> Patch is for b2_2. There are no community endorsed b2_2 maintenance >>>releases. No action should be expected on this patch. >>> >>> If this is a problem that still exists on master, Xyratex should submit >>>a patch to master. >>> >>> >> http://review.whamcloud.com/#/c/2406/ >>> >>> Patch is for b1_8. There are no longer any community endorsed b1_8 >>>maintenance releases (some Lustre vendors offer their customers >>>maintenance releases as they see fit). No action should be expected on >>>this patch. >>> >>> ----- >>> >>> That is how I would envision the process going in the future. When >>>developer feels that a patch isn't making enough progress, and didn't >>>get an adequate explanation in Jira, they raise here with the CDWG. I >>>will look it over as Technical Representative on the tree contract, >>>along with anyone else in the CDWG that wants to contribute. >>> >>> Together with the interested party and Intel, we will decide on the >>>needed course of action. >>> >>> > Again, I don't want to start any war or discussion about those >>>tickets, or about some other. >>> > I don't want to blame anyone about something. But for me obviously >>>some problems exit. >>> >>> Ok, maybe those patches are not the right ones to discuss. But you >>>really should start discussions about patches that are currently a >>>problem. Bringing a problem to our attention should not be the start of >>>a war. It should be the start of a discussion, which will result in a >>>plan of action, which will guide us to a solution. >>> >>> Chris >>> >>> >>>>> http://review.whamcloud.com/#/c/3553/ >>>>> http://review.whamcloud.com/#/c/3277/ >>>>> http://review.whamcloud.com/#/c/5213/ >>>>> http://review.whamcloud.com/#/c/4372/ >>>>> http://review.whamcloud.com/#/c/4641/ >>>>> http://review.whamcloud.com/#/c/4664/ >>>>> http://review.whamcloud.com/#/c/3725/ >>>>> http://review.whamcloud.com/#/c/2406/ >>>>> >>>>> Again, I don't want to start any war or discussion about those >>>>>tickets, or about some other. >>>>> I don't want to blame anyone about something. But for me obviously >>>>>some problems exit. >>>>> >>>>> Those tickets are probably all have good explanation why. >>>>> My suggestion was to build process, that will resolve such issues >>>>>automatically and will provide us stat and info about Sustaining >>>>>review activities. >>>>> What I don't want is to do it manually. >>>>> >>>>> What we propose is to define all stages of Sustaining process to >>>>>gather all needed info to understand where we have most problems: >>>>> * review resources >>>>> * incorrect test failures >>>>> * rebases >>>>> * code freeze >>>>> * some other… >>>>> >>>>> Process for all, not just Xyratex, but for all reviews. >>>>> >>>>> That will give us more visibility and possibility to improve. >>>>> We are not saint and we need to improve too. We have issues with >>>>>upstream submission too and there are no fault here in this >>>>>discussion. >>>>> >>>>> Right now we know that only based on our experience in our heads, >>>>>intuitively. >>>>> >>>>> Of course we could use any suggestions. If we all think that just >>>>>e-mail with list will resolve this situation - we will use that. >>>>> >>>>> I just started this topic to share our process that could be useful, >>>>>and gather other feedbacks - what could be done. >>>>> >>>>> Thanks, >>>>> Denis >>>>> >>>>> On 7 авг. 2013, at 19:07, "Jones, Peter A" >>>>>> wrote: >>>>> >>>>> Thanks Denis I would appreciate it. I absolutely agree that this >>>>>needs to >>>>> be an iterative process and that we need data to analyze and improve. >>>>> >>>>> The last time this concern was raised (just before ISC) I did >>>>>complete an >>>>> analysis of every single Xyratex patch submitted against master and >>>>>(other >>>>> than a couple of feature patches that had been delayed by the 2.4 >>>>>feature >>>>> freeze) the longest wait that I saw at that time was only a few >>>>>weeks. >>>>> >>>>> Xyratex committed at that time to provide a consolidated list of >>>>>issues >>>>> that are a concern. I suggest that we focus on that as a first step >>>>>before >>>>> getting into possible process changes so that we can be sure that our >>>>> process reflects the actual situation. >>>>> >>>>> >>>>> On 8/7/13 8:11 AM, "Denis Kondratenko" >>>>>> >>>>> wrote: >>>>> >>>>> OK, I will go and try to search. >>>>> >>>>> Maybe I have overestimated that, my apologize for that - will provide >>>>>you >>>>> numbers and examples. >>>>> Point wasn't in that. >>>>> >>>>> Point was - we have no numbers - so nothing to analyze and improve. >>>>> >>>>> Thanks, >>>>> Denis >>>>> >>>>> On 7 авг. 2013, at 18:03, "Jones, Peter A" >>>>>> >>>>> wrote: >>>>> >>>>> >>>>> >>>>> >>>>> It is not a rare occurrence - patches that were submitted 6-12 months >>>>> after it was first pushed for review. >>>>> >>>>> Denis, please give me three examples where patches pushed to master >>>>>have >>>>> waited 6-12 months after being pushed for review? >>>>> >>>>> I take this very seriously. >>>>> >>>>> There are certainly busy times when lower priority patches might need >>>>>to >>>>> wait but I have not seen anything that long. >>>>> >>>>> Feature patches submitted during the feature freeze, but that is >>>>>usually >>>>> more like 3-4 months in the worst case scenario. >>>>> >>>>> Sometimes people push patches against maintenance branches, which can >>>>>be >>>>> useful for the community but if these land it will only be at the >>>>>time >>>>> we >>>>> create a maintenance release against that branch. >>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> >>>>> >>>>> ------------------------------ >>>>> For additional information including the registered office and the >>>>> treatment of Xyratex confidential information please visit >>>>>www.xyratex.com >>>>> >>>>> ------------------------------ >>>>> _______________________________________________ >>>>> cdwg mailing list >>>>> cdwg at lists.opensfs.org >>>>> http://lists.opensfs.org/listinfo.cgi/cdwg-opensfs.org >>>>> >>>>> >>>>> >>>>> >>>>> ________________________________ >>>>> For additional information including the registered office and the >>>>>treatment of Xyratex confidential information please visit >>>>>www.xyratex.com >>>>> >>>>> ________________________________ >>>> >>>> >>> >>> _______________________________________________ >>> cdwg mailing list >>> cdwg at lists.opensfs.org >>> http://lists.opensfs.org/listinfo.cgi/cdwg-opensfs.org >> >>_______________________________________________ >>cdwg mailing list >>cdwg at lists.opensfs.org >>http://lists.opensfs.org/listinfo.cgi/cdwg-opensfs.org > From kevin_canady at xyratex.com Fri Aug 9 15:14:09 2013 From: kevin_canady at xyratex.com (Kevin Canady) Date: Fri, 9 Aug 2013 08:14:09 -0700 Subject: [cdwg] Monitoring Ticket Progress In-Reply-To: References: Message-ID: <89011036-EA10-4D0C-943E-0F495E5B40FB@xyratex.com> Many thanks, Peter. I believe you are hitting the right points here. Collective negotiations especially using email lists and a biweekly call can be challenging to have such discussions and projects coordinate. It's an enormous challenge but the benefits of improvement are something we can all benefit from. Even though attempts may have been made in the past, it's really on going process of continuing improvement. One that should be balanced and not put unreasonable pressures on your organization. We all very much appreciate your efforts. Cheers, Kevin P. Kevin Canady Director, Business Development Lustre and HPC Services kevin_canady at xyratex.com O: 510-687-5475 C: 415.505.7701 (best) On Aug 9, 2013, at 5:04 AM, "Jones, Peter A" wrote: > Kevin > > Re-reading this email sent at the end of a long day, I wonder if it does > not come across in the spirit that it was intended. Sorry if that is the > case and I will try and make amends now. > > I appreciate that this is not really your area, so you must feel pretty > concerned to step in like this, so I really hope that I can set your mind > at ease here. > > I think that you have picked out a very useful part of the thread. I would > absolutely love to have some better tools that allowed me to quickly spot > patterns and anomalies amongst all the hundreds of patches flowing through > the system. The current mechanisms are a little crude and definitely not > intuitive. There is also a lack of metrics for us to track our > effectiveness over time. > > Ultimately, though, such a system is simply a tool to help us improve the > patch landing process itself. It will enable us to identify patches where > things are not running smoothly for whatever reason, review them, and take > corrective action. It is by this iterative process that will help us > improve over time. > > My concern is that I do not want us to wait until we have an improved > tracking system in place before we start other improvements to our > processes. While not needing to dwell on the specifics of the tickets, my > takeaway was that there was low hanging fruit in this area across the > board, so I think that it illustrates the value of using the options at > our disposal today to improve things in parallel to any longer-term > initiative to have a more automated mechanism in place. > > John Forgan of Xyratex sent out some filters which could generate some > possible candidates for discussion and, to my mind, each individual > engineer has a more manageable number of patches that they authored and > know intimately and so should be able to flag situations where closer > attention seems warranted. > > Discussing such matters has been a long-standing - but rarely used - > function of the CDWG and I really think that we would all benefit from > taking better advantage of this. > > I hope that this clarifies things for you. If not, then please feel free > to call me and let's talk this over or, of course, we can talk about this > on next week's CDWG call. > > Regards > > Peter > > On 8/8/13 10:08 PM, "Jones, Peter A" wrote: > >> Hi Kevin >> >> I did understand what Denis was proposing and my only objection to it was >> that it would take time to set this up and I personally feel that this >> time could be better spent elsewhere. >> >> I think that it is perfectly healthy to discuss this and I do not think >> that you should feel threatened by such dialog. >> >> In my view, this thread has been quite productive in that Denis has had a >> flawed assumption clarified. >> >> From what I have seen of Denis's work, I would expect him to respond to >> that in a positive manner. >> >> Regards >> >> Peter >> >> On 8/8/13 7:44 PM, "Kevin Canady" wrote: >> >>> Chris, >>> Peter and you continue to miss the main point Denis was making. There >>> never was any implication of animosity, so no need to be defensive or >>> stir such topic. There is no conflict. Somehow, and quite >>> unfortunately, this thread continues to be stuck on the defense of >>> specific patch activity when the main point that was being made was… >>> >>>>> Those tickets are probably all have good explanation why. >>>>> My suggestion was to build process, that will resolve such issues >>>>> automatically and will provide us stat and info about Sustaining review >>>>> activities. >>>>> What I don't want is to do it manually. >>>>> >>>>> What we propose is to define all stages of Sustaining process to >>>>> gather all needed info to understand where we have most problems: >>>>> * review resources >>>>> * incorrect test failures >>>>> * rebases >>>>> * code freeze >>>>> * some other… >>>>> >>>>> Process for all, not just Xyratex, but for all reviews. >>>>> >>>>> That will give us more visibility and possibility to improve. >>>>> We are not saint and we need to improve too. We have issues with >>>>> upstream submission too and there are no fault here in this discussion. >>>>> >>>>> Right now we know that only based on our experience in our heads, >>>>> intuitively. >>>>> >>>>> Of course we could use any suggestions. If we all think that just >>>>> e-mail with list will resolve this situation - we will use that. >>>>> >>>>> I just started this topic to share our process that could be useful, >>>>> and gather other feedbacks - what could be done. >>> >>> It would be extremely helpful if we can remain centered on these >>> discussions to make this a productive dialog. >>> >>> Kevin >>> >>> On Aug 8, 2013, at 6:14 PM, Christopher J. Morrone >>> wrote: >>> >>>> On 08/08/2013 09:06 AM, Denis Kondratenko wrote: >>>>> That how this hole thread was started - we do want to do this under >>>>> CDWG and just searching right way to do it. >>>> >>>> Great! >>>> >>>> I believe the right way to do it is for the patch submitter to keep >>>> track of his/her submissions. If a submitted patch needs attention, >>>> they should raise the issue in the associated Jira ticket. I find that >>>> often just a friendly reminder is all it takes to get attention on a >>>> patch, or an explanation of why the patch needs to wait. >>>> >>>> If that does not solve the problem, the next step is to raise the issue >>>> on the CDWG mailing list. List the specific patch(es) that you think >>>> need attention. We will discuss and come to a decision together. >>>> >>>> Lets try it out with the list that you supplied: >>>> >>>>>> http://review.whamcloud.com/#/c/3553/ >>>> >>>> Landed on master, August 6, 2013. >>>> No action needed. >>>> >>>>>> http://review.whamcloud.com/#/c/3277/ >>>> >>>> Landed on master, June 21, 2013. >>>> No action needed. >>>> >>>>>> http://review.whamcloud.com/#/c/5213/ >>>> >>>> -1 code review from Andreas, 30 inline comments. >>>> Waiting on Xyratex to fix and push next version for review. >>>> >>>>>> http://review.whamcloud.com/#/c/4372/ >>>> >>>> Landed on master, June 13, 2013. >>>> No action needed. >>>> >>>>>> http://review.whamcloud.com/#/c/4641/ >>>> >>>> Landed on b2_1, May 20, 2013. >>>> Out of scope for OpenSFS "tree contract", but nevertheless, no action >>>> needed. >>>> >>>>>> http://review.whamcloud.com/#/c/4664/ >>>> >>>> This is probably a good example of one that has sat a while. We could >>>> chat about what happened here. If you go to the associated jira ticket: >>>> >>>> https://jira.hpdd.intel.com/browse/LU-2377 >>>> >>>> it seems clear to me that Intel's opinion was that upstream ext4 was a >>>> more appropriate place for this patch than carrying it in the ldiskfs >>>> patch stack. >>>> >>>> Conversation between Xyratex and Intel looks like it went nicely. >>>> >>>> Did Xyratex follow through with sending this patch to the upstream ext4 >>>> developers? >>>> >>>>>> http://review.whamcloud.com/#/c/3725/ >>>> >>>> Patch is for b2_2. There are no community endorsed b2_2 maintenance >>>> releases. No action should be expected on this patch. >>>> >>>> If this is a problem that still exists on master, Xyratex should submit >>>> a patch to master. >>>> >>>>>> http://review.whamcloud.com/#/c/2406/ >>>> >>>> Patch is for b1_8. There are no longer any community endorsed b1_8 >>>> maintenance releases (some Lustre vendors offer their customers >>>> maintenance releases as they see fit). No action should be expected on >>>> this patch. >>>> >>>> ----- >>>> >>>> That is how I would envision the process going in the future. When >>>> developer feels that a patch isn't making enough progress, and didn't >>>> get an adequate explanation in Jira, they raise here with the CDWG. I >>>> will look it over as Technical Representative on the tree contract, >>>> along with anyone else in the CDWG that wants to contribute. >>>> >>>> Together with the interested party and Intel, we will decide on the >>>> needed course of action. >>>> >>>>> Again, I don't want to start any war or discussion about those >>>> tickets, or about some other. >>>>> I don't want to blame anyone about something. But for me obviously >>>> some problems exit. >>>> >>>> Ok, maybe those patches are not the right ones to discuss. But you >>>> really should start discussions about patches that are currently a >>>> problem. Bringing a problem to our attention should not be the start of >>>> a war. It should be the start of a discussion, which will result in a >>>> plan of action, which will guide us to a solution. >>>> >>>> Chris >>>> >>>> >>>>>> http://review.whamcloud.com/#/c/3553/ >>>>>> http://review.whamcloud.com/#/c/3277/ >>>>>> http://review.whamcloud.com/#/c/5213/ >>>>>> http://review.whamcloud.com/#/c/4372/ >>>>>> http://review.whamcloud.com/#/c/4641/ >>>>>> http://review.whamcloud.com/#/c/4664/ >>>>>> http://review.whamcloud.com/#/c/3725/ >>>>>> http://review.whamcloud.com/#/c/2406/ >>>>>> >>>>>> Again, I don't want to start any war or discussion about those >>>>>> tickets, or about some other. >>>>>> I don't want to blame anyone about something. But for me obviously >>>>>> some problems exit. >>>>>> >>>>>> Those tickets are probably all have good explanation why. >>>>>> My suggestion was to build process, that will resolve such issues >>>>>> automatically and will provide us stat and info about Sustaining >>>>>> review activities. >>>>>> What I don't want is to do it manually. >>>>>> >>>>>> What we propose is to define all stages of Sustaining process to >>>>>> gather all needed info to understand where we have most problems: >>>>>> * review resources >>>>>> * incorrect test failures >>>>>> * rebases >>>>>> * code freeze >>>>>> * some other… >>>>>> >>>>>> Process for all, not just Xyratex, but for all reviews. >>>>>> >>>>>> That will give us more visibility and possibility to improve. >>>>>> We are not saint and we need to improve too. We have issues with >>>>>> upstream submission too and there are no fault here in this >>>>>> discussion. >>>>>> >>>>>> Right now we know that only based on our experience in our heads, >>>>>> intuitively. >>>>>> >>>>>> Of course we could use any suggestions. If we all think that just >>>>>> e-mail with list will resolve this situation - we will use that. >>>>>> >>>>>> I just started this topic to share our process that could be useful, >>>>>> and gather other feedbacks - what could be done. >>>>>> >>>>>> Thanks, >>>>>> Denis >>>>>> >>>>>> On 7 авг. 2013, at 19:07, "Jones, Peter A" >>>>>> > wrote: >>>>>> >>>>>> Thanks Denis I would appreciate it. I absolutely agree that this >>>>>> needs to >>>>>> be an iterative process and that we need data to analyze and improve. >>>>>> >>>>>> The last time this concern was raised (just before ISC) I did >>>>>> complete an >>>>>> analysis of every single Xyratex patch submitted against master and >>>>>> (other >>>>>> than a couple of feature patches that had been delayed by the 2.4 >>>>>> feature >>>>>> freeze) the longest wait that I saw at that time was only a few >>>>>> weeks. >>>>>> >>>>>> Xyratex committed at that time to provide a consolidated list of >>>>>> issues >>>>>> that are a concern. I suggest that we focus on that as a first step >>>>>> before >>>>>> getting into possible process changes so that we can be sure that our >>>>>> process reflects the actual situation. >>>>>> >>>>>> >>>>>> On 8/7/13 8:11 AM, "Denis Kondratenko" >>>>>> > >>>>>> wrote: >>>>>> >>>>>> OK, I will go and try to search. >>>>>> >>>>>> Maybe I have overestimated that, my apologize for that - will provide >>>>>> you >>>>>> numbers and examples. >>>>>> Point wasn't in that. >>>>>> >>>>>> Point was - we have no numbers - so nothing to analyze and improve. >>>>>> >>>>>> Thanks, >>>>>> Denis >>>>>> >>>>>> On 7 авг. 2013, at 18:03, "Jones, Peter A" >>>>>> > >>>>>> wrote: >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> It is not a rare occurrence - patches that were submitted 6-12 months >>>>>> after it was first pushed for review. >>>>>> >>>>>> Denis, please give me three examples where patches pushed to master >>>>>> have >>>>>> waited 6-12 months after being pushed for review? >>>>>> >>>>>> I take this very seriously. >>>>>> >>>>>> There are certainly busy times when lower priority patches might need >>>>>> to >>>>>> wait but I have not seen anything that long. >>>>>> >>>>>> Feature patches submitted during the feature freeze, but that is >>>>>> usually >>>>>> more like 3-4 months in the worst case scenario. >>>>>> >>>>>> Sometimes people push patches against maintenance branches, which can >>>>>> be >>>>>> useful for the community but if these land it will only be at the >>>>>> time >>>>>> we >>>>>> create a maintenance release against that branch. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> >>>>>> >>>>>> ------------------------------ >>>>>> For additional information including the registered office and the >>>>>> treatment of Xyratex confidential information please visit >>>>>> www.xyratex.com >>>>>> >>>>>> ------------------------------ >>>>>> _______________________________________________ >>>>>> cdwg mailing list >>>>>> cdwg at lists.opensfs.org >>>>>> http://lists.opensfs.org/listinfo.cgi/cdwg-opensfs.org >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> ________________________________ >>>>>> For additional information including the registered office and the >>>>>> treatment of Xyratex confidential information please visit >>>>>> www.xyratex.com >>>>>> >>>>>> ________________________________ >>>>> >>>>> >>>> >>>> _______________________________________________ >>>> cdwg mailing list >>>> cdwg at lists.opensfs.org >>>> http://lists.opensfs.org/listinfo.cgi/cdwg-opensfs.org >>> >>> _______________________________________________ >>> cdwg mailing list >>> cdwg at lists.opensfs.org >>> http://lists.opensfs.org/listinfo.cgi/cdwg-opensfs.org >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From morrone2 at llnl.gov Fri Aug 9 17:51:41 2013 From: morrone2 at llnl.gov (Christopher J. Morrone) Date: Fri, 09 Aug 2013 10:51:41 -0700 Subject: [cdwg] Monitoring Ticket Progress In-Reply-To: <6C16DA71-D062-44AE-BC4D-766F0150C82B@xyratex.com> References: <5204428F.3090808@llnl.gov> <6C16DA71-D062-44AE-BC4D-766F0150C82B@xyratex.com> Message-ID: <52052C2D.2050004@llnl.gov> Kevin, I'm not sure what I said in the email to which you replied to make you believe that I missed Denis's point. I have been entirely in favor of Denis's discussion about tools and process improvment. I was in such complete agreement with Denis about the needed gerrit filter improvements that I myself went and created LU-3690* so that we don't lose track of that task. Chris * https://jira.hpdd.intel.com/browse/LU-3690 On 08/08/2013 07:44 PM, Kevin Canady wrote: > Chris, > Peter and you continue to miss the main point Denis was making. There never was any implication of animosity, so no need to be defensive or stir such topic. There is no conflict. Somehow, and quite unfortunately, this thread continues to be stuck on the defense of specific patch activity when the main point that was being made was… > >>> Those tickets are probably all have good explanation why. >>> My suggestion was to build process, that will resolve such issues automatically and will provide us stat and info about Sustaining review activities. >>> What I don't want is to do it manually. >>> >>> What we propose is to define all stages of Sustaining process to gather all needed info to understand where we have most problems: >>> * review resources >>> * incorrect test failures >>> * rebases >>> * code freeze >>> * some other… >>> >>> Process for all, not just Xyratex, but for all reviews. >>> >>> That will give us more visibility and possibility to improve. >>> We are not saint and we need to improve too. We have issues with upstream submission too and there are no fault here in this discussion. >>> >>> Right now we know that only based on our experience in our heads, intuitively. >>> >>> Of course we could use any suggestions. If we all think that just e-mail with list will resolve this situation - we will use that. >>> >>> I just started this topic to share our process that could be useful, and gather other feedbacks - what could be done. > > It would be extremely helpful if we can remain centered on these discussions to make this a productive dialog. > > Kevin > > On Aug 8, 2013, at 6:14 PM, Christopher J. Morrone wrote: > >> On 08/08/2013 09:06 AM, Denis Kondratenko wrote: >>> That how this hole thread was started - we do want to do this under CDWG and just searching right way to do it. >> >> Great! >> >> I believe the right way to do it is for the patch submitter to keep track of his/her submissions. If a submitted patch needs attention, they should raise the issue in the associated Jira ticket. I find that often just a friendly reminder is all it takes to get attention on a patch, or an explanation of why the patch needs to wait. >> >> If that does not solve the problem, the next step is to raise the issue on the CDWG mailing list. List the specific patch(es) that you think need attention. We will discuss and come to a decision together. >> >> Lets try it out with the list that you supplied: >> >>>> http://review.whamcloud.com/#/c/3553/ >> >> Landed on master, August 6, 2013. >> No action needed. >> >>>> http://review.whamcloud.com/#/c/3277/ >> >> Landed on master, June 21, 2013. >> No action needed. >> >>>> http://review.whamcloud.com/#/c/5213/ >> >> -1 code review from Andreas, 30 inline comments. >> Waiting on Xyratex to fix and push next version for review. >> >>>> http://review.whamcloud.com/#/c/4372/ >> >> Landed on master, June 13, 2013. >> No action needed. >> >>>> http://review.whamcloud.com/#/c/4641/ >> >> Landed on b2_1, May 20, 2013. >> Out of scope for OpenSFS "tree contract", but nevertheless, no action needed. >> >>>> http://review.whamcloud.com/#/c/4664/ >> >> This is probably a good example of one that has sat a while. We could chat about what happened here. If you go to the associated jira ticket: >> >> https://jira.hpdd.intel.com/browse/LU-2377 >> >> it seems clear to me that Intel's opinion was that upstream ext4 was a more appropriate place for this patch than carrying it in the ldiskfs patch stack. >> >> Conversation between Xyratex and Intel looks like it went nicely. >> >> Did Xyratex follow through with sending this patch to the upstream ext4 developers? >> >>>> http://review.whamcloud.com/#/c/3725/ >> >> Patch is for b2_2. There are no community endorsed b2_2 maintenance releases. No action should be expected on this patch. >> >> If this is a problem that still exists on master, Xyratex should submit a patch to master. >> >>>> http://review.whamcloud.com/#/c/2406/ >> >> Patch is for b1_8. There are no longer any community endorsed b1_8 maintenance releases (some Lustre vendors offer their customers maintenance releases as they see fit). No action should be expected on this patch. >> >> ----- >> >> That is how I would envision the process going in the future. When developer feels that a patch isn't making enough progress, and didn't get an adequate explanation in Jira, they raise here with the CDWG. I will look it over as Technical Representative on the tree contract, along with anyone else in the CDWG that wants to contribute. >> >> Together with the interested party and Intel, we will decide on the needed course of action. >> >>> Again, I don't want to start any war or discussion about those tickets, or about some other. >>> I don't want to blame anyone about something. But for me obviously some problems exit. >> >> Ok, maybe those patches are not the right ones to discuss. But you really should start discussions about patches that are currently a problem. Bringing a problem to our attention should not be the start of a war. It should be the start of a discussion, which will result in a plan of action, which will guide us to a solution. >> >> Chris >> >> >>>> http://review.whamcloud.com/#/c/3553/ >>>> http://review.whamcloud.com/#/c/3277/ >>>> http://review.whamcloud.com/#/c/5213/ >>>> http://review.whamcloud.com/#/c/4372/ >>>> http://review.whamcloud.com/#/c/4641/ >>>> http://review.whamcloud.com/#/c/4664/ >>>> http://review.whamcloud.com/#/c/3725/ >>>> http://review.whamcloud.com/#/c/2406/ >>>> >>>> Again, I don't want to start any war or discussion about those tickets, or about some other. >>>> I don't want to blame anyone about something. But for me obviously some problems exit. >>>> >>>> Those tickets are probably all have good explanation why. >>>> My suggestion was to build process, that will resolve such issues automatically and will provide us stat and info about Sustaining review activities. >>>> What I don't want is to do it manually. >>>> >>>> What we propose is to define all stages of Sustaining process to gather all needed info to understand where we have most problems: >>>> * review resources >>>> * incorrect test failures >>>> * rebases >>>> * code freeze >>>> * some other… >>>> >>>> Process for all, not just Xyratex, but for all reviews. >>>> >>>> That will give us more visibility and possibility to improve. >>>> We are not saint and we need to improve too. We have issues with upstream submission too and there are no fault here in this discussion. >>>> >>>> Right now we know that only based on our experience in our heads, intuitively. >>>> >>>> Of course we could use any suggestions. If we all think that just e-mail with list will resolve this situation - we will use that. >>>> >>>> I just started this topic to share our process that could be useful, and gather other feedbacks - what could be done. >>>> >>>> Thanks, >>>> Denis >>>> >>>> On 7 авг. 2013, at 19:07, "Jones, Peter A" > wrote: >>>> >>>> Thanks Denis I would appreciate it. I absolutely agree that this needs to >>>> be an iterative process and that we need data to analyze and improve. >>>> >>>> The last time this concern was raised (just before ISC) I did complete an >>>> analysis of every single Xyratex patch submitted against master and (other >>>> than a couple of feature patches that had been delayed by the 2.4 feature >>>> freeze) the longest wait that I saw at that time was only a few weeks. >>>> >>>> Xyratex committed at that time to provide a consolidated list of issues >>>> that are a concern. I suggest that we focus on that as a first step before >>>> getting into possible process changes so that we can be sure that our >>>> process reflects the actual situation. >>>> >>>> >>>> On 8/7/13 8:11 AM, "Denis Kondratenko" > >>>> wrote: >>>> >>>> OK, I will go and try to search. >>>> >>>> Maybe I have overestimated that, my apologize for that - will provide you >>>> numbers and examples. >>>> Point wasn't in that. >>>> >>>> Point was - we have no numbers - so nothing to analyze and improve. >>>> >>>> Thanks, >>>> Denis >>>> >>>> On 7 авг. 2013, at 18:03, "Jones, Peter A" > >>>> wrote: >>>> >>>> >>>> >>>> >>>> It is not a rare occurrence - patches that were submitted 6-12 months >>>> after it was first pushed for review. >>>> >>>> Denis, please give me three examples where patches pushed to master have >>>> waited 6-12 months after being pushed for review? >>>> >>>> I take this very seriously. >>>> >>>> There are certainly busy times when lower priority patches might need to >>>> wait but I have not seen anything that long. >>>> >>>> Feature patches submitted during the feature freeze, but that is usually >>>> more like 3-4 months in the worst case scenario. >>>> >>>> Sometimes people push patches against maintenance branches, which can be >>>> useful for the community but if these land it will only be at the time >>>> we >>>> create a maintenance release against that branch. >>>> >>>> >>>> >>>> >>>> -- >>>> >>>> >>>> ------------------------------ >>>> For additional information including the registered office and the >>>> treatment of Xyratex confidential information please visit www.xyratex.com >>>> >>>> ------------------------------ >>>> _______________________________________________ >>>> cdwg mailing list >>>> cdwg at lists.opensfs.org >>>> http://lists.opensfs.org/listinfo.cgi/cdwg-opensfs.org >>>> >>>> >>>> >>>> >>>> ________________________________ >>>> For additional information including the registered office and the treatment of Xyratex confidential information please visit www.xyratex.com >>>> >>>> ________________________________ >>> >>> >> >> _______________________________________________ >> cdwg mailing list >> cdwg at lists.opensfs.org >> http://lists.opensfs.org/listinfo.cgi/cdwg-opensfs.org > > . > From peter.a.jones at intel.com Fri Aug 9 20:28:04 2013 From: peter.a.jones at intel.com (Jones, Peter A) Date: Fri, 9 Aug 2013 20:28:04 +0000 Subject: [cdwg] Lustre 2.5 update - August 2nd 2013 In-Reply-To: Message-ID: Just to close the loop on this – I'm afraid that it took a little longer than expected, but these patches are now all landed to master and HSM is feature complete for 2.5. Thanks to CEA for this exciting contribution to Lustre! Now we are officially in the Stabilization period for Lustre 2.5 and the focus will be on testing and bufixing between now and GA (targeted for the end of October) On 8/2/13 5:27 PM, "Jones, Peter A" > wrote: HSM (LU-3608) There is still some remaining work for this to be feature complete. As per the discussion on the CDWG call on Wednesday we are going to see we have extended the landing window for these patches only in view of the high interest in this feature and the belief that this work is close to completion. I will send out another update early next week with the final outcome on this. * POSIX Copy tool http://review.whamcloud.com/#/c/4737/ * Disaster Recovery http://review.whamcloud.com/#/c/7027/ * Coordinator http://review.whamcloud.com/#/c/6912/ From aik at fnal.gov Fri Aug 9 20:54:46 2013 From: aik at fnal.gov (Alex Kulyavtsev) Date: Fri, 9 Aug 2013 15:54:46 -0500 Subject: [cdwg] lustre 1.8.x releases Re: Monitoring Ticket Progress In-Reply-To: <5204428F.3090808@llnl.gov> References: <5204428F.3090808@llnl.gov> Message-ID: Is there end of maintenance releases announced for 1.8.x branch? When is it going to happen if so? Alex On Aug 8, 2013, at 8:14 PM, Christopher J. Morrone wrote: > There are no longer any community endorsed b1_8 > maintenance releases (some Lustre vendors offer their customers > maintenance releases as they see fit). -------------- next part -------------- An HTML attachment was scrubbed... URL: From peter.a.jones at intel.com Fri Aug 9 21:07:58 2013 From: peter.a.jones at intel.com (Jones, Peter A) Date: Fri, 9 Aug 2013 21:07:58 +0000 Subject: [cdwg] lustre 1.8.x releases Re: Monitoring Ticket Progress In-Reply-To: Message-ID: Speaking on behalf of Intel, while we do not have specific plans for another 1.8.x release at the moment, it is quite probable we will release a 1.8.10-wc1 at some point. We still have many customers running our 1.8.x releases. What Chris is referring to below is that the CDWG focuses on active 2.x code lines, rather than historic code lines that support vendors need to maintain for their customerbase. On 8/9/13 1:54 PM, "Alex Kulyavtsev" > wrote: Is there end of maintenance releases announced for 1.8.x branch? When is it going to happen if so? Alex On Aug 8, 2013, at 8:14 PM, Christopher J. Morrone wrote: There are no longer any community endorsed b1_8 maintenance releases (some Lustre vendors offer their customers maintenance releases as they see fit). From aik at fnal.gov Fri Aug 9 21:37:47 2013 From: aik at fnal.gov (Alex Kulyavtsev) Date: Fri, 9 Aug 2013 16:37:47 -0500 Subject: [cdwg] lustre 1.8.x releases In-Reply-To: References: Message-ID: <0352B36E-519E-46D3-A82A-4D3D18B04961@fnal.gov> 1.8.10 or 1.8.9.1 bug fix will be helpful as LBUG on assertion() was introduced in 1.8.9 (see LU-3067). I'm looking to downgrade. Alex. On Aug 9, 2013, at 4:07 PM, Jones, Peter A wrote: > Speaking on behalf of Intel, while we do not have specific plans for another 1.8.x release at the moment, it is quite probable we will release a 1.8.10-wc1 at some point. We still have many customers running our 1.8.x releases. What Chris is referring to below is that the CDWG focuses on active 2.x code lines, rather than historic code lines that support vendors need to maintain for their customerbase. > > On 8/9/13 1:54 PM, "Alex Kulyavtsev" > wrote: > > Is there end of maintenance releases announced for 1.8.x branch? > When is it going to happen if so? > Alex -------------- next part -------------- An HTML attachment was scrubbed... URL: From peter.a.jones at intel.com Fri Aug 9 21:45:59 2013 From: peter.a.jones at intel.com (Jones, Peter A) Date: Fri, 9 Aug 2013 21:45:59 +0000 Subject: [cdwg] lustre 1.8.x releases In-Reply-To: <0352B36E-519E-46D3-A82A-4D3D18B04961@fnal.gov> Message-ID: Yes. This issue would certainly be addressed in a 1.8.10-wc1 release. In the meantime, there is a patch available. On 8/9/13 2:37 PM, "Alex Kulyavtsev" > wrote: 1.8.10 or 1.8.9.1 bug fix will be helpful as LBUG on assertion() was introduced in 1.8.9 (see LU-3067). I'm looking to downgrade. Alex. On Aug 9, 2013, at 4:07 PM, Jones, Peter A wrote: Speaking on behalf of Intel, while we do not have specific plans for another 1.8.x release at the moment, it is quite probable we will release a 1.8.10-wc1 at some point. We still have many customers running our 1.8.x releases. What Chris is referring to below is that the CDWG focuses on active 2.x code lines, rather than historic code lines that support vendors need to maintain for their customerbase. On 8/9/13 1:54 PM, "Alex Kulyavtsev" > wrote: Is there end of maintenance releases announced for 1.8.x branch? When is it going to happen if so? Alex From oleg.drokin at intel.com Sat Aug 10 04:49:33 2013 From: oleg.drokin at intel.com (Drokin, Oleg) Date: Sat, 10 Aug 2013 04:49:33 +0000 Subject: [cdwg] new master tag 2.4.90 Message-ID: <0D7F7339-9592-4992-BB46-916BE0DEEFA8@intel.com> Hello! Now that we are fully in feature-freeze zone, I just cut a 2.4.90 tag in the master branch. Bye, Oleg From morrone2 at llnl.gov Tue Aug 13 20:06:44 2013 From: morrone2 at llnl.gov (Christopher J. Morrone) Date: Tue, 13 Aug 2013 13:06:44 -0700 Subject: [cdwg] OpenSFS CDWG Call Message-ID: <520A91D4.5000708@llnl.gov> Hi all, This is a reminder that we will have a Community Development Working Group (CDWG) call on Wednesday, August, at 9:00am PDT. Agenda: * Review Action Items from last meeting * 2.5.0 development update (celebrate HSM landing/feature freeze) * Discuss what do to about the time it takes to land patches If you have any additional agenda items, please suggest them before the call. Call-in: 866-914-3976 (925-424-8105) Passcode: 534986# Regards, Chris From morrone2 at llnl.gov Wed Aug 14 23:21:07 2013 From: morrone2 at llnl.gov (Christopher J. Morrone) Date: Wed, 14 Aug 2013 16:21:07 -0700 Subject: [cdwg] Draft of updated roadmap slide Message-ID: <520C10E3.7030405@llnl.gov> Hi folks, Attached is a draft of an updated Lustre Roadmap slide. I made it a jpg to save space in email, but the final on the web will be png so it won't have all of those compression artifacts. Let me know if you spot anything that needs correction. I am running out of time today, so I will have to delay the draft of the 2.5 "scheduled maintenance branch" announcement until tomorrow. Chris -------------- next part -------------- A non-text attachment was scrubbed... Name: CommunityLustreRoadmap_2013-08-13.jpg Type: image/jpeg Size: 165653 bytes Desc: not available URL: From morrone2 at llnl.gov Fri Aug 16 01:08:23 2013 From: morrone2 at llnl.gov (Christopher J. Morrone) Date: Thu, 15 Aug 2013 18:08:23 -0700 Subject: [cdwg] Draft of updated roadmap slide In-Reply-To: <520C10E3.7030405@llnl.gov> References: <520C10E3.7030405@llnl.gov> Message-ID: <520D7B87.1010701@llnl.gov> With no objections, the web page has been updated with the new roadmap slide that I proposed: http://lustre.opensfs.org/community-lustre-roadmap/ The next step is a public announcement about the 2.4->2.5 change. here is my first draft. Please comment and suggest improvements. I will plan to blast this announcement to various mailing lists by the end of my day on Monday, August 19th. Subject: Community Roadmap update, Realignment on 2.5 Background ---------- The Lustre community has banded together to work on the development of the Lustre source code. As part of that effort, we regularly discuss the roadmap for major Lustre releases. We have developed a schedule of major releases that occur every six months. We recognize, however, that many organizations need a branch of Lustre that they can run for much longer periods of time than six months. To that end we collectively decided that we would target the Lustre 2.4.0 feature release to begin a side branch of Lustre to receive regularly scheduled maintenance releases for a significant period of time (18 months or more). Unfortunately, one particular feature that some folks feel strongly is an absolute requirement in the next scheduled maintenance release branch was not completed in time for Lustre 2.4.0. Happy, that feature has landed on the master branch, and will appear in the next Lustre feature release 2.5.0. Rather than split the community effort between two closely spaced scheduled maintenance release branches, we have decided to realign our efforts from the 2.4 branch to the 2.5 branch. An updated Community Lustre Roadmap has been posted here: http://lustre.opensfs.org/community-lustre-roadmap/ What this means in a Nutshell ----------------------------- The Lustre 2.5 branch is the one for which we expect to see regularly scheduled maintenance release for an extended period of time (18+ months). We no longer expect regularly scheduled maintenance releases on the Lustre 2.4 branch after Lustre 2.4.2 release. Our recommended upgrade path after 2.4.2 is to the latest 2.5.X release. What to do if you are already committed to Lustre 2.4 ----------------------------------------------------- If you have already committed to using Lustre 2.4 at your organization and an upgrade to Lustre 2.5 is not either desired or possible, we recommend that you contact your Lustre support vendor to find out which branches they intend to support. Some Lustre vendors offer support for branches beyond the Community's officially recommended releases. Some Lustre vendors have already announced their intent to continue supporting their users who have committed to the Lustre 2.4 branch. Chris On 08/14/2013 04:21 PM, Christopher J. Morrone wrote: > Hi folks, > > Attached is a draft of an updated Lustre Roadmap slide. I made it a jpg > to save space in email, but the final on the web will be png so it won't > have all of those compression artifacts. > > Let me know if you spot anything that needs correction. > > I am running out of time today, so I will have to delay the draft of the > 2.5 "scheduled maintenance branch" announcement until tomorrow. > > Chris From peter.a.jones at intel.com Fri Aug 16 13:04:41 2013 From: peter.a.jones at intel.com (Jones, Peter A) Date: Fri, 16 Aug 2013 13:04:41 +0000 Subject: [cdwg] Draft of updated roadmap slide In-Reply-To: <520D7B87.1010701@llnl.gov> Message-ID: Overall I think that you have captured the key points well, but I am unclear as to why you do not explicitly mention HSM by name in this paragraph. I also think that "Happily" rather than "Happy" would be more appropriate choice of word. On 8/15/13 6:08 PM, "Christopher J. Morrone" wrote: >Unfortunately, one particular feature that some folks feel strongly is >an absolute requirement in the next scheduled maintenance release branch >was not completed in time for Lustre 2.4.0. Happy, that feature has >landed on the master branch, and will appear in the next Lustre feature >release 2.5.0. From peter.a.jones at intel.com Fri Aug 16 16:40:09 2013 From: peter.a.jones at intel.com (Jones, Peter A) Date: Fri, 16 Aug 2013 16:40:09 +0000 Subject: [cdwg] Lustre 2.5 update - August 16th 2013 Message-ID: Hi there Here is an update on the Lustre 2.5 release. Landings ======== -A number of landings made - see http://git.whamcloud.com/?p=fs/lustre-release.git;a=shortlog;h=refs/heads/master -Further to the final HSM feature patches landed last week, the HSM test script has now landed (LU-3561) Testing ======= - Testing on the 2.4.53 tag is complete; testing on the 2.4.90 tag is ongoing (the bump in tag numbers is to indicate feature freeze has passed) Blockers ======== -Full list available at https://jira.hpdd.intel.com/issues/?jql=project%20%3D%20LU%20AND%20fixVersion%20%3D%20%22Lustre%202.5.0%22%20AND%20resolution%20%3D%20Unresolved%20AND%20priority%20%3D%20Blocker%20ORDER%20BY%20key%20DESC -If there are any issues not presently marked as blockers that you believe should be, please let me know Other ===== -We are trialling using the Fix In Release field for the 2.5 release to track work hoped to be included in the release; this means that a fuller picture of the progress on the release can be viewed at https://jira.hpdd.intel.com/browse/LU/fixforversion/10295#selectedTab=com.atlassian.jira.plugin.system.project%3Aversion-issues-panel -Feature Freeze is now in effect and 2.5 has entered its stabilization period. We encourage community members to test out the latest code on master and to use JIRA (https://jira.hpdd.intel.com) to report any bugs encountered -You can also keep up to date with matters relating to the 2.5 release on the CDWG wiki - http://wiki.opensfs.org/Lustre_2.5.0 Thanks Peter From morrone2 at llnl.gov Fri Aug 16 21:12:12 2013 From: morrone2 at llnl.gov (Christopher J. Morrone) Date: Fri, 16 Aug 2013 14:12:12 -0700 Subject: [cdwg] Draft of updated roadmap slide In-Reply-To: References: Message-ID: <520E95AC.60100@llnl.gov> On 08/16/2013 06:04 AM, Jones, Peter A wrote: > I also think that "Happily" rather than "Happy" would be more > appropriate choice of word. Yes, that is a mistake, thanks for catching that. From kevin_canady at xyratex.com Mon Aug 19 18:50:39 2013 From: kevin_canady at xyratex.com (Kevin Canady) Date: Mon, 19 Aug 2013 11:50:39 -0700 Subject: [cdwg] Anyone having issues getting to Lustre sites? Message-ID: Outside of OpenSFS and Lustre.org, the other sites look to be down? Anyone know what's up? Thanks, Kevin P. Kevin Canady Director, Business Development Lustre and HPC Services kevin_canady at xyratex.com O: 510-687-5475 C: 415.505.7701 (best) -------------- next part -------------- An HTML attachment was scrubbed... URL: From peter.a.jones at intel.com Mon Aug 19 18:56:12 2013 From: peter.a.jones at intel.com (Jones, Peter A) Date: Mon, 19 Aug 2013 18:56:12 +0000 Subject: [cdwg] Anyone having issues getting to Lustre sites? In-Reply-To: Message-ID: Hi Kevin There seems to be a problem affecting a number of Intel-hosted sites including ours. We have reported the problem and hope to have it resolved asap. Regards Peter On 8/19/13 11:50 AM, "Kevin Canady" > wrote: Outside of OpenSFS and Lustre.org, the other sites look to be down? Anyone know what's up? Thanks, Kevin P. Kevin Canady Director, Business Development Lustre and HPC Services kevin_canady at xyratex.com O: 510-687-5475 C: 415.505.7701 (best) From kevin_canady at xyratex.com Mon Aug 19 19:02:11 2013 From: kevin_canady at xyratex.com (Kevin Canady) Date: Mon, 19 Aug 2013 12:02:11 -0700 Subject: [cdwg] Anyone having issues getting to Lustre sites? In-Reply-To: References: Message-ID: Grrrr gremlins! Thanks Peter, appreciate any updates you can provide. Kevin On Aug 19, 2013, at 11:56 AM, "Jones, Peter A" wrote: > Hi Kevin > > There seems to be a problem affecting a number of Intel-hosted sites including ours. We have reported the problem and hope to have it resolved asap. > > Regards > > Peter > > On 8/19/13 11:50 AM, "Kevin Canady" > wrote: > > Outside of OpenSFS and Lustre.org, the other sites look to be down? > > Anyone know what's up? > > Thanks, > Kevin > > P. Kevin Canady > Director, Business Development Lustre and HPC Services > kevin_canady at xyratex.com > O: 510-687-5475 > C: 415.505.7701 (best) > > > From morrone2 at llnl.gov Tue Aug 20 01:01:39 2013 From: morrone2 at llnl.gov (Christopher J. Morrone) Date: Mon, 19 Aug 2013 18:01:39 -0700 Subject: [cdwg] Community Roadmap Update, Realignment on 2.5 In-Reply-To: <520C10E3.7030405@llnl.gov> References: <520C10E3.7030405@llnl.gov> Message-ID: <5212BFF3.7000002@llnl.gov> Background ---------- The Lustre community has banded together to work on the development of the Lustre source code. As part of that effort, we regularly discuss the roadmap for major Lustre releases. We have developed a schedule of major releases that occur every six months. We recognize, however, that many organizations need a branch of Lustre that they can run for much longer periods of time than six months. To that end we collectively decided that we would target the Lustre 2.4.0 feature release to begin a side branch of Lustre to receive regularly scheduled maintenance releases for a significant period of time (18 months or more). Unfortunately, one particular feature that some folks feel strongly is an absolute requirement, HSM (Hierarchical Storage Management), did not land on the development branch in time for Lustre 2.4.0. Happily HSM is now landed on the master branch, and will appear in the next Lustre feature release, version 2.5.0. Rather than split the community effort between two closely spaced scheduled maintenance release branches, we have decided to realign our efforts from the 2.4 branch to the 2.5 branch. An updated Community Lustre Roadmap has been posted here: http://lustre.opensfs.org/community-lustre-roadmap/ What this means in a Nutshell ----------------------------- The Lustre 2.5 branch is the one for which we expect to see regularly scheduled maintenance releases for an extended period of time (18+ months). We no longer expect regularly scheduled maintenance releases on the Lustre 2.4 branch after the Lustre 2.4.2 release. Our recommended upgrade path after 2.4.2 is an upgrade to the latest 2.5.X release. What to do if you are already committed to Lustre 2.4 ----------------------------------------------------- If you have already committed to using Lustre 2.4 at your organization and an upgrade to Lustre 2.5 is not either desired or possible, we recommend that you contact your Lustre support vendor to find out which branches they intend to support. Some Lustre vendors offer support for branches beyond the Community's officially recommended releases. Some Lustre vendors have already announced their intent to continue supporting their users who have committed to the Lustre 2.4 branch. Chris Morrone OpenSFS Community Development Working Group Lead From gshipman at ornl.gov Wed Aug 21 13:53:18 2013 From: gshipman at ornl.gov (Shipman, Galen M.) Date: Wed, 21 Aug 2013 09:53:18 -0400 Subject: [cdwg] Updated "About Us" for OpenSFS Message-ID: <5CEF44D2-4F50-43E1-B618-AD38D8D50E87@ornl.gov> All, The following is our updated "About Us" for OpenSFS. Please make an attempt to use this for all official OpenSFS communications (notices to the community, press releases, etc.). Open Scalable File Systems, Inc. is a strong and growing nonprofit organization dedicated to the success of the Lustre® file system. OpenSFS was founded in 2010 to advance Lustre, ensuring it remains vendor-neutral, open, and free. Since its inception, OpenSFS has been responsible or advancing Lustre, delivering new releases on behalf of the open source development community. Through working-groups, events, and ongoing funding initiatives, OpenSFS harnesses the power of collaborative development to fuel innovation and growth of Lustre worldwide. http://www.opensfs.org/ * Lustre is a registered trademark of Xyratex Technology Ltd. Thanks Galen From arney at cray.com Wed Aug 21 19:45:08 2013 From: arney at cray.com (Becky Arney) Date: Wed, 21 Aug 2013 19:45:08 +0000 Subject: [cdwg] [Board] Updated "About Us" for OpenSFS In-Reply-To: <5CEF44D2-4F50-43E1-B618-AD38D8D50E87@ornl.gov> References: <5CEF44D2-4F50-43E1-B618-AD38D8D50E87@ornl.gov> Message-ID: <5F523CEB-1E15-49E5-BC38-3C832E0D77C6@cray.com> Note, one typo corrected below, correction noted in RED ("for") … please use corrected text. On Aug 21, 2013, at 6:53 AM, Shipman, Galen M. wrote: All, The following is our updated "About Us" for OpenSFS. Please make an attempt to use this for all official OpenSFS communications (notices to the community, press releases, etc.). Open Scalable File Systems, Inc. is a strong and growing nonprofit organization dedicated to the success of the Lustre® file system. OpenSFS was founded in 2010 to advance Lustre, ensuring it remains vendor-neutral, open, and free. Since its inception, OpenSFS has been responsible for advancing Lustre, delivering new releases on behalf of the open source development community. Through working-groups, events, and ongoing funding initiatives, OpenSFS harnesses the power of collaborative development to fuel innovation and growth of Lustre worldwide. http://www.opensfs.org/ * Lustre is a registered trademark of Xyratex Technology Ltd. Thanks Galen _______________________________________________ Board mailing list Board at lists.opensfs.org http://lists.opensfs.org/listinfo.cgi/board-opensfs.org -------------- next part -------------- An HTML attachment was scrubbed... URL: From michael_connolly at xyratex.com Wed Aug 21 18:46:56 2013 From: michael_connolly at xyratex.com (Michael K. Connolly) Date: Wed, 21 Aug 2013 14:46:56 -0400 Subject: [cdwg] [Marketing] Updated "About Us" for OpenSFS In-Reply-To: <5CEF44D2-4F50-43E1-B618-AD38D8D50E87@ornl.gov> References: <5CEF44D2-4F50-43E1-B618-AD38D8D50E87@ornl.gov> Message-ID: <00ee01ce9e9e$d0d2a450$7277ecf0$@com> Hello Galen et al, Looks good but there was a typo and Lustre needs to be used as an adjective in context. Here is edit with that in mind: Open Scalable File Systems, Inc. is a strong and growing non-profit organization dedicated to the success of the LustreR file system. OpenSFS was founded in 2010 to advance Lustre file system, ensuring it remains vendor-neutral, open, and free . Since its inception, OpenSFS has played a role in new Lustre releases on behalf of the open source development community. Through working-groups, events, and ongoing funding initiatives, OpenSFS harnesses the power of collaborative development to fuel innovation and growth of the Lustre file system worldwide. http://www.opensfs.org/ *Lustre is a registered trademark of Xyratex Technology Ltd. Best Regards, Michael K. Connolly . Manager, Partner and Alliances Development Xyratex office: (407) 829-3519 . mobile: (407) 920-1583 email: michael_connolly at xyratex.com www.xyratex.com Connect with Xyratex -----Original Message----- From: marketing-bounces at lists.opensfs.org [mailto:marketing-bounces at lists.opensfs.org] On Behalf Of Shipman, Galen M. Sent: Wednesday, August 21, 2013 9:53 AM To: marketing at opensfs.org; Jesse Casman; twg at lists.opensfs.org; cdwg at lists.opensfs.org; openbenchmark at lists.opensfs.org Cc: OpenSFSBoard Subject: [Marketing] Updated "About Us" for OpenSFS All, The following is our updated "About Us" for OpenSFS. Please make an attempt to use this for all official OpenSFS communications (notices to the community, press releases, etc.). Open Scalable File Systems, Inc. is a strong and growing nonprofit organization dedicated to the success of the LustreR file system. OpenSFS was founded in 2010 to advance Lustre, ensuring it remains vendor-neutral, open, and free. Since its inception, OpenSFS has been responsible or advancing Lustre, delivering new releases on behalf of the open source development community. Through working-groups, events, and ongoing funding initiatives, OpenSFS harnesses the power of collaborative development to fuel innovation and growth of Lustre worldwide. http://www.opensfs.org/ * Lustre is a registered trademark of Xyratex Technology Ltd. Thanks Galen _______________________________________________ Marketing mailing list Marketing at lists.opensfs.org http://lists.opensfs.org/listinfo.cgi/marketing-opensfs.org From michael_connolly at xyratex.com Wed Aug 21 20:55:15 2013 From: michael_connolly at xyratex.com (Michael K. Connolly) Date: Wed, 21 Aug 2013 16:55:15 -0400 Subject: [cdwg] [Marketing] Updated "About Us" for OpenSFS References: <5CEF44D2-4F50-43E1-B618-AD38D8D50E87@ornl.gov> Message-ID: <000601ce9eb0$bea65e90$3bf31bb0$@com> A further typo was alerted to me so here is new version: Open Scalable File Systems, Inc. is a strong and growing non-profit organization dedicated to the success of the LustreR file system. OpenSFS was founded in 2010 to advance the Lustre file system, ensuring it remains vendor-neutral, open, and free . Since its inception, OpenSFS has played a role in new Lustre file system releases on behalf of the open source development community. Through working-groups, events, and ongoing funding initiatives, OpenSFS harnesses the power of collaborative development to fuel innovation and growth of the Lustre file system worldwide. http://www.opensfs.org/ *Lustre is a registered trademark of Xyratex Technology Ltd. Best Regards, Michael K. Connolly . Manager, Partner and Alliances Development Xyratex office: (407) 829-3519 . mobile: (407) 920-1583 email: michael_connolly at xyratex.com www.xyratex.com Connect with Xyratex -----Original Message----- From: Michael K. Connolly [mailto:michael_connolly at xyratex.com] Sent: Wednesday, August 21, 2013 2:47 PM To: 'Shipman, Galen M.'; 'marketing at opensfs.org'; 'Jesse Casman'; 'twg at lists.opensfs.org'; 'cdwg at lists.opensfs.org'; 'openbenchmark at lists.opensfs.org' Cc: 'OpenSFSBoard' Subject: RE: [Marketing] Updated "About Us" for OpenSFS Hello Galen et al, Looks good but there was a typo and Lustre needs to be used as an adjective in context. Here is edit with that in mind: Open Scalable File Systems, Inc. is a strong and growing non-profit organization dedicated to the success of the LustreR file system. OpenSFS was founded in 2010 to advance Lustre file system, ensuring it remains vendor-neutral, open, and free . Since its inception, OpenSFS has played a role in new Lustre releases on behalf of the open source development community. Through working-groups, events, and ongoing funding initiatives, OpenSFS harnesses the power of collaborative development to fuel innovation and growth of the Lustre file system worldwide. http://www.opensfs.org/ *Lustre is a registered trademark of Xyratex Technology Ltd. Best Regards, Michael K. Connolly . Manager, Partner and Alliances Development Xyratex office: (407) 829-3519 . mobile: (407) 920-1583 email: michael_connolly at xyratex.com www.xyratex.com Connect with Xyratex -----Original Message----- From: marketing-bounces at lists.opensfs.org [mailto:marketing-bounces at lists.opensfs.org] On Behalf Of Shipman, Galen M. Sent: Wednesday, August 21, 2013 9:53 AM To: marketing at opensfs.org; Jesse Casman; twg at lists.opensfs.org; cdwg at lists.opensfs.org; openbenchmark at lists.opensfs.org Cc: OpenSFSBoard Subject: [Marketing] Updated "About Us" for OpenSFS All, The following is our updated "About Us" for OpenSFS. Please make an attempt to use this for all official OpenSFS communications (notices to the community, press releases, etc.). Open Scalable File Systems, Inc. is a strong and growing nonprofit organization dedicated to the success of the LustreR file system. OpenSFS was founded in 2010 to advance Lustre, ensuring it remains vendor-neutral, open, and free. Since its inception, OpenSFS has been responsible or advancing Lustre, delivering new releases on behalf of the open source development community. Through working-groups, events, and ongoing funding initiatives, OpenSFS harnesses the power of collaborative development to fuel innovation and growth of Lustre worldwide. http://www.opensfs.org/ * Lustre is a registered trademark of Xyratex Technology Ltd. Thanks Galen _______________________________________________ Marketing mailing list Marketing at lists.opensfs.org http://lists.opensfs.org/listinfo.cgi/marketing-opensfs.org From john.carrier at gmail.com Thu Aug 22 20:48:47 2013 From: john.carrier at gmail.com (John Carrier) Date: Thu, 22 Aug 2013 13:48:47 -0700 Subject: [cdwg] cdwg Digest, Vol 27, Issue 20 In-Reply-To: References: Message-ID: Michael, Your rewrite obscures the fact that OpenSFS is not just involved in the releases of Lustre but also has funded new feature development. Until there is more community-generated development, this function is no less important than the release process. This sentence captures this thought more explicitly: > Since its inception, OpenSFS has funded development of important new Lustre file system features and played a role in new Lustre file system > releases on behalf of > the open source development community. I also find the term "open source development community" to be awkward and inexact since the beneficiaries of our efforts are all users of the Lustre file system, not just the developers. thanks, --jc Sent from my iPad > > Date: Wed, 21 Aug 2013 16:55:15 -0400 > From: "Michael K. Connolly" > To: "'Shipman, Galen M.'" , > , "'Jesse Casman'" , > , , > > Cc: 'OpenSFSBoard' > Subject: Re: [cdwg] [Marketing] Updated "About Us" for OpenSFS > Message-ID: <000601ce9eb0$bea65e90$3bf31bb0$@com> > Content-Type: text/plain; charset="us-ascii" > > A further typo was alerted to me so here is new version: > > > > Open Scalable File Systems, Inc. is a strong and growing non-profit > organization dedicated to the success of the LustreR file system. OpenSFS > was founded in 2010 to advance the Lustre file system, ensuring it remains > vendor-neutral, open, and free . > Since its inception, OpenSFS has played a role in new Lustre file system > releases on behalf of > the open source development community. Through working-groups, events, and > ongoing funding initiatives, OpenSFS harnesses the power of collaborative > development to fuel innovation and growth of the Lustre file system > worldwide. > > http://www.opensfs.org/ > > *Lustre is a registered trademark of Xyratex Technology Ltd. > > > > > Best Regards, > > Michael K. Connolly . Manager, Partner and Alliances Development > Xyratex > office: (407) 829-3519 . mobile: (407) 920-1583 > email: michael_connolly at xyratex.com > www.xyratex.com > Connect with Xyratex > > > ************************************ From michael_connolly at xyratex.com Thu Aug 22 21:28:58 2013 From: michael_connolly at xyratex.com (Michael K. Connolly) Date: Thu, 22 Aug 2013 17:28:58 -0400 Subject: [cdwg] cdwg Digest, Vol 27, Issue 20 In-Reply-To: References: Message-ID: <008001ce9f7e$9e1931b0$da4b9510$@com> Hi John, Thanks for comments but I only made minor changes to use of the word Lustre (needs to be an adjective) in my update. The other points you referenced as change and some that are not in the paragraph are not related to me but was how the text appeared from Galen. Have a look at first version in thread compared to mine. Have a great night. Best Regards, Michael K. Connolly . Manager, Partner and Alliances Development Xyratex office: (407) 829-3519 . mobile: (407) 920-1583 email: michael_connolly at xyratex.com www.xyratex.com Connect with Xyratex Begin forwarded message: From: John Carrier Subject: Re: [cdwg] cdwg Digest, Vol 27, Issue 20 Date: August 22, 2013 1:48:47 PM PDT To: "cdwg at lists.opensfs.org" Michael, Your rewrite obscures the fact that OpenSFS is not just involved in the releases of Lustre but also has funded new feature development. Until there is more community-generated development, this function is no less important than the release process. This sentence captures this thought more explicitly: Since its inception, OpenSFS has funded development of important new Lustre file system features and played a role in new Lustre file system releases on behalf of the open source development community. I also find the term "open source development community" to be awkward and inexact since the beneficiaries of our efforts are all users of the Lustre file system, not just the developers. thanks, --jc Sent from my iPad Date: Wed, 21 Aug 2013 16:55:15 -0400 From: "Michael K. Connolly" To: "'Shipman, Galen M.'" , , "'Jesse Casman'" , , , Cc: 'OpenSFSBoard' Subject: Re: [cdwg] [Marketing] Updated "About Us" for OpenSFS Message-ID: <000601ce9eb0$bea65e90$3bf31bb0$@com> Content-Type: text/plain; charset="us-ascii" A further typo was alerted to me so here is new version: Open Scalable File Systems, Inc. is a strong and growing non-profit organization dedicated to the success of the LustreR file system. OpenSFS was founded in 2010 to advance the Lustre file system, ensuring it remains vendor-neutral, open, and free . Since its inception, OpenSFS has played a role in new Lustre file system releases on behalf of the open source development community. Through working-groups, events, and ongoing funding initiatives, OpenSFS harnesses the power of collaborative development to fuel innovation and growth of the Lustre file system worldwide. http://www.opensfs.org/ *Lustre is a registered trademark of Xyratex Technology Ltd. Best Regards, Michael K. Connolly . Manager, Partner and Alliances Development Xyratex office: (407) 829-3519 . mobile: (407) 920-1583 email: michael_connolly at xyratex.com www.xyratex.com Connect with Xyratex ************************************ _______________________________________________ cdwg mailing list cdwg at lists.opensfs.org http://lists.opensfs.org/listinfo.cgi/cdwg-opensfs.org -------------- next part -------------- An HTML attachment was scrubbed... URL: From gshipman at ornl.gov Tue Aug 27 23:29:35 2013 From: gshipman at ornl.gov (Shipman, Galen M.) Date: Tue, 27 Aug 2013 19:29:35 -0400 Subject: [cdwg] Updated "About Us" for OpenSFS Message-ID: <203A291A-9B46-478A-B683-C8F94722ADCC@ornl.gov> Thank you all for your positive feedback, very helpful. Below is an update to our About Us: Open Scalable File Systems, Inc. is a strong and growing nonprofit organization dedicated to the success of the Lustre* file system. OpenSFS was founded in 2010 to advance Lustre, ensuring it remains vendor-neutral, open, and free. Since its inception, OpenSFS has been responsible for advancing Lustre, delivering new releases on behalf of the open source community. Through working-groups, events, and ongoing funding initiatives, OpenSFS harnesses the power of collaborative development to fuel innovation and growth of Lustre worldwide. http://www.opensfs.org/ * Lustre is a registered trademark of Xyratex Technology Ltd. From morrone2 at llnl.gov Tue Aug 27 22:09:58 2013 From: morrone2 at llnl.gov (Christopher J. Morrone) Date: Tue, 27 Aug 2013 15:09:58 -0700 Subject: [cdwg] OpenSFS CDWG Call Message-ID: <521D23B6.6050709@llnl.gov> Hi all, This is a reminder that we will have a Community Development Working Group (CDWG) call on Wednesday, August 28, at 9:00am PDT. Agenda: * Lustre 2.5.0 status update * Begin Lustre 2.6.0 planning If you have any additional agenda items, please suggest them before the call. Call-in: 866-914-3976 (925-424-8105) Passcode: 534986# Regards, Chris From denis_kondratenko at xyratex.com Thu Aug 29 13:10:23 2013 From: denis_kondratenko at xyratex.com (Denis Kondratenko) Date: Thu, 29 Aug 2013 16:10:23 +0300 Subject: [cdwg] pending review list In-Reply-To: References: Message-ID: Hi All, OK. Let me be more specific. I am still in position to find and define process problems and not to blame someone. Let start from small subset of our current reviews. It seems to be specific and natural. Looking to this queue (and master only): http://review.whamcloud.com/#/q/starredby:Denis_Kondratenko,n,z LU-3031/5843: Uploaded: Mar 26, 2013 2:07 PM Updated: Aug 29, 2013 6:44 AM Patch Sets: 5 from first look it seems OK, Updated recently and has no negative marks. But lets see why 5 patch sets and 5 months. Patch Set 1 - failed testing. 28 Mar - 8 Apr, 11 days - no update from engineer Patch Set 2 - passed 9 Apr-10 Jul, 31 days - no review 10 Jul - 26 Jul, 16 days - no update from engineer Patch Set 3 - passed 30 Jul- 10 Aug, 10 days, - no review 10 Aug-13 Aug, 3 days, - no review review failed 13 Aug-26 Aug, 13 days - no update from engineer build failed - rebase - 2 days Process summary: 5 stages, 5 months no update from engineer: 11+16+13 = 40 days no review: 31+10+3 = 44 days test failures: 1 rebase: 2 days LU-2524/5022 Process summary: 15 stages, 7.5 months no update from engineer: 2+1+2+26+5+150+5+2 no review: 2 test failures: 1+1+1+1+1+1+1 rebase: 4 LU-1601/3276 Process summary: 10 stages, 13 months no update from engineer: 14+19+7+180+2+12 no review: 120+12+28 test failures: 1+1+1 test issue: 7 rebase:3 LU-3473/6648 Process summary: 2 stages, 0.5 months no update from engineer: 13 no review: 1 test failures: test issue: rebase: LU-2711/5213 Process summary: 17 stages, 5 months no update from engineer: 10+9+30 no review: 5+5+70 test failures: 1+1+1+1+1+1+1+1 test issue:5+ rebase:1+1+1 LU-2377/4664 Process summary: 2 stages, 9 months no update from engineer: 120 no review: 4+112 test failures: test issue: rebase: So that are strict numbers. What conclusions should be done, numbers like: 31, 26, 150, 180, 120, 30, 70, 120, 112 indicate issues. Problem stages are: no update from engineer, no review. All tickets are individual, but pattern is the same. If there will be possibility to get that stat on big set of issues we could get different conclusion. So I think you probably understood the way. We need stat numbers and not individual check for every ticket. We might be need some automatic notification for stages longer than 1-2 weeks (what ever we will define). Might be that any time more than week or two - is the sbj for discuss on CDWG. Numbers will not say us all trues about review - they will indicate problem reviews and problem stages. That what I want to discuss on CDWG every week - what problem reviews we have, what problem stages now. Please review and provide your feedback. Thanks, Denis On 29 авг. 2013, at 00:46, "Jones, Peter A" wrote: > Yes the CDWG is the place to raise questions like this. Alternatively, my > door continues to remain open to John if he would like to chat directly. > > On 8/28/13 10:58 AM, "Christopher J. Morrone" wrote: > >> Denis, >> >> I think that the CDWG list is the place to take these. >> >> I would suggest though, that you need to say a little more about what >> you think the problem if for each of the patches. >> >> For instance you call out patch 5213 from LU-2711, and it looks to me >> like that patch had a recent review from Andreas and now the ball is in >> Xyratex's court waiting for the next revision. What do you want or need >> from the CDWG on that ticket? What is it that we should find interesting? >> >> Chris >> >> On 08/28/2013 10:19 AM, Denis Kondratenko wrote: >>> Forgot to add Nic >>> >>> On Aug 28, 2013 7:45 PM, "Denis Kondratenko" >>> > >>> wrote: >>> >>> Hi Team, >>> >>> I don't really know how to correctly share this info to discuss on >>> CDWG or just with us. >>> >>> Lets start from something. >>> >>> Here is the list of reviews that we want to check: >>> >>> http://review.whamcloud.com/#/q/status:open+project:fs/lustre-release+sta >>> rredby:Denis_Kondratenko+branch:master+-Verified-1+-Verified-2+-CodeRevie >>> w-1+-CodeReview-2,n,z >>> >>> That actually has different problems inside. >>> Beside that it was updated recently, some of that takes long time to >>> review. >>> >>> It not worse to look into this table too: >>> http://review.whamcloud.com/#/q/starredby:Denis_Kondratenko,n,z >>> >>> Examples are LU-2711 and LU-2377, interesting to look into them. >>> >>> Branches other than master - we need to understand what to do with >>> them too. Should we not submit fixes against them? >>> >>> Probably will be cool to get list of problems that we have(in >>> engineering response for example) from these list and start >>> discussion on CDWG. Maybe we could later build some FAQ or improve >>> process. >>> >>> Please review and provide your feedback. >>> >>> Thanks, >>> Denis >>> >>> >>> ------------------------------------------------------------------------ >>> For additional information including the registered office and the >>> treatment of Xyratex confidential information please >>> visitwww.xyratex.com >>> >>> ------------------------------------------------------------------------ >> > -- ------------------------------ For additional information including the registered office and the treatment of Xyratex confidential information please visit www.xyratex.com ------------------------------ -------------- next part -------------- An HTML attachment was scrubbed... URL: From john_forgan at xyratex.com Thu Aug 29 13:24:01 2013 From: john_forgan at xyratex.com (John Forgan) Date: Thu, 29 Aug 2013 14:24:01 +0100 Subject: [cdwg] pending review list In-Reply-To: References: Message-ID: Hi, I'd just like to emphasize that we are keen to work with the community to improve process and response times, and it may very well be that there are issues with the way that we, ourselves, are logging and progressing tickets. Please make any recommendations that you think will help. I appreciate that it is never easy to handle many things at once, particularly in an Open Source project where resources aren't limitless, but if we all come to a common understanding on how to handle tickets and how to ensure an appropriate response time, it can only be a good thing for us all. Best regards John On 29 August 2013 14:10, Denis Kondratenko wrote: > Hi All, > > OK. Let me be more specific. > I am still in position to find and define process problems and not to > blame someone. > > Let start from small subset of our current reviews. It seems to be > specific and natural. > > Looking to this queue (and master only): > http://review.whamcloud.com/#/q/starredby:Denis_Kondratenko,n,z > > LU-3031/5843: > Uploaded: Mar 26, 2013 2:07 PM > Updated: Aug 29, 2013 6:44 AM > Patch Sets: 5 > > from first look it seems OK, Updated recently and has no negative marks. > But lets see why 5 patch sets and 5 months. > Patch Set 1 - failed testing. > 28 Mar - 8 Apr, 11 days - no update from engineer > Patch Set 2 - passed > 9 Apr-10 Jul, 31 days - no review > 10 Jul - 26 Jul, 16 days - no update from engineer > Patch Set 3 - passed > 30 Jul- 10 Aug, 10 days, - no review > 10 Aug-13 Aug, 3 days, - no review > review failed > 13 Aug-26 Aug, 13 days - no update from engineer > build failed - rebase - 2 days > > Process summary: > 5 stages, 5 months > no update from engineer: 11+16+13 = 40 days > no review: 31+10+3 = 44 days > test failures: 1 > rebase: 2 days > > LU-2524/5022 > Process summary: > 15 stages, 7.5 months > no update from engineer: 2+1+2+26+5+150+5+2 > no review: 2 > test failures: 1+1+1+1+1+1+1 > rebase: 4 > > LU-1601/3276 > Process summary: > 10 stages, 13 months > no update from engineer: 14+19+7+180+2+12 > no review: 120+12+28 > test failures: 1+1+1 > test issue: 7 > rebase:3 > > LU-3473/6648 > Process summary: > 2 stages, 0.5 months > no update from engineer: 13 > no review: 1 > test failures: > test issue: > rebase: > > LU-2711/5213 > Process summary: > 17 stages, 5 months > no update from engineer: 10+9+30 > no review: 5+5+70 > test failures: 1+1+1+1+1+1+1+1 > test issue:5+ > rebase:1+1+1 > > LU-2377/4664 > Process summary: > 2 stages, 9 months > no update from engineer: 120 > no review: 4+112 > test failures: > test issue: > rebase: > > So that are strict numbers. > > What conclusions should be done, numbers like: > 31, 26, 150, 180, 120, 30, 70, 120, 112 > indicate issues. > > Problem stages are: no update from engineer, no review. > > All tickets are individual, but pattern is the same. > If there will be possibility to get that stat on big set of issues we > could get different conclusion. > > So I think you probably understood the way. We need stat numbers and not > individual check for every ticket. > > We might be need some automatic notification for stages longer than 1-2 > weeks (what ever we will define). > > Might be that any time more than week or two - is the sbj for discuss on > CDWG. > > Numbers will not say us all trues about review - they will indicate > problem reviews and problem stages. > > That what I want to discuss on CDWG every week - what problem reviews we > have, what problem stages now. > > Please review and provide your feedback. > > Thanks, > Denis > > On 29 авг. 2013, at 00:46, "Jones, Peter A" > wrote: > > Yes the CDWG is the place to raise questions like this. Alternatively, my > door continues to remain open to John if he would like to chat directly. > > On 8/28/13 10:58 AM, "Christopher J. Morrone" wrote: > > Denis, > > I think that the CDWG list is the place to take these. > > I would suggest though, that you need to say a little more about what > you think the problem if for each of the patches. > > For instance you call out patch 5213 from LU-2711, and it looks to me > like that patch had a recent review from Andreas and now the ball is in > Xyratex's court waiting for the next revision. What do you want or need > from the CDWG on that ticket? What is it that we should find interesting? > > Chris > > On 08/28/2013 10:19 AM, Denis Kondratenko wrote: > > Forgot to add Nic > > On Aug 28, 2013 7:45 PM, "Denis Kondratenko" > > >> > wrote: > > Hi Team, > > I don't really know how to correctly share this info to discuss on > CDWG or just with us. > > Lets start from something. > > Here is the list of reviews that we want to check: > > http://review.whamcloud.com/#/q/status:open+project:fs/lustre-release+sta > rredby:Denis_Kondratenko+branch:master+-Verified-1+-Verified-2+-CodeRevie > w-1+-CodeReview-2,n,z > > That actually has different problems inside. > Beside that it was updated recently, some of that takes long time to > review. > > It not worse to look into this table too: > http://review.whamcloud.com/#/q/starredby:Denis_Kondratenko,n,z > > Examples are LU-2711 and LU-2377, interesting to look into them. > > Branches other than master - we need to understand what to do with > them too. Should we not submit fixes against them? > > Probably will be cool to get list of problems that we have(in > engineering response for example) from these list and start > discussion on CDWG. Maybe we could later build some FAQ or improve > process. > > Please review and provide your feedback. > > Thanks, > Denis > > > ------------------------------------------------------------------------ > For additional information including the registered office and the > treatment of Xyratex confidential information please > visitwww.xyratex.com > > ------------------------------------------------------------------------ > > > > > -- John Forgan Senior Software Engineering Manager Xyratex Office : +44 (0)2392 496819 Mobile: +44 (0)7738 136207 *john_forgan at xyratex.com *www.xyratex.com -- ------------------------------ For additional information including the registered office and the treatment of Xyratex confidential information please visit www.xyratex.com ------------------------------ -------------- next part -------------- An HTML attachment was scrubbed... URL: From peter.a.jones at intel.com Thu Aug 29 21:36:52 2013 From: peter.a.jones at intel.com (Jones, Peter A) Date: Thu, 29 Aug 2013 21:36:52 +0000 Subject: [cdwg] pending review list In-Reply-To: Message-ID: Thanks John/Denis. I appreciate and welcome Xyratex's intention to stimulate discussion. I have looked over the below data and must confess that I am quite puzzled by how the data in the cited tickets reconciles with the stated conclusions. Rather than starting another lengthy email chain, I think that it would be more efficient to step through these in the next CDWG call. It certainly looks like this would be a worthwhile exercise and help feed into the process page that the CDWG is working on. On 8/29/13 6:24 AM, "John Forgan" > wrote: Hi, I'd just like to emphasize that we are keen to work with the community to improve process and response times, and it may very well be that there are issues with the way that we, ourselves, are logging and progressing tickets. Please make any recommendations that you think will help. I appreciate that it is never easy to handle many things at once, particularly in an Open Source project where resources aren't limitless, but if we all come to a common understanding on how to handle tickets and how to ensure an appropriate response time, it can only be a good thing for us all. Best regards John On 29 August 2013 14:10, Denis Kondratenko > wrote: Hi All, OK. Let me be more specific. I am still in position to find and define process problems and not to blame someone. Let start from small subset of our current reviews. It seems to be specific and natural. Looking to this queue (and master only): http://review.whamcloud.com/#/q/starredby:Denis_Kondratenko,n,z LU-3031/5843: Uploaded: Mar 26, 2013 2:07 PM Updated: Aug 29, 2013 6:44 AM Patch Sets: 5 from first look it seems OK, Updated recently and has no negative marks. But lets see why 5 patch sets and 5 months. Patch Set 1 - failed testing. 28 Mar - 8 Apr, 11 days - no update from engineer Patch Set 2 - passed 9 Apr-10 Jul, 31 days - no review 10 Jul - 26 Jul, 16 days - no update from engineer Patch Set 3 - passed 30 Jul- 10 Aug, 10 days, - no review 10 Aug-13 Aug, 3 days, - no review review failed 13 Aug-26 Aug, 13 days - no update from engineer build failed - rebase - 2 days Process summary: 5 stages, 5 months no update from engineer: 11+16+13 = 40 days no review: 31+10+3 = 44 days test failures: 1 rebase: 2 days LU-2524/5022 Process summary: 15 stages, 7.5 months no update from engineer: 2+1+2+26+5+150+5+2 no review: 2 test failures: 1+1+1+1+1+1+1 rebase: 4 LU-1601/3276 Process summary: 10 stages, 13 months no update from engineer: 14+19+7+180+2+12 no review: 120+12+28 test failures: 1+1+1 test issue: 7 rebase:3 LU-3473/6648 Process summary: 2 stages, 0.5 months no update from engineer: 13 no review: 1 test failures: test issue: rebase: LU-2711/5213 Process summary: 17 stages, 5 months no update from engineer: 10+9+30 no review: 5+5+70 test failures: 1+1+1+1+1+1+1+1 test issue:5+ rebase:1+1+1 LU-2377/4664 Process summary: 2 stages, 9 months no update from engineer: 120 no review: 4+112 test failures: test issue: rebase: So that are strict numbers. What conclusions should be done, numbers like: 31, 26, 150, 180, 120, 30, 70, 120, 112 indicate issues. Problem stages are: no update from engineer, no review. All tickets are individual, but pattern is the same. If there will be possibility to get that stat on big set of issues we could get different conclusion. So I think you probably understood the way. We need stat numbers and not individual check for every ticket. We might be need some automatic notification for stages longer than 1-2 weeks (what ever we will define). Might be that any time more than week or two - is the sbj for discuss on CDWG. Numbers will not say us all trues about review - they will indicate problem reviews and problem stages. That what I want to discuss on CDWG every week - what problem reviews we have, what problem stages now. Please review and provide your feedback. Thanks, Denis On 29 авг. 2013, at 00:46, "Jones, Peter A" > wrote: Yes the CDWG is the place to raise questions like this. Alternatively, my door continues to remain open to John if he would like to chat directly. On 8/28/13 10:58 AM, "Christopher J. Morrone" > wrote: Denis, I think that the CDWG list is the place to take these. I would suggest though, that you need to say a little more about what you think the problem if for each of the patches. For instance you call out patch 5213 from LU-2711, and it looks to me like that patch had a recent review from Andreas and now the ball is in Xyratex's court waiting for the next revision. What do you want or need from the CDWG on that ticket? What is it that we should find interesting? Chris On 08/28/2013 10:19 AM, Denis Kondratenko wrote: Forgot to add Nic On Aug 28, 2013 7:45 PM, "Denis Kondratenko" > wrote: Hi Team, I don't really know how to correctly share this info to discuss on CDWG or just with us. Lets start from something. Here is the list of reviews that we want to check: http://review.whamcloud.com/#/q/status:open+project:fs/lustre-release+sta rredby:Denis_Kondratenko+branch:master+-Verified-1+-Verified-2+-CodeRevie w-1+-CodeReview-2,n,z That actually has different problems inside. Beside that it was updated recently, some of that takes long time to review. It not worse to look into this table too: http://review.whamcloud.com/#/q/starredby:Denis_Kondratenko,n,z Examples are LU-2711 and LU-2377, interesting to look into them. Branches other than master - we need to understand what to do with them too. Should we not submit fixes against them? Probably will be cool to get list of problems that we have(in engineering response for example) from these list and start discussion on CDWG. Maybe we could later build some FAQ or improve process. Please review and provide your feedback. Thanks, Denis ------------------------------------------------------------------------ For additional information including the registered office and the treatment of Xyratex confidential information please visitwww.xyratex.com ------------------------------------------------------------------------ -- John Forgan Senior Software Engineering Manager Xyratex Office : +44 (0)2392 496819 Mobile: +44 (0)7738 136207 john_forgan at xyratex.com www.xyratex.com ________________________________ For additional information including the registered office and the treatment of Xyratex confidential information please visit www.xyratex.com ________________________________ From peter.a.jones at intel.com Fri Aug 30 17:44:26 2013 From: peter.a.jones at intel.com (Jones, Peter A) Date: Fri, 30 Aug 2013 17:44:26 +0000 Subject: [cdwg] Lustre 2.5 update - August 30th 2013 Message-ID: Hi there Here is an update on the Lustre 2.5 release. Landings ======== -A number of landings made - see http://git.whamcloud.com/?p=fs/lustre-release.git;a=shortlog;h=refs/heads/master Testing ======= - Testing on the 2.4.90 and 2.4.91 tags is complete; 2.4.92 tag will be created shortly Blockers ======== -Full list available at https://jira.hpdd.intel.com/issues/?jql=project%20%3D%20LU%20AND%20fixVersion%20%3D%20%22Lustre%202.5.0%22%20AND%20resolution%20%3D%20Unresolved%20AND%20priority%20%3D%20Blocker%20ORDER%20BY%20key%20DESC -If there are any issues not presently marked as blockers that you believe should be, please let me know Other ===== -We are trialling using the Fix In Release field for the 2.5 release to track work hoped to be included in the release; this means that a fuller picture of the progress on the release can be viewed at https://jira.hpdd.intel.com/browse/LU/fixforversion/10295#selectedTab=com.atlassian.jira.plugin.system.project%3Aversion-issues-panel -Feature Freeze is now in effect and 2.5 has entered its stabilization period. We encourage community members to test out the latest code on master and to use JIRA (https://jira.hpdd.intel.com) to report any bugs encountered -You can also keep up to date with matters relating to the 2.5 release on the CDWG wiki - http://wiki.opensfs.org/Lustre_2.5.0 Thanks Peter