Re: [Gluster-devel] Proposal to change Gerrit -> Bugzilla updates

2018-09-11 Thread Amar Tumballi 
On Tue, Sep 11, 2018 at 9:25 PM, Atin Mukherjee  wrote:

>
>
> On Mon, Sep 10, 2018 at 7:09 PM Shyam Ranganathan 
> wrote:
>
>> On 09/10/2018 08:37 AM, Nigel Babu wrote:
>> > Hello folks,
>> >
>> > We now have review.gluster.org  as an
>> > external tracker on Bugzilla. Our current automation when there is a
>> > bugzilla attached to a patch is as follows:
>> >
>> > 1. When a new patchset has "Fixes: bz#1234" or "Updates: bz#1234", we
>> > will post a comment to the bug with a link to the patch and change the
>> > status to POST. 2. When the patchset is merged, if the commit said
>> > "Fixes", we move the status to MODIFIED.
>> >
>> > I'd like to propose the following improvements:
>> > 1. Add the Gerrit URL as an external tracker to the bug.
>>
>> My assumption here is that for each patch that mentions a BZ, an
>> additional tracker would be added to the tracker list, right?
>>
>> Further assumption (as I have not used trackers before) is that this
>> would reduce noise as comments in the bug itself, right?
>>
>> In the past we have reduced noise by not commenting on the bug (or
>> github issue) every time the patch changes, so we get 2 comments per
>> patch currently, with the above change we would just get one and that
>> too as a terse external reference (see [1], based on my
>> test/understanding).
>>
>> What we would lose is the commit details when the patch is merged in the
>> BZ, as far as I can tell based on the changes below. These are useful
>> and would like these to be retained in case they are not.
>>
>
> The commit at the bugzilla has been extremely helpful, in fact I could
> refer to the commit details to understand what has been fixed for the bug
> when r.g.o was down in couple of instances. So my vote would be to stick to
> the same.
>
>
>> > 2. When a patch is merged, only change state of the bug if needed. If
>> > there is no state change, do not add an additional message. The external
>> > tracker state should change reflecting the state of the review.
>>
>> I added a tracker to this bug [1], but not seeing the tracker state
>> correctly reflected in BZ, is this work that needs to be done?
>>
>> > 3. Assign the bug to the committer. This has edge cases, but it's best
>> > to at least handle the easy ones and then figure out edge cases later.
>> > The experience is going to be better than what it is right now.
>>
>
> Assign the bug to the committer - When? Is it when the first patch set is
> posted or is it when the patch(es) are merged and bug is moved to MODIFIED?
>
>
This is one good reason for having both bugzilla and github (with label
'Type:Bug') for handling bugs for the project. That way, most of the
regular developers can have bugzilla account to post the patch, but for any
new developer, posting a patch against github issue, no need for one more
account.



>
>> Is the above a reference to just the "assigned to", or overall process?
>> If overall can you elaborate a little more on why this would be better
>> (I am not saying it is not, attempting to understand how you see it).
>>
>> >
>> > Please provide feedback/comments by end of day Friday. I plan to add
>> > this activity to the next Infra team sprint that starts on Monday (Sep
>> 17).
>>
>> [1] https://bugzilla.redhat.com/show_bug.cgi?id=1619423
>> ___
>> Gluster-devel mailing list
>> Gluster-devel@gluster.org
>> https://lists.gluster.org/mailman/listinfo/gluster-devel
>>
>
> ___
> Gluster-devel mailing list
> Gluster-devel@gluster.org
> https://lists.gluster.org/mailman/listinfo/gluster-devel
>



-- 
Amar Tumballi (amarts)
___
Gluster-devel mailing list
Gluster-devel@gluster.org
https://lists.gluster.org/mailman/listinfo/gluster-devel

Re: [Gluster-devel] Proposal to change Gerrit -> Bugzilla updates

2018-09-11 Thread Atin Mukherjee 
On Mon, Sep 10, 2018 at 7:09 PM Shyam Ranganathan 
wrote:

> On 09/10/2018 08:37 AM, Nigel Babu wrote:
> > Hello folks,
> >
> > We now have review.gluster.org  as an
> > external tracker on Bugzilla. Our current automation when there is a
> > bugzilla attached to a patch is as follows:
> >
> > 1. When a new patchset has "Fixes: bz#1234" or "Updates: bz#1234", we
> > will post a comment to the bug with a link to the patch and change the
> > status to POST. 2. When the patchset is merged, if the commit said
> > "Fixes", we move the status to MODIFIED.
> >
> > I'd like to propose the following improvements:
> > 1. Add the Gerrit URL as an external tracker to the bug.
>
> My assumption here is that for each patch that mentions a BZ, an
> additional tracker would be added to the tracker list, right?
>
> Further assumption (as I have not used trackers before) is that this
> would reduce noise as comments in the bug itself, right?
>
> In the past we have reduced noise by not commenting on the bug (or
> github issue) every time the patch changes, so we get 2 comments per
> patch currently, with the above change we would just get one and that
> too as a terse external reference (see [1], based on my
> test/understanding).
>
> What we would lose is the commit details when the patch is merged in the
> BZ, as far as I can tell based on the changes below. These are useful
> and would like these to be retained in case they are not.
>

