[Pulp-dev] 2.12.0 blocked(ish)

[Sean Myers]

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. :)

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 866 bytes
Desc: OpenPGP digital signature
URL: <http://listman.redhat.com/archives/pulp-dev/attachments/20170131/3c570986/attachment.sig>