On 20/12/17 07:07, Zane Bitter wrote: > On 13/12/17 11:17, Thierry Carrez wrote: >> So... What do you think ? > > Some points against that I haven't seen mentioned much yet: > > * Following our standard deprecation policy, it would take up to 3 > years to remove anything. For perspective, 3 years ago we had just > shipped Juno. (I feel old now.) > > * Other large, complex software distributions have moved to 6-month or > shorter development cycles (e.g. Ubuntu, Fedora, Chromium, Linux, > Firefox), with apparent success. What do we think is different about > the context in which we work that makes it a good idea to go in the > other direction? > > * Upgrading OpenStack is painful for our users. Modern software > development theory holds that you make painful things less painful by > doing them *more* often, in smaller bites. (And preferably make the > developers suffer some of the pain, so they're motivated to reduce > it.) Less frequent upgrades with bigger changes is likely to provoke > even more of our users to remain on old releases indefinitely. > > * It's true that OpenStack is mature in the sense that the things it > does are pretty stable. It's not true in the sense of it being close > to fulfilling our mission, of implementing a full-featured cloud. > (e.g. my pet bug-bear: applications can't use it unless they have > economies of scale, are prepared to implement a bunch of stuff > themselves, and are extremely motivated to use OpenStack over > alternatives that are designed with application support in mind... so > basically just infra.) We absolutely need to keep up a fast pace of > innovation in order not to become irrelevant. >
+100 > * Natural complements to OpenStack like Kubernetes also have rapid > release cycles. If we're unable to respond rapidly to changes in them > (by adjusting our integration points in a timely fashion) then they're > going to be more inclined to put effort into working around OpenStack > than into working together. (The fact that said integration points > largely don't exist at the moment is also an example of the previous > point.) Very good point. > > * As someone who will probably volunteer as a PTL again at some point, > the prospect of having to sign up for an entire year is a major > disincentive to do so. > > > I'm all for encouraging companies who are using OpenStack to > contribute e.g. 20% of a developer to helping out upstream. I'm not at > all convinced that regular releases are an obstacle to that - by the > 'pace' of development I suspect they mean the constant code churn > resulting in never-ending rebases of outstanding patches that they > struggle to get reviews on (often, it must be said, because they are > GIANT), and not the release cadence. So count me as -1 on this change. > > cheers, > Zane. > > __________________________________________________________________________ > > 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 -- Cheers & Best regards, Feilong Wang (王飞龙) -------------------------------------------------------------------------- Senior Cloud Software Engineer Tel: +64-48032246 Email: flw...@catalyst.net.nz Catalyst IT Limited Level 6, Catalyst House, 150 Willis Street, Wellington -------------------------------------------------------------------------- __________________________________________________________________________ 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
