[Pulp-dev] Pulp 3 Release Process Questions

[Dennis Kliban]

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/20180418/c6e4560b/attachment.htm>