[Pulp-dev] Downloading Decision

The pulp 3 alpha included two solutions for providing downloading support in the plugin API.  Each solution was based on different concurrency technologies, protocol support libs and abstractions.  The goal was to test drive each, get community feedback and make a second pass at documenting

[Pulp-dev] Repository Versions stories update

In the RepositoryVersions discussion this morning, we identified some issues that needed to be updated to the current design. The issue changes have been made and they are ready for all to review. We will discuss adding them to the sprint in another meeting tomorrow.

Re: [Pulp-dev] Github keywords

> I think we should (if possible) change our redmine automation to: > closes https://pulp.plan.io/issues/1234 > > I like this because there is no ambiguity and it will prevent us from > having to also add the href to the PR as a comment. > As a nice bonus, if GitHub *is* used as the issue

Re: [Pulp-dev] creating repository version resources using a single REST endpoint

Thinking through the documentation for this endpoint, I could see it becoming quite unwieldy. Suppose each plugin implements 1-2 tasks with a couple parameters. This endpoint could potentially have 20+ parameters easily. Imagine reading through the API documentation to try to figure out what

Re: [Pulp-dev] creating repository version resources using a single REST endpoint

On Tue, Jan 9, 2018 at 7:43 AM, Dennis Kliban wrote: > On Mon, Jan 8, 2018 at 4:24 PM, Austin Macdonald > wrote: > >> From a discussion with dkliban I see that this design could work. Plugin >> tasks would be imported to pulpcore with a mechanism