The commit at the bugzilla has been extremely helpful, in fact I could
refer to the commit details to understand what has been fixed for the bug
when r.g.o was down in couple of instances. So my vote would be to stick to
the same.


> > 2. When a patch is merged, only change state of the bug if needed. If
> > there is no state change, do not add an additional message. The external
> > tracker state should change reflecting the state of the review.
>
> I added a tracker to this bug [1], but not seeing the tracker state
> correctly reflected in BZ, is this work that needs to be done?
>
> > 3. Assign the bug to the committer. This has edge cases, but it's best
> > to at least handle the easy ones and then figure out edge cases later.
> > The experience is going to be better than what it is right now.
>

Assign the bug to the committer - When? Is it when the first patch set is
posted or is it when the patch(es) are merged and bug is moved to MODIFIED?


> Is the above a reference to just the "assigned to", or overall process?
> If overall can you elaborate a little more on why this would be better
> (I am not saying it is not, attempting to understand how you see it).
>
> >
> > Please provide feedback/comments by end of day Friday. I plan to add
> > this activity to the next Infra team sprint that starts on Monday (Sep
> 17).
>
> [1] https://bugzilla.redhat.com/show_bug.cgi?id=1619423
> ___
> Gluster-devel mailing list
> Gluster-devel@gluster.org
> https://lists.gluster.org/mailman/listinfo/gluster-devel
>
___
Gluster-devel mailing list
Gluster-devel@gluster.org
https://lists.gluster.org/mailman/listinfo/gluster-devel

Re: [Gluster-devel] [Gluster-infra] Freebsd builder upgrade to 10.4, maybe 11

2018-09-11 Thread Nigel Babu 
On Tue, Sep 11, 2018 at 7:06 PM Michael Scherer  wrote:

> And... rescue mode is not working. So the server is down until
> Rackspace fix it.
>
> Can someone disable the freebsd smoke test, as I think our 2nd builder
> is not yet building fine ?
>


Disabled. Please do not merge any JJB review requests until this is fixed.

-- 
nigelb
___
Gluster-devel mailing list
Gluster-devel@gluster.org
https://lists.gluster.org/mailman/listinfo/gluster-devel

Re: [Gluster-devel] Freebsd builder upgrade to 10.4, maybe 11

2018-09-11 Thread Michael Scherer 
Le mardi 11 septembre 2018 à 13:55 +0200, Michael Scherer a écrit :
> Hi,
> 
> so it seems our working builder (the one on rackspace) is still
> running
> a EOL version of Freebsd. I am about to upgrade it to 10.4, so we can
> expect a reboot.
> 
> Then we will likely need to take care of upgrading to 11.0, unless
> someone is against, cause 10.4 is EOL end of october.

So, seems the builder did reboot but without network, cause some cloud-
init issue. I am on it.

-- 
Michael Scherer
Sysadmin, Community Infrastructure and Platform, OSAS



signature.asc
Description: This is a digitally signed message part
___
Gluster-devel mailing list
Gluster-devel@gluster.org
https://lists.gluster.org/mailman/listinfo/gluster-devel

[Gluster-devel] Freebsd builder upgrade to 10.4, maybe 11

2018-09-11 Thread Michael Scherer 
Hi,

so it seems our working builder (the one on rackspace) is still running
a EOL version of Freebsd. I am about to upgrade it to 10.4, so we can
expect a reboot.

Then we will likely need to take care of upgrading to 11.0, unless
someone is against, cause 10.4 is EOL end of october.




-- 
Michael Scherer
Sysadmin, Community Infrastructure and Platform, OSAS



signature.asc
Description: This is a digitally signed message part
___
Gluster-devel mailing list
Gluster-devel@gluster.org
https://lists.gluster.org/mailman/listinfo/gluster-devel

Re: [Gluster-devel] Proposal to change Gerrit -> Bugzilla updates

2018-09-11 Thread Nigel Babu 
On Mon, Sep 10, 2018 at 7:08 PM Shyam Ranganathan 
wrote:

> My assumption here is that for each patch that mentions a BZ, an
> additional tracker would be added to the tracker list, right?
>

Correct.


>
> Further assumption (as I have not used trackers before) is that this
> would reduce noise as comments in the bug itself, right?
>

There is two goals - One two see all the patches posted at the start of the
bug. The reduction of noise is a good bonus to have.


>
> In the past we have reduced noise by not commenting on the bug (or
> github issue) every time the patch changes, so we get 2 comments per
> patch currently, with the above change we would just get one and that
> too as a terse external reference (see [1], based on my
> test/understanding).
>
> What we would lose is the commit details when the patch is merged in the
> BZ, as far as I can tell based on the changes below. These are useful
> and would like these to be retained in case they are not.
>

I'm okay to do that.


