[Gluster-devel] Automated bug workflow

[Pranith Kumar Karampuri]

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" <srangana at redhat.com>
> To: "Niels de Vos" <ndevos at redhat.com>, gluster-devel at 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 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