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 <[email protected]> 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 <[email protected]> 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 <[email protected]> >> wrote: >> >>> On Tue, Apr 17, 2018 at 11:50 AM, Eric Helms <[email protected]> wrote: >>> >>>> >>>> >>>> On Fri, Apr 13, 2018 at 4:40 PM, Dennis Kliban <[email protected]> >>>> wrote: >>>> >>>>> On Fri, Apr 13, 2018 at 1:25 PM, Patrick Creech <[email protected]> >>>>> 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 >>>>>> [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 >>> >>> >> >
_______________________________________________ Pulp-dev mailing list [email protected] https://www.redhat.com/mailman/listinfo/pulp-dev