>
> > 2. When a patch is merged, only change state of the bug if needed. If
> > there is no state change, do not add an additional message. The external
> > tracker state should change reflecting the state of the review.
>
> I added a tracker to this bug [1], but not seeing the tracker state
> correctly reflected in BZ, is this work that needs to be done?
>

Huh. That's odd. This works way better with other trackers. I'll follow up
with the Bugzilla folks to see how to chase this down. Ideally it should
show the state change (however, with no notification on the bug as far as I
can understand. Given that you're for keeping the notification, at this
point, all that's extra is we'll add a tracker for every new bug.


>
> > 3. Assign the bug to the committer. This has edge cases, but it's best
> > to at least handle the easy ones and then figure out edge cases later.
> > The experience is going to be better than what it is right now.
>
> Is the above a reference to just the "assigned to", or overall process?
> If overall can you elaborate a little more on why this would be better
> (I am not saying it is not, attempting to understand how you see it).
>

It's a reference just to the "assigned to". I don't yet know who has their
gerrit emails mapped to their bugzilla IDs. Automatic assigning will only
work if that matrix is perfectly matched. So, when we start doing this, it
will fail for a bunch of users. We'll have to tune this over time to
develop a matrix of Gerrit email -> Bugzilla email.


>
> >
> > Please provide feedback/comments by end of day Friday. I plan to add
> > this activity to the next Infra team sprint that starts on Monday (Sep
> 17).
>
> [1] https://bugzilla.redhat.com/show_bug.cgi?id=1619423
>


-- 
nigelb
___
Gluster-devel mailing list
Gluster-devel@gluster.org
https://lists.gluster.org/mailman/listinfo/gluster-devel

Re: [Gluster-devel] Proposal to change Gerrit -> Bugzilla updates

2018-09-11 Thread Niels de Vos 
On Mon, Sep 10, 2018 at 09:38:04AM -0400, Shyam Ranganathan wrote:
> On 09/10/2018 08:37 AM, Nigel Babu wrote:
> > Hello folks,
> > 
> > We now have review.gluster.org  as an
> > external tracker on Bugzilla. Our current automation when there is a
> > bugzilla attached to a patch is as follows:
> > 
> > 1. When a new patchset has "Fixes: bz#1234" or "Updates: bz#1234", we
> > will post a comment to the bug with a link to the patch and change the
> > status to POST. 2. When the patchset is merged, if the commit said
> > "Fixes", we move the status to MODIFIED.
> > 
> > I'd like to propose the following improvements:
> > 1. Add the Gerrit URL as an external tracker to the bug.
> 
> My assumption here is that for each patch that mentions a BZ, an
> additional tracker would be added to the tracker list, right?
> 
> Further assumption (as I have not used trackers before) is that this
> would reduce noise as comments in the bug itself, right?
> 
> In the past we have reduced noise by not commenting on the bug (or
> github issue) every time the patch changes, so we get 2 comments per
> patch currently, with the above change we would just get one and that
> too as a terse external reference (see [1], based on my test/understanding).

This has my preference. The information of a patch being posted has
little relevance for a bug reporter. The bug moving to POST should be an
indication that work is being done. The link to the patch is available
so the status can be tracked pretty easily if needed.

> What we would lose is the commit details when the patch is merged in the
> BZ, as far as I can tell based on the changes below. These are useful
> and would like these to be retained in case they are not.

I agree with this. Specially once a patch has been merged, a comment
with the commit hash, subject and message is extremely helpful.

> > 2. When a patch is merged, only change state of the bug if needed. If
> > there is no state change, do not add an additional message. The external
> > tracker state should change reflecting the state of the review.
> 
> I added a tracker to this bug [1], but not seeing the tracker state
> correctly reflected in BZ, is this work that needs to be done?

That indeed looks close to useless. If there is no summary/subject or
status in the external tracker table, we do not gain a lot. I hope this
can be fixed soon.

> > 3. Assign the bug to the committer. This has edge cases, but it's best
> > to at least handle the easy ones and then figure out edge cases later.
> > The experience is going to be better than what it is right now.
> 
> Is the above a reference to just the "assigned to", or overall process?
> If overall can you elaborate a little more on why this would be better
> (I am not saying it is not, attempting to understand how you see it).

I assume this is the "assigned to" value in Bugzilla. Many BZs are
currently assigned to b...@gluster.org even when the BZ is not in NEW
anymore. Asking for a status update in the BZ is therefore more
difficult as need to be (useless to select NEEDINFO=assignee).

Thanks,
Niels

> 
> > 
> > Please provide feedback/comments by end of day Friday. I plan to add
> > this activity to the next Infra team sprint that starts on Monday (Sep 17).
> 
> [1] https://bugzilla.redhat.com/show_bug.cgi?id=1619423
> ___
> Gluster-devel mailing list
> Gluster-devel@gluster.org
> https://lists.gluster.org/mailman/listinfo/gluster-devel
___
Gluster-devel mailing list
Gluster-devel@gluster.org
https://lists.gluster.org/mailman/listinfo/gluster-devel