Re: [Pulp-dev] Pulp 3 MVP Issue Cleanup

2018-04-18 Thread Brian Bouterse 
I added two categories: 'CLI' and 'Migration Tool' to the core project in
Redmine

On Tue, Apr 10, 2018 at 4:42 PM, Dennis Kliban  wrote:

> I still think the CLI should have it's own project if we are going to
> version it separately from Pulp. I hope we do version it separately from
> pulpcore.
>
> We should use categories for the installer and migration tool.
>
> On Tue, Apr 10, 2018 at 3:01 PM, Jeff Ortel  wrote:
>
>>
>>
>> On 04/10/2018 11:28 AM, Brian Bouterse wrote:
>>
>> OK so to bring it back to how to manage this in Redmine. We've been
>> talking about 'Tags' and I've read a some +1s for their use to track these
>> things and no -1s. I want to identify I think it would be better to use the
>> 'Category' built-in field of Redmine. Tags can be multi-selcted, but I
>> don't think a single issue will need to be a CLI and an Installer and a
>> $other_tag all at once (multi-selected). Categories are a single selection
>> which seems more appropriate. We also make little use of them today and
>> they are built into all Issues redmine has.
>>
>>
>> +1
>>
>>
>>
>> Should I make a Categories for 'Ansible Installer', 'CLI' and 'Migration
>> Tool' in the Pulp project on Redmine?
>>
>> Other suggestions and ideas are welcome.
>>
>>
>>
>>
>> On Tue, Apr 10, 2018 at 11:23 AM, Jeff Ortel  wrote:
>>
>>>
>>>
>>> On 04/10/2018 10:15 AM, Jeff Ortel wrote:
>>>
>>>
>>>
>>> On 04/04/2018 05:09 PM, Dennis Kliban 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?
>>>
>>>
>>> Separately.
>>>
>>>
>>> Meant to clarify.  The CLI can be released separately but I think the
>>> migration tool needs to be released in step with Pulp.  As for the
>>> installer .. seems like that also needs to be released in step with Pulp.
>>>
>>>
>>>
>>>
>>> On Wed, Apr 4, 2018 at 5:41 PM, Austin Macdonald 
>>> 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@redhat.com
 https://www.redhat.com/mailman/listinfo/pulp-dev


>>>
>>>
>>> ___
>>> Pulp-dev mailing 
>>> listPulp-dev@redhat.comhttps://www.redhat.com/mailman/listinfo/pulp-dev
>>>
>>>
>>>
>>>
>>> ___
>>> Pulp-dev mailing list
>>> Pulp-dev@redhat.com
>>> https://www.redhat.com/mailman/listinfo/pulp-dev
>>>
>>>
>>
>>
>> ___
>> Pulp-dev mailing list
>> Pulp-dev@redhat.com
>> https://www.redhat.com/mailman/listinfo/pulp-dev
>>
>>
>
___
Pulp-dev mailing list
Pulp-dev@redhat.com
https://www.redhat.com/mailman/listinfo/pulp-dev

[Pulp-dev] Pulp 3 MVP issue cleanup (round 2)

2018-04-11 Thread Austin Macdonald 
Note: there will be some redundancy with "Various MVP micro-discussions".
That email includes all changes to the MVP document, this thread covers all
changes to issues with the "Pulp 3 MVP" tag.

*Needs attention (please respond on issue):*

   - single resource OperationPostponed https://pulp.plan.io/issues/3166
   - date filter cleanup https://pulp.plan.io/issues/3557
   - RepositoryVersion filters (includes rename "number" field)
   https://pulp.plan.io/issues/3558
   - Filters on detail endpoints https://pulp.plan.io/issues/3537

*Added to sprint :*

   - arbitrary view registration https://pulp.plan.io/issues/3560
   - namespace convention for content https://pulp.plan.io/issues/3472

!*skip*

   - distribution base_path overlap prevention (data layer)
   https://pulp.plan.io/issues/3051

