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

Reply via email to