[Gluster-infra] [Bug 1423002] Changes needed in infra to accommodate move to github for issue tracking and updates

bugzilla at redhat.com bugzilla at redhat.com
Fri Feb 17 20:18:41 UTC 2017


https://bugzilla.redhat.com/show_bug.cgi?id=1423002



--- Comment #3 from Michael Scherer <misc at zarb.org> ---
> That was to gauge if we can even do this, and we have some semblance of a 
> plan, before going to devel.

Ok, that's fair.
But the communication did look a bit more "we are gonna do that, here is the
plan", due to the presence of a actual planning. It is good to have one, but
this tend to make people thing a different things than a discussion :)

I still think this should start on -devel, but I can see how people prefer to
start small, I did in the past too (and got burned for that).


> - I did not understand the gerrit and Jenkins not having ACL part, how/what 
> does that mean?

So my point is that having private bugs is useless if the CI is public, and if
gerrit is public, as they are part of the workflow for fixing security bugs.
Afaik, both are public (but I can be wrong). I do not know what is the workflow
for fixing bugs. Are they discussed out of gerrit, tested out of jenkins, etc ?

Maybe we didn't got enough to have a process and maybe that's the time.

If we decide that privates bugs are a thing we need and/or use, then we have to
make sure the whole workflow is as private as the bug. 

If we decide that we are not gonna do embargos (which is reasonable, since RH
Security Team think they should be exceptional), then the requirement for
private bugs disappear.  

But again, I want to make sure we are clear on that, and clear with people
handling bugs.

> Hmmm... can we get more specifics about the problems? So that we can evaluate 
> the same. Also, a person dedicated to the automation needs work!

So the issue they had had mostly with the API limit. Ansible seems to have a
rather huge volume of requests, and github do limit them. Github issues do not
scale well for a big project, either from a ressources point of view (cf limit
on API) and from a design/UX point of view (ie, bugzilla is slightly more
advanced). So people tend to automate lots of things there. 

The bot also do automated triaging (ie, adding various labels) for queries. So
it has to go over all issues, etc, etc.

I do not say this is not doable, but we have to take that in account. jctanner
is the guy in charge of that, he can tell more.

> Would it be possible to prototype some changes in gerrit-stage (like the 
> hooks for example?) so that when devs experience this, it is well known what 
> needs to be done in the future and we can get better feedback on this.

Mhh I guess it is up to nigel to decide if he use it or not. We still can't
give a test instance of gerrit easily and we are working on pushing that to
ansible. So I would prefer we finish that, so we can scrap and reinstall if
needed. But if nigel is ok, I do not have strong objection to that.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=ACIpCsu6H2&a=cc_unsubscribe


More information about the Gluster-infra mailing list