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