On Fri, Mar 04, 2016 at 09:23:19AM -0500, Emilien Macchi wrote: > That's not the name of any Summit's talk, it's just an e-mail I wanted > to write for a long time. > > It is an attempt to expose facts or things I've heard a lot; and bring > constructive thoughts about why it's challenging to contribute in > TripleO project. > > > 1/ "I don't review this patch, we don't have CI coverage." > > One thing I've noticed in TripleO is that a very few people are involved > in CI work. > In my opinion, CI system is more critical than any feature in a product. > Developing Software without tests is a bit like http://goo.gl/OlgFRc > All people - specially core - in the project should be involved in CI > work. If you are TripleO core and you don't contribute on CI, you might > ask yourself why. > As somebody who contributes to openstack-infa and knows most of the ins and outs of OpenStack CI, I often wish the TripleO CI would be more inline with openstack-infa. Right now, TripleO CI is a black hole to me. I understand there are some reason to have separate CI (eg: baremetal provisioning) but it would be nice to revisit the current setup and see if we can move more inline with openstack-infra.
For the simple reason, having common tooling means I can contribute to TripleO CI if needed. > > 2/ "I don't review this patch, CI is broken." > > Another thing I've noticed in TripleO is that when CI is broken, again, > a very few people are actually working on fixing failures. > My experience over the last years taught me to stop my daily work when > CI is broken and fix it asap. > See my above comment. I think this would go a great way to helping the team. > > 3/ "I don't review it, because this feature / code is not my area". > > My first though is "Aren't we supposed to be engineers and learn new areas?" > My second though is that I think we have a problem with TripleO Heat > Templates. > THT or TripleO Heat Templates's code is 80% of Puppet / Hiera. If > TripleO core say "I'm not familiar with Puppet", we have a problem here, > isn't? > Maybe should we split this repository? Or revisit the list of people who > can +2 patches on THT. > > > 4/ Patches are stalled. Most of the time. > > Over the last 12 months, I've pushed a lot of patches in TripleO and one > thing I've noticed is that if I don't ping people, my patch got no > review. And I have to rebase it, every week, because the interface > changed. I got +2, cool ! Oh, merge conflict. Rebasing. Waiting for +2 > again... and so on.. > > I personally spent 20% of my time to review code, every day. > I wrote a blog post about how I'm doing review, with Gertty: > http://my1.fr/blog/reviewing-puppet-openstack-patches/ > I suggest TripleO folks to spend more time on reviews, for some reasons: > > * decreasing frustration from contributors > * accelerate development process > * teach new contributors to work on TripleO, and eventually scale-up the > core team. It's a time investment, but worth it. > > In Puppet team, we have weekly triage sessions and it's pretty helpful. > > > 5/ Most of the tests are run... manually. > > How many times I've heard "I've tested this patch locally, and it does > not work so -1". > > The only test we do in current CI is a ping to an instance. Seriously? > Most of OpenStack CIs (Fuel included), run Tempest, for testing APIs and > real scenarios. And we run a ping. > That's similar to 1/ but I wanted to raise it too. > > > > If we don't change our way to work on TripleO, people will be more > frustrated and reduce contributions at some point. > I hope from here we can have a open and constructive discussion to try > to improve the TripleO project. > > Thank you for reading so far. > -- > Emilien Macchi > So for me, I'd love to help more but having to context shift into TripleO CI is a deal breaker for me (and more of -infra is I was a betting man). So, anything I can do to help move things like base images or using AFS mirrors into TripleO I am happy to help. However, having the TripleO team maintain CI themselves doesn't seem to be the best case scenario. > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