*"Pulp 3 MVP" Tag removed:*

   - asyncio timeout bug https://pulp.plan.io/issues/3149
   - Create version from version https://pulp.plan.io/issues/3360
   - href_in_list filter https://pulp.plan.io/issues/3240
   - Unit tests for Tasks https://pulp.plan.io/issues/3409
   - NGINX ansible role https://pulp.plan.io/issues/2922
___
Pulp-dev mailing list
Pulp-dev@redhat.com
https://www.redhat.com/mailman/listinfo/pulp-dev

Re: [Pulp-dev] Pulp 3 MVP Issue Cleanup

2018-04-10 Thread Dennis Kliban 
I still think the CLI should have it's own project if we are going to
version it separately from Pulp. I hope we do version it separately from
pulpcore.

We should use categories for the installer and migration tool.

On Tue, Apr 10, 2018 at 3:01 PM, Jeff Ortel  wrote:

>
>
> On 04/10/2018 11:28 AM, Brian Bouterse wrote:
>
> OK so to bring it back to how to manage this in Redmine. We've been
> talking about 'Tags' and I've read a some +1s for their use to track these
> things and no -1s. I want to identify I think it would be better to use the
> 'Category' built-in field of Redmine. Tags can be multi-selcted, but I
> don't think a single issue will need to be a CLI and an Installer and a
> $other_tag all at once (multi-selected). Categories are a single selection
> which seems more appropriate. We also make little use of them today and
> they are built into all Issues redmine has.
>
>
> +1
>
>
>
> Should I make a Categories for 'Ansible Installer', 'CLI' and 'Migration
> Tool' in the Pulp project on Redmine?
>
> Other suggestions and ideas are welcome.
>
>
>
>
> On Tue, Apr 10, 2018 at 11:23 AM, Jeff Ortel  wrote:
>
>>
>>
>> On 04/10/2018 10:15 AM, Jeff Ortel wrote:
>>
>>
>>
>> On 04/04/2018 05:09 PM, Dennis Kliban 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?
>>
>>
>> Separately.
>>
>>
>> Meant to clarify.  The CLI can be released separately but I think the
>> migration tool needs to be released in step with Pulp.  As for the
>> installer .. seems like that also needs to be released in step with Pulp.
>>
>>
>>
>>
>> On Wed, Apr 4, 2018 at 5:41 PM, Austin Macdonald 
>> 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@redhat.com
>>> https://www.redhat.com/mailman/listinfo/pulp-dev
>>>
>>>
>>
>>
>> ___
>> Pulp-dev mailing 
>> listPulp-dev@redhat.comhttps://www.redhat.com/mailman/listinfo/pulp-dev
>>
>>
>>
>>
>> ___
>> Pulp-dev mailing list
>> Pulp-dev@redhat.com
>> https://www.redhat.com/mailman/listinfo/pulp-dev
>>
>>
>
>
> ___
> Pulp-dev mailing list
> Pulp-dev@redhat.com
> https://www.redhat.com/mailman/listinfo/pulp-dev
>
>
___
Pulp-dev mailing list
Pulp-dev@redhat.com
https://www.redhat.com/mailman/listinfo/pulp-dev

Re: [Pulp-dev] Pulp 3 MVP Issue Cleanup

2018-04-10 Thread Jeff Ortel 



On 04/10/2018 11:28 AM, Brian Bouterse wrote:
OK so to bring it back to how to manage this in Redmine. We've been 
talking about 'Tags' and I've read a some +1s for their use to track 
these things and no -1s. I want to identify I think it would be better 
to use the 'Category' built-in field of Redmine. Tags can be 
multi-selcted, but I don't think a single issue will need to be a CLI 
and an Installer and a $other_tag all at once (multi-selected). 
Categories are a single selection which seems more appropriate. We 
also make little use of them today and they are built into all Issues 
redmine has.


+1



Should I make a Categories for 'Ansible Installer', 'CLI' and 
'Migration Tool' in the Pulp project on Redmine?


Other suggestions and ideas are welcome.




On Tue, Apr 10, 2018 at 11:23 AM, Jeff Ortel > wrote:




On 04/10/2018 10:15 AM, Jeff Ortel wrote:



On 04/04/2018 05:09 PM, Dennis Kliban 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?


Separately.


Meant to clarify.  The CLI can be released separately but I think
the migration tool needs to be released in step with Pulp.  As for
the installer .. seems like that also needs to be released in step
with Pulp.






On Wed, Apr 4, 2018 at 5:41 PM, Austin Macdonald
mailto:aus...@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@redhat.com 
https://www.redhat.com/mailman/listinfo/pulp-dev





___
Pulp-dev mailing list
Pulp-dev@redhat.com 
https://www.redhat.com/mailman/listinfo/pulp-dev






___
Pulp-dev mailing list
Pulp-dev@redhat.com 
https://www.redhat.com/mailman/listinfo/pulp-dev





___
Pulp-dev mailing list
Pulp-dev@redhat.com
https://www.redhat.com/mailman/listinfo/pulp-dev

Re: [Pulp-dev] Pulp 3 MVP Issue Cleanup

2018-04-10 Thread Dana Walker 
I like the idea of making better use of existing Redmine functionality by
going with categories over tags if there's no overlap.  +1

Dana Walker

Associate Software Engineer

Red Hat




On Tue, Apr 10, 2018 at 1:20 PM, Austin Macdonald  wrote:

> -0 Ansible installer (since this lives in a totally separate repository)
> +1 CLI
> +1 Migration Tool
>
> On Tue, Apr 10, 2018 at 12:28 PM, Brian Bouterse 
> wrote:
>
>> OK so to bring it back to how to manage this in Redmine. We've been
>> talking about 'Tags' and I've read a some +1s for their use to track these
>> things and no -1s. I want to identify I think it would be better to use the
>> 'Category' built-in field of Redmine. Tags can be multi-selcted, but I
>> don't think a single issue will need to be a CLI and an Installer and a
>> $other_tag all at once (multi-selected). Categories are a single selection
>> which seems more appropriate. We also make little use of them today and
>> they are built into all Issues redmine has.
>>
>> Should I make a Categories for 'Ansible Installer', 'CLI' and 'Migration
>> Tool' in the Pulp project on Redmine?
>>
>> Other suggestions and ideas are welcome.
>>
>>
>>
>>
>> On Tue, Apr 10, 2018 at 11:23 AM, Jeff Ortel  wrote:
>>
>>>
>>>
>>> On 04/10/2018 10:15 AM, Jeff Ortel wrote:
>>>
>>>
>>>
>>> On 04/04/2018 05:09 PM, Dennis Kliban 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?
>>>
>>>
>>> Separately.
>>>
>>>
>>> Meant to clarify.  The CLI can be released separately but I think the
>>> migration tool needs to be released in step with Pulp.  As for the
>>> installer .. seems like that also needs to be released in step with Pulp.
>>>
>>>
>>>
>>>
>>> On Wed, Apr 4, 2018 at 5:41 PM, Austin Macdonald 
>>> 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@redhat.com
 https://www.redhat.com/mailman/listinfo/pulp-dev


>>>
>>>
>>> ___
>>> Pulp-dev mailing 
>>> listPulp-dev@redhat.comhttps://www.redhat.com/mailman/listinfo/pulp-dev
>>>
>>>
>>>
>>>
>>> ___
>>> Pulp-dev mailing list
>>> Pulp-dev@redhat.com
>>> https://www.redhat.com/mailman/listinfo/pulp-dev
>>>
>>>
>>
>> ___
>> Pulp-dev mailing list
>> Pulp-dev@redhat.com
>> https://www.redhat.com/mailman/listinfo/pulp-dev
>>
>>
>
> ___
> Pulp-dev mailing list
> Pulp-dev@redhat.com
> https://www.redhat.com/mailman/listinfo/pulp-dev
>
>
___
Pulp-dev mailing list
Pulp-dev@redhat.com
https://www.redhat.com/mailman/listinfo/pulp-dev

Re: [Pulp-dev] Pulp 3 MVP Issue Cleanup

