[Gluster-devel] Automated bug workflow
Pranith Kumar Karampuri
pkarampu at redhat.com
Tue Jul 7 09:18:22 UTC 2015
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?
> 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.
>> Pranith & Niels
>> Etherpad with detailed step by step actions to take:
>> IRC log, where the discussion started:
>> Gluster-devel mailing list
>> Gluster-devel at gluster.org
> Gluster-devel mailing list
> Gluster-devel at gluster.org
More information about the Gluster-devel