[Pulp-dev] Pulp 3 Release Process Questions

[Robin Chan]

Dennis, Eric, & Patrick,

Thanks for this additional information around this motivation behind some
of the differences between Pulp 2 and Pulp 3 release options. I'm glad to
hear that Pulp 2 had some constraints that Pulp 3 does not have and that
Pulp 3 can now be published on PyPI. This is great and a good change.  A
release process in Pulp 3 that allows for community contribution of a wide
range of Linux distributions would be fantastic and I fully support that
goal.

When I see the term "derivative" packaging, I'm not clear on what is meant
here. If it simply means that it is created after that, then I don't see is
how the above goals or changes make RPM deliverables something we don't
have any commitments around. I would disagree that the build team can
decide how often they build RPMs. Since the existing community has consumed
Pulp 2 as RPMs, I was assuming that Pulp 3 (at the latest 3.0 GA) needed to
be delivered to PyPI and also as RPMs. A deviation should be at least
vetted with stakeholders before deciding the need? Is there feedback or
some industry standard/example that I'm not aware of?  Can we check with
stakeholders and consumers if they are ok with taking Pulp 3.0 GA from PyPI
only or propose a minimum commitment around how often RPMS would need to be
made available? The build team can help support us and in our commitments,
but I don't think they have a direct commitment to Pulp stakeholders - I
think that's the rub here.

I suspect that Pulp 3.0 Core Beta consumers would be OK with taking just
PyPI delivery of Pulp 3.0 core beta code even though we committed to RPM
deliverables. I also think some additional discussion of testing by various
tools and teams would be good to have in a collaborative, open way.

-Robin



On Wed, Apr 18, 2018 at 4:05 PM, Dennis Kliban <dkliban at redhat.com> wrote:

> One of the requirements for Pulp 3 is to be able to run on a wide range of
> Linux distributions. Being a Python application, that means we can achieve
> that goal by following good Python development practices. Part of those
> good practices is releasing packages via the Python Package Index (PyPI).
>
> Pulp 2 could never be published on PyPI because it had dependencies that
> were not available from PyPI. Pulp 3 was designed to be installed from
> PyPI. It's dependencies were carefully selected to meet this requirement.
>
> On Wed, Apr 18, 2018 at 3:17 PM, Robin Chan <rchan at redhat.com> wrote:
>
>> Since this is a change from Pulp 2, I think it would be helpful to
>> outline the reasoning behind such a change and ask that spell those out
>> here for transparency. In addition, are there any concerns we think others
>> may have or new problems that such a change brings about that we need to
>> work to answer?
>>
>> On Tue, Apr 17, 2018 at 11:57 AM, Dennis Kliban <dkliban at redhat.com>
>> wrote:
>>
>>> On Tue, Apr 17, 2018 at 11:50 AM, Eric Helms <ehelms at redhat.com> wrote:
>>>
>>>>
>>>>
>>>> On Fri, Apr 13, 2018 at 4:40 PM, Dennis Kliban <dkliban at redhat.com>
>>>> wrote:
>>>>
>>>>> On Fri, Apr 13, 2018 at 1:25 PM, Patrick Creech <pcreech at redhat.com>
>>>>> wrote:
>>>>>
>>>>>> Pulp,
>>>>>>
>>>>>> So, while working on the packaging work, I figured it be nice to
>>>>>> start talking about release process expectations around nightlies, beta,
>>>>>> and GA.
>>>>>>
>>>>>> Generally, what is pulp's release plan?  What are the expectations
>>>>>> here?
>>>>>>
>>>>>>
>>>>> The release process for Pulp 3 will be different from what we do for
>>>>> Pulp 2. Our plan for publishing Pulp 3 with quality to PyPI is outlined on
>>>>> our wiki[0]. We are hoping to be able to release to PyPI once a week during
>>>>> the beta cycle. After the packages are published to PyPI,  any of the
>>>>> derivative packaging (RPM, Debian, etc) can be performed. The build team
>>>>> can decide how often the derivative packages need to be produced.
>>>>>
>>>>
>>>> This implies that, for the Pulp developer team, Pypi is considered the
>>>> release vector and that derivative release vectors (e.g. RPM, Deb, etc.)
>>>> are considered community contributions that are not part of the core
>>>> release process. Is that a fair summary of the position? Consumers of
>>>> non-pypi release vectors will need to assume a delay between announced
>>>> release and RPM release. Which then, unlike Pulp 2, means the team handling
>>>> RPM for example would manage build and release announcement on our own
>>>> schedule. I want to clarify so that we set expectations for developers and
>>>> users and so that we can set our expectations for how we shift compared to
>>>> Pulp 2.
>>>>
>>>>
>>> You are correct in your understanding.
>>>
>>>
>>>> If the above is the agreed workflow (and change for Pulp 3) I think the
>>>> rest of the questions I'd ask related to the points below are answered and
>>>> we can talk a bit further on these points above.
>>>>
>>>> - Eric
>>>>
>>>>
>>>>>
>>>>> [0] https://pulp.plan.io/projects/pulp/wiki/Continuous_Delivery_
>>>>> of_Pulp_3
>>>>>
>>>>>
>>>>>> And also, more specifically,
>>>>>>
>>>>>> Based on what we do for pulp 2, when will pulp 'code freeze'? What is
>>>>>> the expected turnaround from 'code freeze to 'packages shipped'.  We should
>>>>>> probably agree on some expectations of turnaround
>>>>>> time.
>>>>>>
>>>>>>
>>>>> The code will be frozen when it is published to PyPI.
>>>>>
>>>>>
>>>>>> Is there a staging process in place yet for packages (pypi or rpm)?
>>>>>> Is there testing expectations of these pre-release bits to ensure quality?
>>>>>> With pypi being a valid install location, are these
>>>>>> releases to be coordinated?
>>>>>>
>>>>>>
>>>>> As outlined on the wiki, we plan to ensure quality at merge time of
>>>>> every commit.
>>>>>
>>>>>
>>>>>> Where are pulp 3 bits expected to be hosted?  How are we going to
>>>>>> handle signing packages?
>>>>>>
>>>>>
>>>>> Pulp 3 will always be published to PyPI. Any derivative packages can
>>>>> be hosted on fedorapeople.org. I'd like to defer to someone else to
>>>>> speak about the signing.
>>>>>
>>>>>
>>>>>> _______________________________________________
>>>>>> 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/20180419/f2474d1d/attachment.htm>