2018-04-10 Thread Austin Macdonald 
-0 Ansible installer (since this lives in a totally separate repository)
+1 CLI
+1 Migration Tool

On Tue, Apr 10, 2018 at 12:28 PM, Brian Bouterse 
wrote:

> OK so to bring it back to how to manage this in Redmine. We've been
> talking about 'Tags' and I've read a some +1s for their use to track these
> things and no -1s. I want to identify I think it would be better to use the
> 'Category' built-in field of Redmine. Tags can be multi-selcted, but I
> don't think a single issue will need to be a CLI and an Installer and a
> $other_tag all at once (multi-selected). Categories are a single selection
> which seems more appropriate. We also make little use of them today and
> they are built into all Issues redmine has.
>
> Should I make a Categories for 'Ansible Installer', 'CLI' and 'Migration
> Tool' in the Pulp project on Redmine?
>
> Other suggestions and ideas are welcome.
>
>
>
>
> On Tue, Apr 10, 2018 at 11:23 AM, Jeff Ortel  wrote:
>
>>
>>
>> On 04/10/2018 10:15 AM, Jeff Ortel wrote:
>>
>>
>>
>> On 04/04/2018 05:09 PM, Dennis Kliban 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?
>>
>>
>> Separately.
>>
>>
>> Meant to clarify.  The CLI can be released separately but I think the
>> migration tool needs to be released in step with Pulp.  As for the
>> installer .. seems like that also needs to be released in step with Pulp.
>>
>>
>>
>>
>> On Wed, Apr 4, 2018 at 5:41 PM, Austin Macdonald 
>> 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@redhat.com
>>> https://www.redhat.com/mailman/listinfo/pulp-dev
>>>
>>>
>>
>>
>> ___
>> Pulp-dev mailing 
>> listPulp-dev@redhat.comhttps://www.redhat.com/mailman/listinfo/pulp-dev
>>
>>
>>
>>
>> ___
>> Pulp-dev mailing list
>> Pulp-dev@redhat.com
>> https://www.redhat.com/mailman/listinfo/pulp-dev
>>
>>
>
> ___
> Pulp-dev mailing list
> Pulp-dev@redhat.com
> https://www.redhat.com/mailman/listinfo/pulp-dev
>
>
___
Pulp-dev mailing list
Pulp-dev@redhat.com
https://www.redhat.com/mailman/listinfo/pulp-dev

Re: [Pulp-dev] Pulp 3 MVP Issue Cleanup

2018-04-10 Thread Brian Bouterse 
OK so to bring it back to how to manage this in Redmine. We've been talking
about 'Tags' and I've read a some +1s for their use to track these things
and no -1s. I want to identify I think it would be better to use the
'Category' built-in field of Redmine. Tags can be multi-selcted, but I
don't think a single issue will need to be a CLI and an Installer and a
$other_tag all at once (multi-selected). Categories are a single selection
which seems more appropriate. We also make little use of them today and
they are built into all Issues redmine has.

Should I make a Categories for 'Ansible Installer', 'CLI' and 'Migration
Tool' in the Pulp project on Redmine?

Other suggestions and ideas are welcome.




On Tue, Apr 10, 2018 at 11:23 AM, Jeff Ortel  wrote:

>
>
> On 04/10/2018 10:15 AM, Jeff Ortel wrote:
>
>
>
> On 04/04/2018 05:09 PM, Dennis Kliban 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?
>
>
> Separately.
>
>
> Meant to clarify.  The CLI can be released separately but I think the
> migration tool needs to be released in step with Pulp.  As for the
> installer .. seems like that also needs to be released in step with Pulp.
>
>
>
>
> On Wed, Apr 4, 2018 at 5:41 PM, Austin Macdonald 
> 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@redhat.com
>> https://www.redhat.com/mailman/listinfo/pulp-dev
>>
>>
>
>
> ___
> Pulp-dev mailing 
> listPulp-dev@redhat.comhttps://www.redhat.com/mailman/listinfo/pulp-dev
>
>
>
>
> ___
> Pulp-dev mailing list
> Pulp-dev@redhat.com
> https://www.redhat.com/mailman/listinfo/pulp-dev
>
>
___
Pulp-dev mailing list
Pulp-dev@redhat.com
https://www.redhat.com/mailman/listinfo/pulp-dev

