On 03/04/2016 03:23 PM, 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.
hi Emilien,
thanks for bringing this up, it's not an easy topic and yet of most
crucial. As a core contributors I feel, to some extent, responsible for
the current status of things and I think it's time for us to reflect
more about what we can, individually, do.
I have some ideas but I want to start by commenting to your points.
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.
Agreed, we need more 'eyes' on out CI to cope with both the infra and
the inavoidable failures due to changes/bugs in the puppet modules or
openstack itself.
But there is more hiding behind this problem ... we already have quite a
number of optional and even pluggable features in TripleO and we're even
designing an interface to make this easier; testing them all isn't going
to happen. So we'll always hit something we don't have coverage for.
Let's have a conversation on how we can improve coverage at the summit!
Maybe we can make simply make our CI scenarios more variegated/complex
in the attempt to touch more features?
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.
Agreed. More eyes and more coverage to increase its dependability.
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.
Not sure here, I find that manifests and templates are pretty much
"meant to go together" so I am worried that a split could solve some
problems but also cause others.
This said, let's be honest, an effective patch for THT requires a good
understanding of many different problems which can be TripleO specific
(eg. implications on upgrades), tooling specific (eg. Heat/Puppet),
OpenStack specific (eg. cooperation with other, optional, features) so I
have myself skipped changes when I didn't feel comfortable with it.
But one problem which I think is more recently slowing reviews and which
is somewhat concause of 3) is that we're not dealing too well with code
duplication in the yamls and with conditional logic in the manifests.
Maybe we could stop and think a together about new HOT functionalities
which could help us? Interesting for the summit as well?
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.
I'm inclined to think that this is a bit of a consequence of 1), 2) and
3) together.
In Puppet team, we have weekly triage sessions and it's pretty helpful.
Right. I think we experimented with something like this before but it
was probably perceived as an emergency measure so we put it on a side
after a while.
I remember we had a list of 'hot reviews' which we would review during
the weekly meetings. But it isn't trivial to understand which type of
review is considered hot. What is the purpose of the puppet team
triaging? To find old reviews? Mergeable reviews? To dropping stale
reviews? To speed up bug fixes? To get attention on features?
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.
I'd say a consequence of 1) as well
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.
me too so let me add my idea as the 6th point
5/ Documentation isn't great
We did some good things, we have a repo with usable doc and a website to
point people to, but the docs honestly are a bit confusing and even lack
documentation about quite some features for end users.
Maybe we can start some minor restructuring of the docs, splitting them
into a 'quickstart' guide and a 'feature-complete' guide and ask people
to submit together with a feature the matching documentation in the
'feature-complete' guide?
--
Giulio Fidente
GPG KEY: 08D733BA
__________________________________________________________________________
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
