[Pulp-dev] Pulp 3 Release Process Questions

[Brian Bouterse]

Travis also supports secure signing so having travis handle releases seems
viable. For signing, I think it's desirable to have 1 key to trust no
matter how you are installing Pulp (pypi, rpm, debian, etc). To do that we
should coordinate our keys before we start signing builds. We probably need
to use subkeys. I hope we defer signing for several months. Feedback from
the community or other stakeholders on their needs for signed builds would
help inform this area.

On Mon, Apr 23, 2018 at 9:07 AM, David Davis <daviddavis at redhat.com> wrote:

> 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
>>
>>
>
> _______________________________________________
> 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/f1f37e45/attachment.htm>