Re: [Pulp-dev] Pulp 3 MVP Issue Cleanup

2018-04-10 Thread Jeff Ortel 



On 04/10/2018 10:15 AM, Jeff Ortel wrote:



On 04/04/2018 05:09 PM, Dennis Kliban 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?


Separately.


Meant to clarify.  The CLI can be released separately but I think the 
migration tool needs to be released in step with Pulp.  As for the 
installer .. seems like that also needs to be released in step with Pulp.







On Wed, Apr 4, 2018 at 5:41 PM, Austin Macdonald > 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@redhat.com 
https://www.redhat.com/mailman/listinfo/pulp-dev





___
Pulp-dev mailing list
Pulp-dev@redhat.com
https://www.redhat.com/mailman/listinfo/pulp-dev




___
Pulp-dev mailing list
Pulp-dev@redhat.com
https://www.redhat.com/mailman/listinfo/pulp-dev

Re: [Pulp-dev] Pulp 3 MVP Issue Cleanup

2018-04-10 Thread Jeff Ortel 



On 04/04/2018 05:09 PM, Dennis Kliban 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?


Separately.




On Wed, Apr 4, 2018 at 5:41 PM, Austin Macdonald > 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@redhat.com 
https://www.redhat.com/mailman/listinfo/pulp-dev





___
Pulp-dev mailing list
Pulp-dev@redhat.com
https://www.redhat.com/mailman/listinfo/pulp-dev


___
Pulp-dev mailing list
Pulp-dev@redhat.com
https://www.redhat.com/mailman/listinfo/pulp-dev

Re: [Pulp-dev] Pulp 3 MVP Issue Cleanup

2018-04-10 Thread Jeff Ortel 

Looks great.  Thanks for putting this together!

On 04/04/2018 02:23 PM, Austin Macdonald wrote:
David and I went through all the pulpcore issues that have the "Pulp3 
MVP" tag.


We added this one to the sprint:

  * https://pulp.plan.io/issues/3545


These two need to be updated before we can move forward:

  * @dalley https://pulp.plan.io/issues/3505
  * @asmacdo https://pulp.plan.io/issues/3546


We marked these as groomed, unless someone says "no", I plan to add 
all of these to the sprint.


  * https://pulp.plan.io/issues/3082
  * https://pulp.plan.io/issues/3081
  * https://pulp.plan.io/issues/3220
  * https://pulp.plan.io/issues/3298
  * https://pulp.plan.io/issues/3395

We have some vagrant/ansible issues. I don't think these really belong 
in the "Pulp" project tracker. Mind if we move them to the 
"Infrastructure" project? (BTW, there are a lot more, just without the 
MVP tag).


  * https://pulp.plan.io/issues/3439
  * https://pulp.plan.io/issues/2922






___
Pulp-dev mailing list
Pulp-dev@redhat.com
https://www.redhat.com/mailman/listinfo/pulp-dev


___
Pulp-dev mailing list
Pulp-dev@redhat.com
https://www.redhat.com/mailman/listinfo/pulp-dev

Re: [Pulp-dev] Pulp 3 MVP Issue Cleanup

2018-04-10 Thread Austin Macdonald 
On Tue, Apr 10, 2018 at 8:17 AM, David Davis  wrote:

