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