On Wed, Aug 13, 2014 at 5:37 AM, Mark McLoughlin <mar...@redhat.com>
wrote:
On Fri, 2014-08-08 at 15:36 -0700, Devananda van der Veen wrote:
On Tue, Aug 5, 2014 at 10:02 AM, Monty Taylor
<mord...@inaugust.com> wrote:
> Yes.
>
> Additionally, and I think we've been getting better at this in
the 2 cycles
> that we've had an all-elected TC, I think we need to learn how to
say no on
> technical merit - and we need to learn how to say "thank you for
your
> effort, but this isn't working out" Breaking up with someone is
hard to do,
> but sometimes it's best for everyone involved.
>
I agree.
The challenge is scaling the technical assessment of projects. We're
all busy, and digging deeply enough into a new project to make an
accurate assessment of it is time consuming. Some times, there are
impartial subject-matter experts who can spot problems very quickly,
but how do we actually gauge fitness?
Yes, it's important the TC does this and it's obvious we need to get a
lot better at it.
The Marconi architecture threads are an example of us trying harder
(and
kudos to you for taking the time), but it's a little disappointing how
it has turned out. On the one hand there's what seems like a "this
doesn't make any sense" gut feeling and on the other hand an earnest,
but hardly bite-sized justification for how the API was chosen and how
it lead to the architecture. Frustrating that appears to not be
resulting in either improved shared understanding, or improved
architecture. Yet everyone is trying really hard.
Letting the industry field-test a project and feed their experience
back into the community is a slow process, but that is the best
measure of a project's success. I seem to recall this being an
implicit expectation a few years ago, but haven't seen it discussed
in
a while.
I think I recall us discussing a "must have feedback that it's
successfully deployed" requirement in the last cycle, but we
recognized
that deployers often wait until a project is integrated.
I'm not suggesting we make a policy of it, but if, after a
few cycles, a project is still not meeting the needs of users, I
think
that's a very good reason to free up the hold on that role within
the
stack so other projects can try and fill it (assuming that is even a
role we would want filled).
I'm certainly not against discussing de-integration proposals. But I
could imagine a case for de-integrating every single one of our
integrated projects. None of our software is perfect. How do we make
sure we approach this sanely, rather than run the risk of someone
starting a witch hunt because of a particular pet peeve?
I could imagine a really useful dashboard showing the current state of
projects along a bunch of different lines - summary of latest
deployments data from the user survey, links to known scalability
issues, limitations that operators should take into account, some
capturing of trends so we know whether things are improving. All of
this
data would be useful to the TC, but also hugely useful to operators.
+1
This seems to be the only way to determine when a project isn't working
out for the users in the community.
With such unbiased data being available, it would make a great case for
why de-integration could happen. It would then allow the project to go
back and fix itself, or allow for a replacement to be created that
doesn't have the same set of limitations/problems. This would seem like
a way that let's the project that works for users best to eventually be
selected (survival of the fittest); although we also have to be
careful, software isn't static and instead can be reshaped and molded
and we should give the project that has issues a chance to reshape
itself (giving the benefit of the doubt vs not).
Mark.
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
