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 <jor...@redhat.com> 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 <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 > 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
