[Pulp-dev] 2.12.0 blocked(ish)

[Jen Albertson]

My only opinion is that we do not block the release of 2.12 on pulp_pytho
2.0 (so concurring with you option 2).

I'm interested to hear what other thoughts there are as to when and how we
introduce it.

On Tue, Jan 31, 2017 at 5:57 PM Sean Myers <sean.myers at redhat.com> wrote:

> 2.12.0 has generally passed upgrade testing, but this guy over in
> pulp_python
>
> land got kicked back to us:
>
>
>
> https://pulp.plan.io/issues/140
>
>
>
> That's one of the new pulp_python 2.0 features. We have a few options for
>
> how to proceed, so I thought it would be worthwhile to put those options
>
> to the list and decide what to do.
>
>
>
> 1. Release pulp 2.12.0 with pulp_python 2.0, with a known issue stating
> that
>
>    this feature is broken, and will be fixed "soon". Pulp 2.12.0 is
> released
>
>    tomorrow.
>
>
>
> 2. Release pulp 2.12.0 with pulp_python 1.1.3, the current stable version,
>
>    deferring the pulp_python 2.0 release until a later date. Pulp 2.12.0
>
>    is released tomorrow.
>
>
>
> 3. Release pulp 2.12.0 with pulp_python 2.0, but remove the new feature
> from
>
>    the list of features added in pulp_python 2.0. Pulp 2.12.0 is released
>
>    tomorrow, pulp_python 2.1 is released at a later date with this new
> feature
>
>    included.
>
>
>
> 4. Block the release of pulp 2.12.0 pending the fix and verification of
>
>    this story, release pulp 2.12.0 with pulp_python 2.0. Pulp 2.12.0
> release
>
>    date is undefined.
>
>
>
> 5. Something else I haven't suggested here.
>
>
>
> Among this options, I prefer the second, since it means we do release very
>
> close to our target release date, and don't release known-broken stuff.
>
>
>
> Given that pulp is able to sync from the "real" pypi, if pulp isn't able
> to sync
>
> a pypi-like repository published by pulp itself, that suggests to me that
> more
>
> features may be at risk in pulp_python 2.0 than the ability to sync from
> pulp.
>
> I would prefer to mitigate that risk by *not* releasing pulp_python 2.0
> without
>
> more verification.
>
>
>
> Both options 1 and 2 give us a little bit of flexibility. Some examples:
>
>
>
> - We could do a separate release cycle for only the updates to pulp_python,
>
>   following a similar process to what we do for platform Y-releases. This
> is
>
>   nice, but may result in a very surprising major-version upgrade of a
> package
>
>   between pulp platform releases.
>
> - We could release pulp_python 2.0 with pulp 2.13.0. This is less
> surprising,
>
>   but also delays the new features introduced in pulp_python 2.0 for still
>
>   another platform Y-release.
>
> - We could do a hybrid of the two, such as releasing a functioning
> pulp_python
>
>   2.0 in its own repository with special instructions for installation,
> and then
>
>   bundle pulp_python 2.0 with 2.13.0 as we had intended to do with 2.12.0.
>
>
>
> So, my questions (and my current answers to them) are these:
>
>
>
> - Do we want to block the release of pulp 2.12.0 until pulp_python is
> ready to
>
> release?  (I expect that we do not.)
>
>
>
> - Do we want to release pulp_python 2.0 tomorrow, with 2.12.0, knowing
> that it
>
> is *not* feature-complete?  (I'm less confident here, but suspect that we
> don't
>
> want to release pulp_python 2.0 in a non-working state.)
>
>
>
> - Do we want to release pulp_python 2.0 at some point before the release
> of pulp
>
> 2.13.0?  (I'm mostly indifferent here. I think it would trivial to put
> together a
>
> release of just pulp_python 2.0 that can be made generally available prior
> to the
>
> release of pulp, but I don't know how useful that would actually be. We
> also may
>
> not need to decide this right now, depending on other answers.)
>
>
>
> Given no objections, my current plan is to follow option #2, and release
> pulp
>
> 2.12.0 tomorrow afternoon with pulp_python 1.1.3, and we can decide what
> to do
>
> about pulp_python 2.0 afterward.
>
>
>
> Thanks for reading my novel. :)
>
>
>
> _______________________________________________
>
> Pulp-dev mailing list
>
> Pulp-dev at redhat.com
>
> https://www.redhat.com/mailman/listinfo/pulp-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/pulp-dev/attachments/20170201/df67b2be/attachment.htm>