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 <[email protected]> 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 > [email protected] > https://www.redhat.com/mailman/listinfo/pulp-dev > >
_______________________________________________ Pulp-dev mailing list [email protected] https://www.redhat.com/mailman/listinfo/pulp-dev
