[Gluster-devel] Automated bug workflow

[Pranith Kumar Karampuri]

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 at gluster.org
>> http://www.gluster.org/mailman/listinfo/gluster-devel
>>
> _______________________________________________
> Gluster-devel mailing list
> Gluster-devel at gluster.org
> http://www.gluster.org/mailman/listinfo/gluster-devel