everett.toews at cybera
Apr 30, 2012, 9:12 AM
Post #3 of 7
I'm always an advocate for one less thing. If it makes sense to do so, I
would rather have two things than three. It's simply a matter of less
complexity and less confusion. I'm not convinced we need three lists.
Duncan, you describe the audience for the openstack list as "folks who are
not code contributors, but standing up OpenStack itself". To me that
sounds, at least in part, to be the role of Ops people.
It's strange to me that we would take the existing mailing list
openstack-operators and move the Ops people on it to the openstack list and
repurpose the openstack-operators for DevOps people.
It's even stranger to me that a list devoted to DevOps would exclude the
Ops people, the openstack-operators for DevOps and openstack for Ops split.
One of the major tenants of DevOps is to be inclusive of Ops. I think the
new DevOps community could learn a lot from the kinds of questions that Ops
people are asking about OpenStack. And vice versa, the Ops people could
give input on solutions being worked on by DevOps.
What is your justification for excluding the Ops from DevOps?
And sorry, I don't buy the "don't have the time to devise a solution
for creating appropriate filters" argument. It takes 10 seconds to create a
filter to shunt mailing list traffic to another folder/label away from your
To me it seems like you don't want to be on the Dev list and you don't want
to be on the Ops list, you want your own DevOps list. I *applaud* the
re-jump-start of the OpenStack DevOps community but I don't think isolating
yourselves is the way to go.
I agree that it might take a cycle to sort out and I agree that we should
make one small change at the time, measure/evaluate and keep changing as
needed. If one list or the other does not have much traction by the next
Summit, we should consider a merge.
But even before then, please do consider whether or not the DevOps
community really needs its own list.
On Fri, Apr 27, 2012 at 3:43 PM, Duncan McGreggor <duncan [at] dreamhost>wrote:
> On Fri, Apr 27, 2012 at 3:52 PM, Everett Toews <everett.toews [at] cybera>
> > I like this idea but what happens to the openstack-operators list in this
> > scenario?
> > I don't think we'd want to have the openstack and openstack-operators
> > going along in parallel since it sounds like they would overlap. I
> > that the members of the openstack-operators list would be (automatically
> > manually) migrated to the openstack list. Then the openstack-operators
> > would be set to read-only or maybe even removed completely to avoid
> > confusion.
> > Comments? Feedback?
> Hrm. One of the things that came out of the Design Summit discussions
> around DevOps was that the OpenStack "DevOps" sub-community doesn't
> really feel like it has a voice. As a result, I'd be loathe to remove
> that venue for discussion right now, even if it's only of symbolic
> That being said, I propose that something along the following lines
> could happen:
> * intense dev work, collaboration, etc., happening on openstack-dev@
> * general usage of openstack questions by folks who are not code
> contributors, but standing up OpenStack itself, happening on
> * conversations around DevOps in particular (the wide spectrum of
> definitions that comprise "DevOps" in various people's minds)
> happening in openstack-operators@
> In helping jump-start (or re-jump-start) the OpenStack DevOps
> community, I'd really like to have a dedicated place for
> announcements, questions, etc. Even if we spent some time pointing
> folks to more detailed, technical resources.
> In hallway conversations at the summit (and in various emails and
> phone calls since then), people who consider themselves "DevOps" have
> expressed concern over the possibility that the operators list would
> go away. They are overwhelmed by the volume of traffic on the
> openstack list, and don't have the time to devise a solution for
> creating appropriate filters, etc.
> That objection may simply go away with the new mail list split.
> But if openstack-operators has become a property valuable to community
> members, we shouldn't just get rid of it because it doesn't make
> logical sense. We should make sure that folks are ready to transition
> to another location for their DevOps needs.
> And that might take a cycle to sort out...