[openstack-dev] [TripleO] Backwards compatibility policy for our projects
duncan.thomas at gmail.com
Mon Jun 16 17:46:12 UTC 2014
This looks like a special pleading here - all OpenStack projects (or
'program' if you prefer - I'm honestly not seeing a difference) have
bits that they've written quickly and would rather not have to
maintain, but in order to allow people to make use of them downstream
have to do that work. Ask the cinder team about how much I try to stay
on top of any back-compat issues.
If TripleO is not ready to take up that burden, then IMO it shouldn't
be an official project. If the bits that make it up are too immature
to actually be maintained with reasonable guarantees that they won't
just pull the rug out from any consumers, then their use needs to be
re-thought. Currently, tripleO enjoys huge benefits from its official
status, but isn't delivering to that standard. No other project has a
hope of coming in as an official deployment tool while tripleO holds
that niche. Despite this, tripleO is barely usable, and doesn't seem
to be maturing towards taking up the responsibilities that other
projects have had forced upon them. If it isn't ready for that, should
it go back to incubation and give some other team or technology a fair
chance to step up to the plate?
I don't want to look like I'm specifically beating on tripleO here,
but it is the first openstack component I've worked with that seems to
have this little concern for downstream users *and* no apparent plans
to fix it.
That's without going into all of the other difficulties myself and
fellow developers have had trying to get involved with tripleO, which
I'll go into at some other point.
It is possible there are other places with similar problems, but this
is the first I've run into - I'll call out any others I run into,
since I think it is important, and discussing it publicly keeps
everyone honest. If I've got the wrong expectations, I'd at least like
to have the correction on record.
On 16 June 2014 17:58, Clint Byrum <clint at fewbar.com> wrote:
> Excerpts from Duncan Thomas's message of 2014-06-16 09:41:49 -0700:
>> On 16 June 2014 17:30, Jason Rist <jrist at redhat.com> wrote:
>> > I'm going to have to agree with Tomas here. There doesn't seem to be
>> > any reasonable expectation of backwards compatibility for the reasons
>> > he outlined, despite some downstream releases that may be impacted.
>> Backward compatibility is a hard habit to get into, and easy to put
>> off. If you're not making any guarantees now, when are you going to
>> start making them? How much breakage can users expect? Without wanting
>> to look entirely like a troll, should TripleO be dropped as an
>> official until it can start making such guarantees? I think every
>> other official OpenStack project has a stable API policy of some kind,
>> even if they don't entirely match...
> I actually agree with the sentiment of your statement, which is "backward
> compatibility matters."
> However, there is one thing that is inaccurate in your statements:
> TripleO is not a "project", it is a "program". These tools are products
> of that program's mission which is to deploy OpenStack using itself as
> much as possible. Where there are holes, we fill them with existing
> tools or we write minimal tools such as the tripleo_heat_merge Heat
> template pre-processor.
> This particular tool is marked for death as soon as Heat grows the
> appropriate capabilities to allow that. This tool never wants to
> be integrated into the release. So it is a little hard to justify
> bending over backwards for BC. But I don't think that is what anybody
> is requesting.
> We're not looking for this tool to remain super agile and grow, thus
> making any existing code and interfaces a burden. So I think it is pretty
> easy to just start marking features as deprecated and raising deprecation
> warnings when they're used.
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
More information about the OpenStack-dev