[Pulp-dev] Pulp 3 Release Process Questions

David Davis daviddavis at redhat.com
Mon Apr 23 13:07:50 UTC 2018


I can only answer the Travis question and I think we tentatively want to
use Travis to push packages to PyPI. It looks like Travis can automatically
deploy tags[0] which is what I think we’ll leverage to do releases.

[0]
https://docs.travis-ci.com/user/deployment#Conditional-Releases-with-on%3A


David

On Fri, Apr 20, 2018 at 11:16 AM, Patrick Creech <pcreech at redhat.com> wrote:

> Thanks Robin!
>
> On Thu, 2018-04-19 at 16:34 -0400, Robin Chan wrote:
> > 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.
>
> +1, The increase in accessibility of the pulp project with pulp3 to other
> user bases is a great thing.
>
> > 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.
>
> This is what we (the build team) believe it to mean.  Whatever is
> published to PyPI becomes the source of reference here, and other packaging
> flows from these bits.  As long as proper quality control
> measures are in place (before the publish to PyPI) that maintain the
> confidince in quality that pulp has earned during pulp 2, then the process
> of ensuring the availability of RPM packages from PyPI
> bits becomes much simpler and straightforward and easier to automate.
>
> > 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.
>
> Although there are other high priority items on our plate, we committed to
> having a software collection and beta rpm bits available on/near the beta
> date.  Unless things change with those other
> priority items, I'm comfortable working to keep this commitment.
>
> > I also think some additional discussion of testing by various tools and
> teams would be good to have in a collaborative, open way.
>
> +1
>
> -------
>
> With all of the above, I think where we (the build team) need immediate
> help to move forward is to figure out where rpms need to be hosted, and
> figuring out the signing processes.  I don't think we
> can use Pulp 2's gpg keys with Pulp 3 (well, technically we could, but it
> was always the intention to change the GPG key with X releases on pulp).
> That way we can be ready to have 'something' hosted
> close to beta day.  As far as a weekly release frequency for beta, I'm not
> sure we could keep up that pace with RPM packaging untill we iron out the
> process more.
>
> Also, it appears that Pulp has adopted the use of Travis upstream for pulp
> 3, I'm assuming that's how the pushes to pypi will happen?
>
> Thanks,
> Patrick
> _______________________________________________
> 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/20180423/8f054a7a/attachment.htm>


More information about the Pulp-dev mailing list