[Pulp-dev] signing service interface

The Plugin API of Signing Services in Pulp 3 is too vague. I came to this conclusion while working with @lieter on an RPM plugin feature that allows users to download a repo config file from a distribution[0]. As a result, we decided to document that the signing service needs to produce a public

[Pulp-dev] improving functional tests

I've written an issue to track improvements to functional tests[0]. Please provide feedback on this thread or on the issue directly. [0] https://pulp.plan.io/issues/6637 ___ Pulp-dev mailing list Pulp-dev@redhat.com

Re: [Pulp-dev] the "relative path" problem

I've reached two conclusions while trying to formulate a solution: This problem needs to be solved at the repository version level. Repository membership needs to be tracked at the artifact level, and not content level as it is now. On Thu, Apr 30, 2020 at 1:11 PM Daniel Alley wrote: > Cool,

[Pulp-dev] New pulpcore release (3.3.1?)

I think Katello would like a few of the bug fixes from the past couple weeks. Would a 3.3.1 release make sense? Would anyone have time this week to work on it? David ___ Pulp-dev mailing list Pulp-dev@redhat.com

Re: [Pulp-dev] fedorapeople.org fixtures

I filed this infrastructure ticket https://pulp.plan.io/issues/6638 for fixtures.pulpproject.org and emailed osci.io contacts asking if they are willing to make https://fixtures.pulpproject.org for us. I'll share back to the thread with what they say. Since we're on the topic, I want to share my

Re: [Pulp-dev] Markdown docs - pulpcore and plugins

I agree pypi will only show the README. I imagined a really long README, but maybe this is not a great approach. What do other users of openapigenerator use for their Python bindings? Can we ask them to get a recommendation? I'm looking for more ideas because I don't think we can continue with

Re: [Pulp-dev] Markdown docs - pulpcore and plugins

Brian, I liked this idea, but I think pypi will only get the README part of the docs, not sure if it is enough Best regards, Fabricio Aguiar Software Engineer, Pulp Project Red Hat Brazil - Latam +55 11 999652368 On Mon, May 4, 2020 at 11:53 AM Brian Bouterse wrote:

Re: [Pulp-dev] Markdown docs - pulpcore and plugins

I misunderstood the PR https://github.com/pulp/pulp_file/pull/386. I thought it did convert pulp_file entirely to MD using an automated tool, but I realize now it uses two formats which I'm not as comfortable with. I am in favor of moving to MD for everything, but if there isn't an automated tool

[Pulp-dev] Pulpcore meeting notes

Forgot to send this out Friday. May 1, 2020 Topics - [bmbouter] converting pulpcore docs to Markdown - https://www.redhat.com/archives/pulp-dev/2020-April/msg00114.html - Bmbouter and daviddavis to respond Previous Action Items - [bmbouter and dkliban] -

Re: [Pulp-dev] Markdown docs - pulpcore and plugins

Clarifying the email, My original thought was: if your plugin has a binding client and you want to document it, the way I find for doing it is introducing markdown docs from the client, as it would end up with 2 docs formats (rST and MD), I wanted the hear your thoughts on moving the entire docs

Re: [Pulp-dev] Markdown docs - pulpcore and plugins

+1 to moving to markdown. I'm imagining that with this move, Markdown will be the lingua franca in Pulp 3 for documentation but it will be ultimately up to plugins to decide what language to use. Moreover, I'm guessing we'll update plugin_template to use Markdown too. I think there are tools that

Re: [Pulp-dev] Markdown docs - pulpcore and plugins

Am I understanding this correctly, that you (ultimately) want to convert all existing reStructuredText documentation to markdown instead? If so, will you also be updating the plugin template? Or is pulp_file the reference implementation to watch here? Currently pulp_deb is overdue for a

Re: [Pulp-dev] Moving to travis-ci.com

+1 to move pulp3 projects. Thank you for taking care of this. Regards, Ina Panova Senior Software Engineer| Pulp| Red Hat Inc. "Do not go where the path may lead, go instead where there is no path and leave a trail." On Fri, May 1, 2020 at 9:22 PM Brian Bouterse wrote: > Thank

Re: [Pulp-dev] fedorapeople.org fixtures

I am also in favour of hosting fixtures. Eventually we'd also need to update our tests and workflows in the docs that point to the fedorapeople.orf fixtures. Regards, Ina Panova Senior Software Engineer| Pulp| Red Hat Inc. "Do not go where the path may lead, go instead where there is

Re: [Pulp-dev] fedorapeople.org fixtures

I agree with @ttereshc that having fixtures hosted somewhere provides value. @bmbouter, your proposal sounds like a good idea. Can you see if it's feasible this week? David On Fri, May 1, 2020 at 3:17 PM Brian Bouterse wrote: > I'm +1 on stopping the use of fixtures on fedora people (see