> So the only content filter we have on the MVP doc is repo version. I think
> this might be tricky and you can already view content for a repository
> version (ie /api/v3/repositories//versions//content) so I
> think we should just leave this out of the MVP.
>
>
That's fine with me. I'll update the issue.

David
>
> On Mon, Apr 9, 2018 at 12:19 PM, Austin Macdonald 
> wrote:
>
>> Here's another one that needs to be groomed and added to the
>> sprint(thanks kersom!)
>>
>>- (@David maybe?) Content Filters https://pulp.plan.io/issues/3084
>>
>>
>> All of these have been added to the sprint:
>>
>>- https://pulp.plan.io/issues/3552
>>- https://pulp.plan.io/issues/3395
>>- https://pulp.plan.io/issues/3298
>>- https://pulp.plan.io/issues/3220
>>- https://pulp.plan.io/issues/3081
>>- https://pulp.plan.io/issues/3082
>>- https://pulp.plan.io/issues/3546
>>
>>
>>
>>
>> On Thu, Apr 5, 2018 at 9:53 AM, Austin Macdonald 
>> wrote:
>>
>>> David and I went through all the pulpcore issues that have the "Pulp3
 MVP" tag.
 We added this one to the sprint:

- https://pulp.plan.io/issues/3545


 These two need to be updated before we can move forward:

- @dalley https://pulp.plan.io/issues/3505


- @asmacdo https://pulp.plan.io/issues/3546


 We marked these as groomed, unless someone says "no", I plan to add all
 of these to the sprint.

- https://pulp.plan.io/issues/3082


- https://pulp.plan.io/issues/3081


- https://pulp.plan.io/issues/3220


- https://pulp.plan.io/issues/3298


- https://pulp.plan.io/issues/3395


>>>
 We have some vagrant/ansible issues. I don't think these really belong
 in the "Pulp" project tracker. Mind if we move them to the "Infrastructure"
 project? (BTW, there are a lot more, just without the MVP tag).

- https://pulp.plan.io/issues/3439


- https://pulp.plan.io/issues/2922

 Adding to these lists:
>>> Needs grooming and addding to spring: https://pulp.plan.io/issues/3552
>>>
>>
>>
>
___
Pulp-dev mailing list
Pulp-dev@redhat.com
https://www.redhat.com/mailman/listinfo/pulp-dev

Re: [Pulp-dev] Pulp 3 MVP Issue Cleanup

2018-04-10 Thread David Davis 
So the only content filter we have on the MVP doc is repo version. I think
this might be tricky and you can already view content for a repository
version (ie /api/v3/repositories//versions//content) so I
think we should just leave this out of the MVP.


David

On Mon, Apr 9, 2018 at 12:19 PM, Austin Macdonald  wrote:

> Here's another one that needs to be groomed and added to the sprint(thanks
> kersom!)
>
>- (@David maybe?) Content Filters https://pulp.plan.io/issues/3084
>
>
> All of these have been added to the sprint:
>
>- https://pulp.plan.io/issues/3552
>- https://pulp.plan.io/issues/3395
>- https://pulp.plan.io/issues/3298
>- https://pulp.plan.io/issues/3220
>- https://pulp.plan.io/issues/3081
>- https://pulp.plan.io/issues/3082
>- https://pulp.plan.io/issues/3546
>
>
>
>
> On Thu, Apr 5, 2018 at 9:53 AM, Austin Macdonald 
> wrote:
>
>> David and I went through all the pulpcore issues that have the "Pulp3
>>> MVP" tag.
>>> We added this one to the sprint:
>>>
>>>- https://pulp.plan.io/issues/3545
>>>
>>>
>>> These two need to be updated before we can move forward:
>>>
>>>- @dalley https://pulp.plan.io/issues/3505
>>>
>>>
>>>- @asmacdo https://pulp.plan.io/issues/3546
>>>
>>>
>>> We marked these as groomed, unless someone says "no", I plan to add all
>>> of these to the sprint.
>>>
>>>- https://pulp.plan.io/issues/3082
>>>
>>>
>>>- https://pulp.plan.io/issues/3081
>>>
>>>
>>>- https://pulp.plan.io/issues/3220
>>>
>>>
>>>- https://pulp.plan.io/issues/3298
>>>
>>>
>>>- https://pulp.plan.io/issues/3395
>>>
>>>
>>
>>> We have some vagrant/ansible issues. I don't think these really belong
>>> in the "Pulp" project tracker. Mind if we move them to the "Infrastructure"
>>> project? (BTW, there are a lot more, just without the MVP tag).
>>>
>>>- https://pulp.plan.io/issues/3439
>>>
>>>
>>>- https://pulp.plan.io/issues/2922
>>>
>>> Adding to these lists:
>> Needs grooming and addding to spring: https://pulp.plan.io/issues/3552
>>
>
>
___
Pulp-dev mailing list
Pulp-dev@redhat.com
https://www.redhat.com/mailman/listinfo/pulp-dev

Re: [Pulp-dev] Pulp 3 MVP Issue Cleanup

2018-04-09 Thread Austin Macdonald 
Here's another one that needs to be groomed and added to the sprint(thanks
kersom!)

   - (@David maybe?) Content Filters https://pulp.plan.io/issues/3084


