[storm] Moving Storm Forward

[Gustavo Niemeyer]

Thanks for putting these ideas together James!

> = Get More People Working on Trunk =
>
> If someone were to look at the revisions in Storm's trunk, they'd see
> that pretty much all the recent commits come from Canonical employees.
>  However, if they looked at the other branches registered on
> Launchpad, it is clear that there are a number of long lived feature
> branches containing significant contribution from the community.  The
> prominent ones are:

A few notes on these specific branches:

>  * twisted-integration

Even though that's not entirely connected to what is being done by
Canonical today, this branch is actually from Thomas Hervé, who works
for Canonical too and is an active Storm developer.  We've been
discussing details about how to integrate it and there are a few edges
we agree should be polished before integration.

>  * Oracle support

I've exchanged some ideas about this with Gustavo (kov), but we both
are a bit slow on answering each other's comments, so it's being a bit
slower than it should.

>  * Microsoft SQL Server support

This came from the community, but I think one of the branches is
actually from Sidnei da Silva, who was then hired by Canonical as
coincidence (this Storm work wasn't involved in the hire,
specifically).   Sidnei, are you listening? :-)  Can you comment on
the status of this branch?

> While the current state of affairs might be workable for their current
> users, I think it would be beneficial to try and get them merged to
> trunk ASAP.  Some benefits of merging the branches include:
(...)

These look like good points.

> Of course, there are some problems to overcome in merging Oracle and
> MS-SQL support.  I am currently able to run tests for all supported DB
> backends on my machine when committing to trunk, but that will be
> difficult with these two due to licensing and ties to Windows for
> MS-SQL.  Perhaps a buildbot instance might be the answer, if we can
> get appropriate slaves set up.

Agreed.  I think buildbots are the way to go.  It would be good if at
least some of the main developers had all the backends working locally
too.

> Another issue is test coverage for the new backends.  If they don't
> currently pass all the tests, might it be appropriate to merge them
> anyway and work out a process where we can ratchet down the set of
> failures to zero post merge?

I'm a bit more concerned about this one aspect.  We're currently quite
strict about the test coverage in Storm, and there's a great benefit
to people which use it in production systems.  If some of these
branches have incomplete test suites (either broken or missing some
tests entirely), once they are integrated, there's less motivation to
get good testing in place.

That said, I guess it's correct to say that being strict about tests
do reduce the community motivation for contributions, since it's a
steeper learning curve to do things *and* to get them properly tested.

So, how do we balance, good testing coverage with good community practices?


> = Reviews =
>
> Changes make their way to trunk through Launchpad's code review
> system.  A list of branches waiting for review is available here:
>
>    https://code.launchpad.net/storm/+activereviews
>
> While most review work is being done by the core Storm team at the
> moment, I'd welcome others to help out.  Even if you don't have a deep
> knowledge of Storm, a general knowledge of Python programming can
> often be enough to see things the original developer missed.

I think we can try to schedule "Storm review days" as well, where all
of the main developers would get together over IRC and clean up the
queues entirely.  This would probably be effective, as long as we
manage to do these often enough.


> = IRC Meetings =
>
> Gustavo mentioned this on the mailing list a few months back, but we
> haven't actually organised it.  It'd be helpful to have a regular IRC
> meeting to discuss the development of Storm.  I think it'd be good to
> aim for a monthly meeting at least initially, but we could do it more
> frequently if we feel it is necessary.
>
> The meeting need not be too long: if there isn't much to discuss, then
> the meeting can end quickly.  This would be open
>
> Picking a time might be a bit tricky, given that we're a
> geographically dispersed team with people in America (North and
> South), Europe and Australia, but hopefully we can find a time that
> works.

Agreed.  I suggest we do the first one next week, on Friday.   What
time would work for you, James?  I guess you're used to that kind of
conflict due to previous Launchpad work, so will probably have some
well-known times where it's best for most people.


> Comments are welcome, as are further suggestions to improve our
> development process.

Indeed!  Again, thank you very much for pushing these ideas forward!

-- 
Gustavo Niemeyer
http://niemeyer.net