[Pulp-dev] Pulp 3 MVP Issue Cleanup

Dennis Kliban dkliban at redhat.com
Thu Apr 5 13:40:34 UTC 2018


I expect our CLI to be agnostic of the plugins. With that in mind, when we
have a problem with the CLI it's an actual problem with the CLI. Any plugin
specific problems are probably issues with the REST API.

On Thu, Apr 5, 2018 at 9:07 AM, Ina Panova <ipanova at redhat.com> wrote:

> I would try for now to minimize the number of projects because they are
> difficult to maintain and stick to Tags field until we clearly define what
> goes where.
>
> Some thoughts:
> if we put CLI as a separate project, where we'd put some plugin specific,
> for example PRM, cli section/command/option request? Under project CLI with
> tag RPM?
> Or under rpm_plugin project with tag CLI?
>
>
>
> --------
> Regards,
>
> Ina Panova
> 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 Thu, Apr 5, 2018 at 1:21 AM, Austin Macdonald <austin at redhat.com>
> wrote:
>
>>
>>
>> On Wed, Apr 4, 2018 at 6:09 PM, Dennis Kliban <dkliban at redhat.com> wrote:
>>
>>> Anything that is going to have it's own release cadence should be
>>> tracked in it's own project. That way we can assign issues related to
>>> specific release of that project to the particular release.
>>>
>> Are we going to release the CLI, Ansible Installer, and the Migration
>>> tool as part of one version of Pulp or will these all be versioned
>>> separately?
>>>
>>
>> Seems reasonable. IMO, CLI should be released on its own. Ansible
>> Installer role will have its own cadence on Galaxy. Vagrant/playbooks will
>> not be released.
>>
>> The Migration tool is tricky. A pulpcore migration tool would be one
>> thing, but each plugin will probably need its own migration tool. So... /me
>> shugs.
>>
>>
>>>
>>> On Wed, Apr 4, 2018 at 5:41 PM, Austin Macdonald <austin at redhat.com>
>>> wrote:
>>>
>>>>
>>>>>> I'm hoping to continue the "Infrastructure" Redmine project for
>>>>> things like website hosting. I see what you mean though because it will be
>>>>> developed and released separately. I think we're in a similar situation for
>>>>> 3 things: the ansible installer, the migration tool, and CLI, and for each
>>>>> of them we should either make their own Redmine projects or a tag under
>>>>> Pulp. We already have many Redmine projects and they are kind of a pain so
>>>>> I want to float a tags based approach for feedback. Perhaps keeping them
>>>>> out of "Pulp" means that we remove all the existing tags from them and tag
>>>>> them with new tags like 'Ansible Installer', '2to3 Migration' and 'CLI'?
>>>>>
>>>>
>>>> I had hoped that someday there would be a separate group of committers
>>>> for pulp/devel or wherever we keep it. Also, I wouldnt want potential
>>>> users/PMs to see a "bug count" that includes non-user facing issues. These
>>>> concerns are trivial though, and if projects are a pain, I'm fine with
>>>> keeping Tags.
>>>>
>>>> Since projects are a pain, can we get rid of the "external" project?
>>>> https://pulp.plan.io/projects/external/issues
>>>>
>>>>
>>>> _______________________________________________
>>>> 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/20180405/71ef9c90/attachment.htm>


More information about the Pulp-dev mailing list