Open Stack

Dan Prince wrote:
>>>  * Migrations added during Folsom release cycle could be compacted
>>>  during "E" release cycle. TBD if/when we do the next compaction.
>>
>> An alternative idea would be to do the compaction *prior* to the
>> Folsom relase instead of after, so that the cleanest possible
>> migration path is presented to non-trunk-chasing users. It could for
>> example be a task that's part of spinning up the first Folsom-RC.
>>
>> Its unlikely that after new migrations are added after the release
>> candidate goes out the door (as these are generally associated with
>> non-trivial new features, which would have missed the boat at that
>> late stage). But if there are any, these would have to be adde to
>> the squashed aggregate migration from the get-go.
> 
> I thought about this... but that still leaves only a couple weeks to catch any issues that might come up in the release candidate phase. Also, using the RC makes the compaction point a bit more fuzzy for end users who are following trunk more closely. I do like that it would keep the release tree cleaner however.
> 
> Performing the compaction after release is sort of a middle ground approach which should allow us to clean house from time to time but also keep things stable around release time.

Yes, I've seen a few hard-to-spot regressions caused by migrations in
the past, mostly corner cases that affect specific databases, so
compacting migrations as the very last step before RC1 generation sounds
a bit dangerous to me. It clearly falls in the "clean-up to make code
more tidy but can introduce gratuitous regressions without fixing any
bug" category, which I prefer to happen early in the cycle rather than late.

-- 
Thierry Carrez (ttx)
Release Manager, OpenStack