Re: [Gluster-devel] Automated bug workflow
On 11/05/2015 04:42 PM, Mohammed Rafi K C wrote: > +pranith, Niles > > On 11/05/2015 04:21 PM, Nandaja Varma wrote: >> Hi, >> >> What is the status of this automation task? > We had couple of discussion regarding this project, unfortunately we > couldn't keep the timeline as we planned because of some other major > issues. As said that the project has completed the design phase [1]. The > implementation is yet to start :). > >> If it hasn't been worked upon Myself and Manikandan would like to take this >> up and work on. > We would be more than happy to welcome and work with you guys. We could > help you with some of the bits. With your convenient, let us make a new > timline plan and make it real :). I will add this topic as agenda for next bug triage meeting that usually happens on every Tuesday. Rafi KC > > Thanks Nandaja and Manikandan for taking a good initiative . > Looking forward to see this feature in upstream gerrit :) > > Regards > Rafi KC > > [1] : https://public.pad.fsfe.org/p/gluster-automated-bug-workflow >> Cheers, >> Nandaja >> >> - Original Message - >> From: "Pranith Kumar Karampuri" >> To: "Rafi Kavungal Chundattu Parambil" , >> gluster-devel@gluster.org >> Sent: Tuesday, July 7, 2015 2:48:22 PM >> Subject: Re: [Gluster-devel] Automated bug workflow >> >> >> >> On 07/07/2015 02:42 PM, Rafi Kavungal Chundattu Parambil wrote: >>> Since we have some common interest in proposed design, IMHO let's start >>> doing the implementation by keeping all of this valuable suggestions in >>> mind. >>> >>> If any one interested to volunteer this project, please reply to this >>> thread. >> I really want to contribute to this, but I am tied up with other work >> till end of this month. When are we trying to start this? >> >> Pranith >>> Regards >>> Rafi KC >>> >>> >>> - Original Message - >>> From: "Shyam" >>> To: "Niels de Vos" , gluster-devel@gluster.org >>> Sent: Friday, May 29, 2015 11:23:34 PM >>> Subject: Re: [Gluster-devel] Automated bug workflow >>> >>> On 05/29/2015 12:51 PM, Niels de Vos wrote: >>>> Hi all, >>>> >>>> today we had a discussion about how to get the status of reported bugs >>>> more correct and up to date. It is something that has come up several >>>> times already, but now we have a "BIG solution" as Pranith calls it. >>>> >>>> The goal is rather simple, but is requires some thinking about rules and >>>> components that can actually take care of the automation. >>>> >>>> The general user-visible results would be: >>>> >>>>* rfc.sh will ask if this patch it the last one for the bug, or if more >>>> patches are expected >>>>* Gerrit will receive the patch with the answer, and modify the status >>>> of the bug to POST >>> I like to do this manually. >>> >>>>* when the patch is merged, Gerrit will change (or not) the status of >>>> the bug to MODIFIED >>> I like to do this manually too... but automation does not hurt, esp. >>> when I control when the bug moves to POST. >>> >>>>* when a nightly build is made, all bugs that have patches included and >>>> the status of the bug is MODIFIED, the build script will change the >>>> status to ON_QA and set a "fixed in version" >>> This I would like automated, as I am not tracking when it was released >>> (of sorts). But, if I miss the nightly boat, I assume the automation >>> would not pick this up, as a result automation on the MODIFIED step is >>> good, as that would take care of this miss for me. >>> >>>> This is a simplified view, there are some other cases that we need to >>>> take care of. These are documented in the etherpad linked below. >>>> >>>> We value any input for this, Kaleb and Rafi already gave some, thanks! >>>> Please let us know over email or IRC and we'll update the etherpad. >>> Overall, we can have all of this, but I guess I will possibly never use >>> the POST automation and do that myself. >>> >>>> Thanks, >>>> Pranith & Niels >>>> >>>> >>>> Etherpad with detailed step by step actions to take: >>>> >>>> https://public.pad.fsfe.org/p/gluster-automated-bug-workflow >>>> >>>> IRC log, where the discussion started: >>>> >>>> >>>> https://botbot.me/freenode/gluster-dev/2015-05-29/?msg=40450336&page=2 >>>> >>>> ___ >>>> Gluster-devel mailing list >>>> Gluster-devel@gluster.org >>>> http://www.gluster.org/mailman/listinfo/gluster-devel >>>> >>> ___ >>> Gluster-devel mailing list >>> Gluster-devel@gluster.org >>> http://www.gluster.org/mailman/listinfo/gluster-devel >> ___ >> Gluster-devel mailing list >> Gluster-devel@gluster.org >> http://www.gluster.org/mailman/listinfo/gluster-devel ___ Gluster-devel mailing list Gluster-devel@gluster.org http://www.gluster.org/mailman/listinfo/gluster-devel
Re: [Gluster-devel] Automated bug workflow
+pranith, Niles On 11/05/2015 04:21 PM, Nandaja Varma wrote: > Hi, > > What is the status of this automation task? We had couple of discussion regarding this project, unfortunately we couldn't keep the timeline as we planned because of some other major issues. As said that the project has completed the design phase [1]. The implementation is yet to start :). > If it hasn't been worked upon Myself and Manikandan would like to take this > up and work on. We would be more than happy to welcome and work with you guys. We could help you with some of the bits. With your convenient, let us make a new timline plan and make it real :). Thanks Nandaja and Manikandan for taking a good initiative . Looking forward to see this feature in upstream gerrit :) Regards Rafi KC [1] : https://public.pad.fsfe.org/p/gluster-automated-bug-workflow > > Cheers, > Nandaja > > - Original Message - > From: "Pranith Kumar Karampuri" > To: "Rafi Kavungal Chundattu Parambil" , > gluster-devel@gluster.org > Sent: Tuesday, July 7, 2015 2:48:22 PM > Subject: Re: [Gluster-devel] Automated bug workflow > > > > On 07/07/2015 02:42 PM, Rafi Kavungal Chundattu Parambil wrote: >> Since we have some common interest in proposed design, IMHO let's start >> doing the implementation by keeping all of this valuable suggestions in mind. >> >> If any one interested to volunteer this project, please reply to this thread. > I really want to contribute to this, but I am tied up with other work > till end of this month. When are we trying to start this? > > Pranith >> Regards >> Rafi KC >> >> >> - Original Message ----- >> From: "Shyam" >> To: "Niels de Vos" , gluster-devel@gluster.org >> Sent: Friday, May 29, 2015 11:23:34 PM >> Subject: Re: [Gluster-devel] Automated bug workflow >> >> On 05/29/2015 12:51 PM, Niels de Vos wrote: >>> Hi all, >>> >>> today we had a discussion about how to get the status of reported bugs >>> more correct and up to date. It is something that has come up several >>> times already, but now we have a "BIG solution" as Pranith calls it. >>> >>> The goal is rather simple, but is requires some thinking about rules and >>> components that can actually take care of the automation. >>> >>> The general user-visible results would be: >>> >>>* rfc.sh will ask if this patch it the last one for the bug, or if more >>> patches are expected >>>* Gerrit will receive the patch with the answer, and modify the status >>> of the bug to POST >> I like to do this manually. >> >>>* when the patch is merged, Gerrit will change (or not) the status of >>> the bug to MODIFIED >> I like to do this manually too... but automation does not hurt, esp. >> when I control when the bug moves to POST. >> >>>* when a nightly build is made, all bugs that have patches included and >>> the status of the bug is MODIFIED, the build script will change the >>> status to ON_QA and set a "fixed in version" >> This I would like automated, as I am not tracking when it was released >> (of sorts). But, if I miss the nightly boat, I assume the automation >> would not pick this up, as a result automation on the MODIFIED step is >> good, as that would take care of this miss for me. >> >>> This is a simplified view, there are some other cases that we need to >>> take care of. These are documented in the etherpad linked below. >>> >>> We value any input for this, Kaleb and Rafi already gave some, thanks! >>> Please let us know over email or IRC and we'll update the etherpad. >> Overall, we can have all of this, but I guess I will possibly never use >> the POST automation and do that myself. >> >>> Thanks, >>> Pranith & Niels >>> >>> >>> Etherpad with detailed step by step actions to take: >>> >>> https://public.pad.fsfe.org/p/gluster-automated-bug-workflow >>> >>> IRC log, where the discussion started: >>> >>> https://botbot.me/freenode/gluster-dev/2015-05-29/?msg=40450336&page=2 >>> >>> ___ >>> Gluster-devel mailing list >>> Gluster-devel@gluster.org >>> http://www.gluster.org/mailman/listinfo/gluster-devel >>> >> ___ >> Gluster-devel mailing list >> Gluster-devel@gluster.org >> http://www.gluster.org/mailman/listinfo/gluster-devel > ___ > Gluster-devel mailing list > Gluster-devel@gluster.org > http://www.gluster.org/mailman/listinfo/gluster-devel ___ Gluster-devel mailing list Gluster-devel@gluster.org http://www.gluster.org/mailman/listinfo/gluster-devel
Re: [Gluster-devel] Automated bug workflow
Hi, What is the status of this automation task? If it hasn't been worked upon Myself and Manikandan would like to take this up and work on. Cheers, Nandaja - Original Message - From: "Pranith Kumar Karampuri" To: "Rafi Kavungal Chundattu Parambil" , gluster-devel@gluster.org Sent: Tuesday, July 7, 2015 2:48:22 PM Subject: Re: [Gluster-devel] Automated bug workflow On 07/07/2015 02:42 PM, Rafi Kavungal Chundattu Parambil wrote: > > Since we have some common interest in proposed design, IMHO let's start doing > the implementation by keeping all of this valuable suggestions in mind. > > If any one interested to volunteer this project, please reply to this thread. I really want to contribute to this, but I am tied up with other work till end of this month. When are we trying to start this? Pranith > > Regards > Rafi KC > > > - Original Message - > From: "Shyam" > To: "Niels de Vos" , gluster-devel@gluster.org > Sent: Friday, May 29, 2015 11:23:34 PM > Subject: Re: [Gluster-devel] Automated bug workflow > > On 05/29/2015 12:51 PM, Niels de Vos wrote: >> Hi all, >> >> today we had a discussion about how to get the status of reported bugs >> more correct and up to date. It is something that has come up several >> times already, but now we have a "BIG solution" as Pranith calls it. >> >> The goal is rather simple, but is requires some thinking about rules and >> components that can actually take care of the automation. >> >> The general user-visible results would be: >> >>* rfc.sh will ask if this patch it the last one for the bug, or if more >> patches are expected >>* Gerrit will receive the patch with the answer, and modify the status >> of the bug to POST > I like to do this manually. > >>* when the patch is merged, Gerrit will change (or not) the status of >> the bug to MODIFIED > I like to do this manually too... but automation does not hurt, esp. > when I control when the bug moves to POST. > >>* when a nightly build is made, all bugs that have patches included and >> the status of the bug is MODIFIED, the build script will change the >> status to ON_QA and set a "fixed in version" > This I would like automated, as I am not tracking when it was released > (of sorts). But, if I miss the nightly boat, I assume the automation > would not pick this up, as a result automation on the MODIFIED step is > good, as that would take care of this miss for me. > >> This is a simplified view, there are some other cases that we need to >> take care of. These are documented in the etherpad linked below. >> >> We value any input for this, Kaleb and Rafi already gave some, thanks! >> Please let us know over email or IRC and we'll update the etherpad. > Overall, we can have all of this, but I guess I will possibly never use > the POST automation and do that myself. > >> Thanks, >> Pranith & Niels >> >> >> Etherpad with detailed step by step actions to take: >> >> https://public.pad.fsfe.org/p/gluster-automated-bug-workflow >> >> IRC log, where the discussion started: >> >> https://botbot.me/freenode/gluster-dev/2015-05-29/?msg=40450336&page=2 >> >> ___ >> Gluster-devel mailing list >> Gluster-devel@gluster.org >> http://www.gluster.org/mailman/listinfo/gluster-devel >> > ___ > Gluster-devel mailing list > Gluster-devel@gluster.org > http://www.gluster.org/mailman/listinfo/gluster-devel ___ Gluster-devel mailing list Gluster-devel@gluster.org http://www.gluster.org/mailman/listinfo/gluster-devel ___ Gluster-devel mailing list Gluster-devel@gluster.org http://www.gluster.org/mailman/listinfo/gluster-devel
Re: [Gluster-devel] Automated bug workflow
On 07/07/2015 02:42 PM, Rafi Kavungal Chundattu Parambil wrote: Since we have some common interest in proposed design, IMHO let's start doing the implementation by keeping all of this valuable suggestions in mind. If any one interested to volunteer this project, please reply to this thread. I really want to contribute to this, but I am tied up with other work till end of this month. When are we trying to start this? Pranith Regards Rafi KC - Original Message - From: "Shyam" To: "Niels de Vos" , gluster-devel@gluster.org Sent: Friday, May 29, 2015 11:23:34 PM Subject: Re: [Gluster-devel] Automated bug workflow On 05/29/2015 12:51 PM, Niels de Vos wrote: Hi all, today we had a discussion about how to get the status of reported bugs more correct and up to date. It is something that has come up several times already, but now we have a "BIG solution" as Pranith calls it. The goal is rather simple, but is requires some thinking about rules and components that can actually take care of the automation. The general user-visible results would be: * rfc.sh will ask if this patch it the last one for the bug, or if more patches are expected * Gerrit will receive the patch with the answer, and modify the status of the bug to POST I like to do this manually. * when the patch is merged, Gerrit will change (or not) the status of the bug to MODIFIED I like to do this manually too... but automation does not hurt, esp. when I control when the bug moves to POST. * when a nightly build is made, all bugs that have patches included and the status of the bug is MODIFIED, the build script will change the status to ON_QA and set a "fixed in version" This I would like automated, as I am not tracking when it was released (of sorts). But, if I miss the nightly boat, I assume the automation would not pick this up, as a result automation on the MODIFIED step is good, as that would take care of this miss for me. This is a simplified view, there are some other cases that we need to take care of. These are documented in the etherpad linked below. We value any input for this, Kaleb and Rafi already gave some, thanks! Please let us know over email or IRC and we'll update the etherpad. Overall, we can have all of this, but I guess I will possibly never use the POST automation and do that myself. Thanks, Pranith & Niels Etherpad with detailed step by step actions to take: https://public.pad.fsfe.org/p/gluster-automated-bug-workflow IRC log, where the discussion started: https://botbot.me/freenode/gluster-dev/2015-05-29/?msg=40450336&page=2 ___ Gluster-devel mailing list Gluster-devel@gluster.org http://www.gluster.org/mailman/listinfo/gluster-devel ___ Gluster-devel mailing list Gluster-devel@gluster.org http://www.gluster.org/mailman/listinfo/gluster-devel ___ Gluster-devel mailing list Gluster-devel@gluster.org http://www.gluster.org/mailman/listinfo/gluster-devel
Re: [Gluster-devel] Automated bug workflow
Since we have some common interest in proposed design, IMHO let's start doing the implementation by keeping all of this valuable suggestions in mind. If any one interested to volunteer this project, please reply to this thread. Regards Rafi KC - Original Message - From: "Shyam" To: "Niels de Vos" , gluster-devel@gluster.org Sent: Friday, May 29, 2015 11:23:34 PM Subject: Re: [Gluster-devel] Automated bug workflow On 05/29/2015 12:51 PM, Niels de Vos wrote: > Hi all, > > today we had a discussion about how to get the status of reported bugs > more correct and up to date. It is something that has come up several > times already, but now we have a "BIG solution" as Pranith calls it. > > The goal is rather simple, but is requires some thinking about rules and > components that can actually take care of the automation. > > The general user-visible results would be: > > * rfc.sh will ask if this patch it the last one for the bug, or if more > patches are expected > * Gerrit will receive the patch with the answer, and modify the status > of the bug to POST I like to do this manually. > * when the patch is merged, Gerrit will change (or not) the status of > the bug to MODIFIED I like to do this manually too... but automation does not hurt, esp. when I control when the bug moves to POST. > * when a nightly build is made, all bugs that have patches included and > the status of the bug is MODIFIED, the build script will change the > status to ON_QA and set a "fixed in version" This I would like automated, as I am not tracking when it was released (of sorts). But, if I miss the nightly boat, I assume the automation would not pick this up, as a result automation on the MODIFIED step is good, as that would take care of this miss for me. > > This is a simplified view, there are some other cases that we need to > take care of. These are documented in the etherpad linked below. > > We value any input for this, Kaleb and Rafi already gave some, thanks! > Please let us know over email or IRC and we'll update the etherpad. Overall, we can have all of this, but I guess I will possibly never use the POST automation and do that myself. > > Thanks, > Pranith & Niels > > > Etherpad with detailed step by step actions to take: > > https://public.pad.fsfe.org/p/gluster-automated-bug-workflow > > IRC log, where the discussion started: > > https://botbot.me/freenode/gluster-dev/2015-05-29/?msg=40450336&page=2 > > ___ > Gluster-devel mailing list > Gluster-devel@gluster.org > http://www.gluster.org/mailman/listinfo/gluster-devel > ___ Gluster-devel mailing list Gluster-devel@gluster.org http://www.gluster.org/mailman/listinfo/gluster-devel ___ Gluster-devel mailing list Gluster-devel@gluster.org http://www.gluster.org/mailman/listinfo/gluster-devel
Re: [Gluster-devel] Automated bug workflow
On 05/30/2015 03:37 AM, Niels de Vos wrote: On Fri, May 29, 2015 at 01:53:34PM -0400, Shyam wrote: On 05/29/2015 12:51 PM, Niels de Vos wrote: Hi all, today we had a discussion about how to get the status of reported bugs more correct and up to date. It is something that has come up several times already, but now we have a "BIG solution" as Pranith calls it. The goal is rather simple, but is requires some thinking about rules and components that can actually take care of the automation. The general user-visible results would be: * rfc.sh will ask if this patch it the last one for the bug, or if more patches are expected * Gerrit will receive the patch with the answer, and modify the status of the bug to POST I like to do this manually. Could you explain why? * when the patch is merged, Gerrit will change (or not) the status of the bug to MODIFIED I like to do this manually too... but automation does not hurt, esp. when I control when the bug moves to POST. With the current design we have, a patch would be marked with a note that has a boolean like "update bug". It either is manually, or not. There is no plan to make a differenciation between single steps. If there is a good reason to do to, we can of course adjust the plan. * when a nightly build is made, all bugs that have patches included and the status of the bug is MODIFIED, the build script will change the status to ON_QA and set a "fixed in version" This I would like automated, as I am not tracking when it was released (of sorts). But, if I miss the nightly boat, I assume the automation would not pick this up, as a result automation on the MODIFIED step is good, as that would take care of this miss for me. This is something that the release maintainers (try to) do. At the moment, bugs change from MODIFIED to ON_QA only when an alpha/beta/GA release is made, not with nightly builds. This is a simplified view, there are some other cases that we need to take care of. These are documented in the etherpad linked below. We value any input for this, Kaleb and Rafi already gave some, thanks! Please let us know over email or IRC and we'll update the etherpad. Overall, we can have all of this, but I guess I will possibly never use the POST automation and do that myself. You can still have manual control if you prefer. The answer to the question asked by rfc.sh will allow you that. Effectively it will add something like "Update-bug: no" in the commit message, which likely gets stripped out once the patch gets merged. I'd be most interested in your reasoning why you prefer to do it manually. There are extremely few engineers that always remember to set an owner the bug they are fixing, move it to POST and then MODIFIED. How do you keep track of that for the bugs/patches you work on? Maybe it is something that others can use/learn from too. Hmmm... ok I am not good at moving things to MODIFIED, so as stated above I like the part where I can get that for free/automated. For me controlling the movement to POST is something like, taking a few actions by my self and checking things around before marking things as POST. I do this post submitting the patch not pre (I mean that is how I work) as a result when submitting a patch I may not be in a state to ask the automation to move it to POST. That would be the only reason for me stating the same above. Now, if you are curious as to what the steps are that I take etc. :) I cannot list them, I would state this is more a personal preference. Having said this, I do not want the automation to get burdened/complicated on the steps. So, if I need 2/3 steps automated, I am willing to give it a go for the first one (I just need to shift my mental model of working there). Mostly none of my answers above are direct, but unable to be more lucid here. Thanks, Niels Thanks, Pranith & Niels Etherpad with detailed step by step actions to take: https://public.pad.fsfe.org/p/gluster-automated-bug-workflow IRC log, where the discussion started: https://botbot.me/freenode/gluster-dev/2015-05-29/?msg=40450336&page=2 ___ Gluster-devel mailing list Gluster-devel@gluster.org http://www.gluster.org/mailman/listinfo/gluster-devel ___ Gluster-devel mailing list Gluster-devel@gluster.org http://www.gluster.org/mailman/listinfo/gluster-devel
Re: [Gluster-devel] Automated bug workflow
On Fri, May 29, 2015 at 01:53:34PM -0400, Shyam wrote: > On 05/29/2015 12:51 PM, Niels de Vos wrote: > >Hi all, > > > >today we had a discussion about how to get the status of reported bugs > >more correct and up to date. It is something that has come up several > >times already, but now we have a "BIG solution" as Pranith calls it. > > > >The goal is rather simple, but is requires some thinking about rules and > >components that can actually take care of the automation. > > > >The general user-visible results would be: > > > > * rfc.sh will ask if this patch it the last one for the bug, or if more > >patches are expected > > * Gerrit will receive the patch with the answer, and modify the status > >of the bug to POST > > I like to do this manually. Could you explain why? > > * when the patch is merged, Gerrit will change (or not) the status of > >the bug to MODIFIED > > I like to do this manually too... but automation does not hurt, esp. when I > control when the bug moves to POST. With the current design we have, a patch would be marked with a note that has a boolean like "update bug". It either is manually, or not. There is no plan to make a differenciation between single steps. If there is a good reason to do to, we can of course adjust the plan. > > * when a nightly build is made, all bugs that have patches included and > >the status of the bug is MODIFIED, the build script will change the > >status to ON_QA and set a "fixed in version" > > This I would like automated, as I am not tracking when it was released (of > sorts). But, if I miss the nightly boat, I assume the automation would not > pick this up, as a result automation on the MODIFIED step is good, as that > would take care of this miss for me. This is something that the release maintainers (try to) do. At the moment, bugs change from MODIFIED to ON_QA only when an alpha/beta/GA release is made, not with nightly builds. > > > >This is a simplified view, there are some other cases that we need to > >take care of. These are documented in the etherpad linked below. > > > >We value any input for this, Kaleb and Rafi already gave some, thanks! > >Please let us know over email or IRC and we'll update the etherpad. > > Overall, we can have all of this, but I guess I will possibly never use the > POST automation and do that myself. You can still have manual control if you prefer. The answer to the question asked by rfc.sh will allow you that. Effectively it will add something like "Update-bug: no" in the commit message, which likely gets stripped out once the patch gets merged. I'd be most interested in your reasoning why you prefer to do it manually. There are extremely few engineers that always remember to set an owner the bug they are fixing, move it to POST and then MODIFIED. How do you keep track of that for the bugs/patches you work on? Maybe it is something that others can use/learn from too. Thanks, Niels > > > >Thanks, > >Pranith & Niels > > > > > >Etherpad with detailed step by step actions to take: > > > > https://public.pad.fsfe.org/p/gluster-automated-bug-workflow > > > >IRC log, where the discussion started: > > > > https://botbot.me/freenode/gluster-dev/2015-05-29/?msg=40450336&page=2 > > > >___ > >Gluster-devel mailing list > >Gluster-devel@gluster.org > >http://www.gluster.org/mailman/listinfo/gluster-devel > > ___ Gluster-devel mailing list Gluster-devel@gluster.org http://www.gluster.org/mailman/listinfo/gluster-devel
Re: [Gluster-devel] Automated bug workflow
On 05/29/2015 11:23 PM, Shyam wrote: On 05/29/2015 12:51 PM, Niels de Vos wrote: Hi all, today we had a discussion about how to get the status of reported bugs more correct and up to date. It is something that has come up several times already, but now we have a "BIG solution" as Pranith calls it. The goal is rather simple, but is requires some thinking about rules and components that can actually take care of the automation. The general user-visible results would be: * rfc.sh will ask if this patch it the last one for the bug, or if more patches are expected * Gerrit will receive the patch with the answer, and modify the status of the bug to POST I like to do this manually. Instead of just yes/no may be we should also let it accept an input 'disable' so that no automated BUG state modifications are done. * when the patch is merged, Gerrit will change (or not) the status of the bug to MODIFIED I like to do this manually too... but automation does not hurt, esp. when I control when the bug moves to POST. hmm... if we have the 'marker' to say 'disabled' even this part won't be automatically done when the patch is merged. ./rfc.sh needs to take more inputs about what kind of automation is needed and act occardingly i.e. don't do 'moving to POST' but if the bug is already in POST move it to MODIFIED etc. Pranith. * when a nightly build is made, all bugs that have patches included and the status of the bug is MODIFIED, the build script will change the status to ON_QA and set a "fixed in version" This I would like automated, as I am not tracking when it was released (of sorts). But, if I miss the nightly boat, I assume the automation would not pick this up, as a result automation on the MODIFIED step is good, as that would take care of this miss for me. This is a simplified view, there are some other cases that we need to take care of. These are documented in the etherpad linked below. We value any input for this, Kaleb and Rafi already gave some, thanks! Please let us know over email or IRC and we'll update the etherpad. Overall, we can have all of this, but I guess I will possibly never use the POST automation and do that myself. Is this a personal preference or you think improving something in the tool will persuade you to let the tool take care of moving to POST? Pranith Thanks, Pranith & Niels Etherpad with detailed step by step actions to take: https://public.pad.fsfe.org/p/gluster-automated-bug-workflow IRC log, where the discussion started: https://botbot.me/freenode/gluster-dev/2015-05-29/?msg=40450336&page=2 ___ Gluster-devel mailing list Gluster-devel@gluster.org http://www.gluster.org/mailman/listinfo/gluster-devel ___ Gluster-devel mailing list Gluster-devel@gluster.org http://www.gluster.org/mailman/listinfo/gluster-devel ___ Gluster-devel mailing list Gluster-devel@gluster.org http://www.gluster.org/mailman/listinfo/gluster-devel
Re: [Gluster-devel] Automated bug workflow
On 05/29/2015 10:41 PM, Nagaprasad Sathyanarayana wrote: When similar automation was discussed, somebody had raised the concern when more than one patch is associated with a BZ. Either we keep 1:1 between BZ and patch. Otherwise the workflow needs to be improvised to inform gerrit when the last patch is submitted for a BZ so that the state can be appropriately changed. Thoughts? rfc.sh will ask if this patch is the last one for the bug, or if more patches are expected. Based on this input it acts on bugzilla. Pranith Thanks Naga On 29-May-2015, at 10:21 pm, Niels de Vos wrote: Hi all, today we had a discussion about how to get the status of reported bugs more correct and up to date. It is something that has come up several times already, but now we have a "BIG solution" as Pranith calls it. The goal is rather simple, but is requires some thinking about rules and components that can actually take care of the automation. The general user-visible results would be: * rfc.sh will ask if this patch it the last one for the bug, or if more patches are expected * Gerrit will receive the patch with the answer, and modify the status of the bug to POST * when the patch is merged, Gerrit will change (or not) the status of the bug to MODIFIED * when a nightly build is made, all bugs that have patches included and the status of the bug is MODIFIED, the build script will change the status to ON_QA and set a "fixed in version" This is a simplified view, there are some other cases that we need to take care of. These are documented in the etherpad linked below. We value any input for this, Kaleb and Rafi already gave some, thanks! Please let us know over email or IRC and we'll update the etherpad. Thanks, Pranith & Niels Etherpad with detailed step by step actions to take: https://public.pad.fsfe.org/p/gluster-automated-bug-workflow IRC log, where the discussion started: https://botbot.me/freenode/gluster-dev/2015-05-29/?msg=40450336&page=2 ___ Gluster-devel mailing list Gluster-devel@gluster.org http://www.gluster.org/mailman/listinfo/gluster-devel ___ Gluster-devel mailing list Gluster-devel@gluster.org http://www.gluster.org/mailman/listinfo/gluster-devel ___ Gluster-devel mailing list Gluster-devel@gluster.org http://www.gluster.org/mailman/listinfo/gluster-devel
Re: [Gluster-devel] Automated bug workflow
On 05/29/2015 12:51 PM, Niels de Vos wrote: Hi all, today we had a discussion about how to get the status of reported bugs more correct and up to date. It is something that has come up several times already, but now we have a "BIG solution" as Pranith calls it. The goal is rather simple, but is requires some thinking about rules and components that can actually take care of the automation. The general user-visible results would be: * rfc.sh will ask if this patch it the last one for the bug, or if more patches are expected * Gerrit will receive the patch with the answer, and modify the status of the bug to POST I like to do this manually. * when the patch is merged, Gerrit will change (or not) the status of the bug to MODIFIED I like to do this manually too... but automation does not hurt, esp. when I control when the bug moves to POST. * when a nightly build is made, all bugs that have patches included and the status of the bug is MODIFIED, the build script will change the status to ON_QA and set a "fixed in version" This I would like automated, as I am not tracking when it was released (of sorts). But, if I miss the nightly boat, I assume the automation would not pick this up, as a result automation on the MODIFIED step is good, as that would take care of this miss for me. This is a simplified view, there are some other cases that we need to take care of. These are documented in the etherpad linked below. We value any input for this, Kaleb and Rafi already gave some, thanks! Please let us know over email or IRC and we'll update the etherpad. Overall, we can have all of this, but I guess I will possibly never use the POST automation and do that myself. Thanks, Pranith & Niels Etherpad with detailed step by step actions to take: https://public.pad.fsfe.org/p/gluster-automated-bug-workflow IRC log, where the discussion started: https://botbot.me/freenode/gluster-dev/2015-05-29/?msg=40450336&page=2 ___ Gluster-devel mailing list Gluster-devel@gluster.org http://www.gluster.org/mailman/listinfo/gluster-devel ___ Gluster-devel mailing list Gluster-devel@gluster.org http://www.gluster.org/mailman/listinfo/gluster-devel
Re: [Gluster-devel] Automated bug workflow
When similar automation was discussed, somebody had raised the concern when more than one patch is associated with a BZ. Either we keep 1:1 between BZ and patch. Otherwise the workflow needs to be improvised to inform gerrit when the last patch is submitted for a BZ so that the state can be appropriately changed. Thoughts? Thanks Naga > On 29-May-2015, at 10:21 pm, Niels de Vos wrote: > > Hi all, > > today we had a discussion about how to get the status of reported bugs > more correct and up to date. It is something that has come up several > times already, but now we have a "BIG solution" as Pranith calls it. > > The goal is rather simple, but is requires some thinking about rules and > components that can actually take care of the automation. > > The general user-visible results would be: > > * rfc.sh will ask if this patch it the last one for the bug, or if more > patches are expected > * Gerrit will receive the patch with the answer, and modify the status > of the bug to POST > * when the patch is merged, Gerrit will change (or not) the status of > the bug to MODIFIED > * when a nightly build is made, all bugs that have patches included and > the status of the bug is MODIFIED, the build script will change the > status to ON_QA and set a "fixed in version" > > This is a simplified view, there are some other cases that we need to > take care of. These are documented in the etherpad linked below. > > We value any input for this, Kaleb and Rafi already gave some, thanks! > Please let us know over email or IRC and we'll update the etherpad. > > Thanks, > Pranith & Niels > > > Etherpad with detailed step by step actions to take: > >https://public.pad.fsfe.org/p/gluster-automated-bug-workflow > > IRC log, where the discussion started: > >https://botbot.me/freenode/gluster-dev/2015-05-29/?msg=40450336&page=2 > > ___ > Gluster-devel mailing list > Gluster-devel@gluster.org > http://www.gluster.org/mailman/listinfo/gluster-devel > > ___ Gluster-devel mailing list Gluster-devel@gluster.org http://www.gluster.org/mailman/listinfo/gluster-devel
[Gluster-devel] Automated bug workflow
Hi all, today we had a discussion about how to get the status of reported bugs more correct and up to date. It is something that has come up several times already, but now we have a "BIG solution" as Pranith calls it. The goal is rather simple, but is requires some thinking about rules and components that can actually take care of the automation. The general user-visible results would be: * rfc.sh will ask if this patch it the last one for the bug, or if more patches are expected * Gerrit will receive the patch with the answer, and modify the status of the bug to POST * when the patch is merged, Gerrit will change (or not) the status of the bug to MODIFIED * when a nightly build is made, all bugs that have patches included and the status of the bug is MODIFIED, the build script will change the status to ON_QA and set a "fixed in version" This is a simplified view, there are some other cases that we need to take care of. These are documented in the etherpad linked below. We value any input for this, Kaleb and Rafi already gave some, thanks! Please let us know over email or IRC and we'll update the etherpad. Thanks, Pranith & Niels Etherpad with detailed step by step actions to take: https://public.pad.fsfe.org/p/gluster-automated-bug-workflow IRC log, where the discussion started: https://botbot.me/freenode/gluster-dev/2015-05-29/?msg=40450336&page=2 ___ Gluster-devel mailing list Gluster-devel@gluster.org http://www.gluster.org/mailman/listinfo/gluster-devel
