Open Stack

On 07/07/2014 11:06 AM, Ihar Hrachyshka wrote:
> On 04/07/14 16:54, Mark McLoughlin wrote:
>> On Fri, 2014-07-04 at 15:31 +0200, Ihar Hrachyshka wrote:
>>> Hi all, at the moment we have several bot jobs that sync contents
>>> to affected projects:
>>>
>>> - translations are copied from transifex; - requirements are
>>> copied from global requirements repo.
>>>
>>> We have another source of common code - oslo-incubator, though
>>> we still rely on people manually copying the new code from there
>>> to affected projects. This results in old, buggy, and sometimes
>>> completely different versions of the same code in all projects.
>>>
>>> I wonder why don't we set another bot to sync code from
>>> incubator? In that way, we would: - reduce work to do for
>>> developers [I hope everyone knows how boring it is to fill in
>>> commit message with all commits synchronized and create sync
>>> requests for > 10 projects at once]; - make sure all projects use
>>> (almost) the same code; - ensure projects are notified in advance
>>> in case API changed in one of the modules that resulted in
>>> failures in gate; - our LOC statistics will be a bit more fair ;)
>>> (currently, the one who syncs a large piece of code from
>>> incubator to a project, gets all the LOC credit at e.g.
>>> stackalytics.com).
>>>
>>> The changes will still be gated, so any failures and
>>> incompatibilities will be caught. I even don't expect most of
>>> sync requests to fail at all, meaning it will be just a matter of
>>> two +2's from cores.
>>>
>>> I know that Oslo team works hard to graduate lots of modules
>>> from incubator to separate libraries with stable API. Still, I
>>> guess we'll live with incubator at least another cycle or two.
>>>
>>> What are your thoughts on that?
> 
>> Just repeating what I said on IRC ...
> 
>> The point of oslo-incubator is that it's a place where APIs can be
>> cleaned up so that they are ready for graduation. Code living in
>> oslo-incubator for a long time with unchanging APIs is not the
>> idea. An automated sync job would IMHO discourage API cleanup work.
>> I'd expect people would start adding lots of ugly backwards API
>> compat hacks with their API cleanups just to stop people
>> complaining about failing auto-syncs. That would be the opposite of
>> what we're trying to achieve.

+1 to what Mark said.


> The idea of oslo-incubator is that everyone consumes the code, I guess
> in its latest form (?). I don't see how silently breaking API thru
> cleanup is any better than breaking it *and* notifying projects about
> the work to be done to consume updates from incubator.

Before automating this with bots we'd need to improve the update.py
script. We've discussed this in the past[0] and agreed that wasting time
on making this script smart enough to do all what we need instead of
dedicating that time to graduating projects is not worth it.

Although ideally all projects should use the latest version of whatever
we have in oslo-incubator, that's definitely not the case. This means
the bot will just cause noise on reviews and it'll be ignored. All this
without considering the likelihood of these syncs to fail.

What should we do with fails?

Which modules should we sync on every run?

I hardly believe someone will prioritize a oslo-sync failure over a new
bug fix or feature up for review. Whether this is the ideal workflow or
not is not under discussion. This is just the reality.


> Also, I suspect the idea now is to eventually drop incubator, and any
> API cleanup is now done inside separate graduating modules, like
> oslo.messaging or oslo.i18n.

Ish. The idea now is to graduate as many libs as possible by following
the API stability premises Mark mentioned.

> 
> So I don't see how syncing the code until those modules are graduated
> can harm, while possible benefits are quite significant.

There are folks that volunteered to be liaisons[1] for Oslo integration.
I'd expect folks on that list to do part of the job you mentioned.

-1 for having an automated bot doing this. I don't think this is the
right time and it doesn't fit with what we're trying to achieve now in
olso-incubator.


[0]
http://lists.openstack.org/pipermail/openstack-dev/2013-November/020118.html
[1] https://wiki.openstack.org/wiki/Oslo/ProjectLiaisons

-- 
@flaper87
Flavio Percoco