[Pulp-dev] 2.12.0 blocked(ish)

Wed Feb 1 11:24:34 UTC 2017

+1 to option 2.

If a pulp smash test is failing, it would be great if the full command to
run exactly that test be posted on the bug. That would reduce the time it
takes for a developer to resolve the issue.

Thanks for raising this.

On Wed, Feb 1, 2017 at 5:09 AM, Michael Hrivnak <mhrivnak at redhat.com> wrote:

> 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
>>
>>
>
> _______________________________________________
> 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/beca4c88/attachment.htm>