All of these have been added to the sprint:

   - https://pulp.plan.io/issues/3552
   - https://pulp.plan.io/issues/3395
   - https://pulp.plan.io/issues/3298
   - https://pulp.plan.io/issues/3220
   - https://pulp.plan.io/issues/3081
   - https://pulp.plan.io/issues/3082
   - https://pulp.plan.io/issues/3546




On Thu, Apr 5, 2018 at 9:53 AM, Austin Macdonald  wrote:

> David and I went through all the pulpcore issues that have the "Pulp3 MVP"
>> tag.
>> We added this one to the sprint:
>>
>>- https://pulp.plan.io/issues/3545
>>
>>
>> These two need to be updated before we can move forward:
>>
>>- @dalley https://pulp.plan.io/issues/3505
>>
>>
>>- @asmacdo https://pulp.plan.io/issues/3546
>>
>>
>> We marked these as groomed, unless someone says "no", I plan to add all
>> of these to the sprint.
>>
>>- https://pulp.plan.io/issues/3082
>>
>>
>>- https://pulp.plan.io/issues/3081
>>
>>
>>- https://pulp.plan.io/issues/3220
>>
>>
>>- https://pulp.plan.io/issues/3298
>>
>>
>>- https://pulp.plan.io/issues/3395
>>
>>
>
>> We have some vagrant/ansible issues. I don't think these really belong in
>> the "Pulp" project tracker. Mind if we move them to the "Infrastructure"
>> project? (BTW, there are a lot more, just without the MVP tag).
>>
>>- https://pulp.plan.io/issues/3439
>>
>>
>>- https://pulp.plan.io/issues/2922
>>
>> Adding to these lists:
> Needs grooming and addding to spring: https://pulp.plan.io/issues/3552
>
___
Pulp-dev mailing list
Pulp-dev@redhat.com
https://www.redhat.com/mailman/listinfo/pulp-dev

Re: [Pulp-dev] Pulp 3 MVP Issue Cleanup

2018-04-05 Thread Dennis Kliban 
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  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 
> wrote:
>
>>
>>
>> On Wed, Apr 4, 2018 at 6:09 PM, Dennis Kliban  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 
>>> 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@redhat.com
 https://www.redhat.com/mailman/listinfo/pulp-dev


>>>
>>
>> ___
>> Pulp-dev mailing list
>> Pulp-dev@redhat.com
>> https://www.redhat.com/mailman/listinfo/pulp-dev
>>
>>
>
___
Pulp-dev mailing list
Pulp-dev@redhat.com
https://www.redhat.com/mailman/listinfo/pulp-dev

Re: [Pulp-dev] Pulp 3 MVP Issue Cleanup

2018-04-05 Thread Ina Panova 
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  wrote:

>
>
> On Wed, Apr 4, 2018 at 6:09 PM, Dennis Kliban  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 
>> 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@redhat.com
>>> https://www.redhat.com/mailman/listinfo/pulp-dev
>>>
>>>
>>
>
> ___
> Pulp-dev mailing list
> Pulp-dev@redhat.com
> https://www.redhat.com/mailman/listinfo/pulp-dev
>
>
___
Pulp-dev mailing list
Pulp-dev@redhat.com
https://www.redhat.com/mailman/listinfo/pulp-dev

