[Pulp-dev] RFC: new redmine project for pulp 3 ?

Elyezer Rezende erezende at redhat.com
Wed Nov 9 14:26:13 UTC 2016

I can't provide a full feedback but will leave some thoughts:

State of the "Pulp" project in redmine now:
> - There is a huge backlog of pulp 2 issues, most of which will become
> irrelevant or implicitly resolved by pulp 3. We'll need to do a big purge
> eventually.

Doing a purge means that relevant issues will be marked as resolved for
Pulp 3? I mean we will eventually go through all pending issues and do so
sort of review of them? Or it will be just check them all and close?

> - Nearly all new issues added will be for pulp 3. Only bug reports and a
> very small number of RFEs will be added for pulp 2.

If we still have the majority of customers using Pulp 2 then maybe the
majority of the issues can be Pulp 2 related. Do we already have any
position about some of our customers willing to upgrade to Pulp 3? Also
having a seamless upgrade path from 2 to 3 would be great and ease that

> Since pulp 3 is such a major refactor/rewrite, it might make sense to have
> hard separation between pulp 2 and 3 issues. Within a separate pulp 3 issue
> tracker, we could identify what qualifies for the MVP using a tag, and only
> move over issues from the pulp 2 tracker that are identified as relevant.

Yes, having a separated project makes sense here. That will make easy to
separate what is 2 and what is 3 related stuff. But we may be in a spot
where we need to deal with two projects in order to define milestones,
sprints, etc, at least until Pulp 2 is fully deprecated.

> Potential Downsides:
> - If we do it for platform, would we also do it for all of the plugins and
> other remine projects? It might still be worth it, but that increases the
> complexity of this change.

Having it for platform makes sense but plugins I am not sure since they
have a separate versioning process. Also would a particular version of a
plugin be compatible with both Pulp 2 and 3, does it make sense at all?

> - Does it impact any team processes, automation, etc?

For QE processes I think that will not be an issue since we can target the
proper issues for skipping/selecting tests, that is the major usage of
Redmine issues on QE automation.

> - Will it be confusing to users? I think we could keep that straight, and
> it's easy to move an issue from one project to another if someone files a
> bug in the wrong place.

I is not confusing for most of the cases I can think of, except if for some
reason an issue can be relevant for both Pulp 2 and 3 (when this happens
should we have separated issues?). I can't think on an example of an issue
being required for both versions but wanted to bring it up.

I hope you find my comments useful or at least can open up for some further


Elyézer Rezende
Senior Quality Engineer
irc: elyezer
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/pulp-dev/attachments/20161109/a0c9bb04/attachment.htm>

More information about the Pulp-dev mailing list