[Pulp-dev] 2.12.0 blocked(ish)

Wed Feb 1 10:09:56 UTC 2017

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 <jalberts at redhat.com> 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 <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
>>
>>
> _______________________________________________
> 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/564d7580/attachment.htm>