Re: [Pulp-dev] Pulp 3 MVP Issue Cleanup

2018-04-04 Thread Austin Macdonald 
On Wed, Apr 4, 2018 at 6:09 PM, Dennis Kliban  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 
> 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@redhat.com
>> https://www.redhat.com/mailman/listinfo/pulp-dev
>>
>>
>
___
Pulp-dev mailing list
Pulp-dev@redhat.com
https://www.redhat.com/mailman/listinfo/pulp-dev

Re: [Pulp-dev] Pulp 3 MVP Issue Cleanup

2018-04-04 Thread Dennis Kliban 
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?


On Wed, Apr 4, 2018 at 5:41 PM, Austin Macdonald  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@redhat.com
> https://www.redhat.com/mailman/listinfo/pulp-dev
>
>
___
Pulp-dev mailing list
Pulp-dev@redhat.com
https://www.redhat.com/mailman/listinfo/pulp-dev

Re: [Pulp-dev] Pulp 3 MVP Issue Cleanup

2018-04-04 Thread Austin Macdonald 
>
>
>> 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@redhat.com
https://www.redhat.com/mailman/listinfo/pulp-dev

Re: [Pulp-dev] Pulp 3 MVP Issue Cleanup

2018-04-04 Thread Brian Bouterse 
All this looks good to me, ty so much for organizing. I left 1 inline
comment

On Wed, Apr 4, 2018 at 3:23 PM, Austin Macdonald  wrote:

> David and I went through all the pulpcore issues that have the "Pulp3 MVP"
> tag.
>
> We added this one to the sprint:
>
>- https://pulp.plan.io/issues/3545
>
>
> These two need to be updated before we can move forward:
>
>- @dalley https://pulp.plan.io/issues/3505
>- @asmacdo https://pulp.plan.io/issues/3546
>
>
> We marked these as groomed, unless someone says "no", I plan to add all of
> these to the sprint.
>
>- https://pulp.plan.io/issues/3082
>- https://pulp.plan.io/issues/3081
>- https://pulp.plan.io/issues/3220
>- https://pulp.plan.io/issues/3298
>- https://pulp.plan.io/issues/3395
>
> We have some vagrant/ansible issues. I don't think these really belong in
> the "Pulp" project tracker. Mind if we move them to the "Infrastructure"
> project? (BTW, there are a lot more, just without the MVP tag).
>
>- https://pulp.plan.io/issues/3439
>- https://pulp.plan.io/issues/2922
>
> 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'?

>
>-
>
>
>
>
>
> ___
> Pulp-dev mailing list
> Pulp-dev@redhat.com
> https://www.redhat.com/mailman/listinfo/pulp-dev
>
>
___
Pulp-dev mailing list
Pulp-dev@redhat.com
https://www.redhat.com/mailman/listinfo/pulp-dev

[Pulp-dev] Pulp 3 MVP Issue Cleanup

2018-04-04 Thread Austin Macdonald 
David and I went through all the pulpcore issues that have the "Pulp3 MVP"
tag.

We added this one to the sprint:

   - https://pulp.plan.io/issues/3545


These two need to be updated before we can move forward:

   - @dalley https://pulp.plan.io/issues/3505
   - @asmacdo https://pulp.plan.io/issues/3546


We marked these as groomed, unless someone says "no", I plan to add all of
these to the sprint.

   - https://pulp.plan.io/issues/3082
   - https://pulp.plan.io/issues/3081
   - https://pulp.plan.io/issues/3220
   - https://pulp.plan.io/issues/3298
   - https://pulp.plan.io/issues/3395

We have some vagrant/ansible issues. I don't think these really belong in
the "Pulp" project tracker. Mind if we move them to the "Infrastructure"
project? (BTW, there are a lot more, just without the MVP tag).

   - https://pulp.plan.io/issues/3439
   - https://pulp.plan.io/issues/2922
___
Pulp-dev mailing list
Pulp-dev@redhat.com
https://www.redhat.com/mailman/listinfo/pulp-dev