I'll make a second proposal.
Each plugin could have their own IRC channel (several already do). We
could invite pulpbot to each channel and make whatever (hopefully minor?)
modifications are necessary to restrict triages in those channels to their
associated plugin and also store the logs under d
On Wed, Mar 7, 2018 at 8:58 AM, Robin Chan wrote:
> I would like to hear from QE since I know they had some concerns here.
> Since the Pulp QE team is much smaller, having to manage attendance to
> multiple traige's per week is more of a strain on them to have the
> interruptions and their expert
I would like to hear from QE since I know they had some concerns here.
Since the Pulp QE team is much smaller, having to manage attendance to
multiple traige's per week is more of a strain on them to have the
interruptions and their expertise may not be as clearly delineated as a
larger team which
It makes sense to let to mini-teams to triage the issues, but the decision
whether to put or not on the sprint still should be addressed by whole
team, or at least acknowledged.
Regards,
Ina Panova
Software Engineer| Pulp| Red Hat Inc.
"Do not go where the path may lead,
go instead w
I'm fine with this. I dislike the idea of multiple meetings but I think
that what will end up happening is that the issue load for each project
individually will be low enough that they will can and will all end up
being handled asynchronously as they come in. I also think that letting
each plugi
Currently the biweekly triage query includes a large number of unrelated
topics: Pulp, RPM, Puppet, Python, Ansible (the pulp3 role plugin),
Packaging, OS Tree, Crane, Docker, External, and File Support. These are
all different top-level pulp.plan.io projects in Redmine. These are so many
specializ
