[Pulp-dev] 2.12.0 blocked(ish)

Jeff Ortel jortel at redhat.com
Wed Feb 1 18:45:46 UTC 2017


+1 option #2.

On 01/31/2017 04:57 PM, Sean Myers 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 --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 847 bytes
Desc: OpenPGP digital signature
URL: <http://listman.redhat.com/archives/pulp-dev/attachments/20170201/fb52f34b/attachment.sig>


More information about the Pulp-dev mailing list