I like option 2, for all the reasons you said, and one more. In trying to investigate the failure (if there are details about how it fails, I don't know where to see them), I noticed that the documentation for pulp_python is woefully inadequate. There are basic things missing, like information about how to construct a correct feed URL. The only docs with any substantial information are the "Getting Started" docs, which only show examples.
I think there's at least a decent chance that the test is failing because QE had to make guesses about how to construct a feed URL, and happened to guess wrong. Looking at the docs in their current state, I would not want to be responsible for writing tests for this plugin. QE: please feel empowered to complain about missing docs. I feel bad that you were working from so little information. It would be much better to release pulp_python 2.0 with at least basic documentation for its features. Let's take some time and get that right, while not blocking Pulp 2.12. Michael On Wed, Feb 1, 2017 at 3:24 AM, Jen Albertson <[email protected]> wrote: > 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 <[email protected]> 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 >> >> [email protected] >> >> https://www.redhat.com/mailman/listinfo/pulp-dev >> >> > _______________________________________________ > Pulp-dev mailing list > [email protected] > https://www.redhat.com/mailman/listinfo/pulp-dev > >
_______________________________________________ Pulp-dev mailing list [email protected] https://www.redhat.com/mailman/listinfo/pulp-dev
