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 process. > 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 conversation. Cheers -- Elyézer Rezende Senior Quality Engineer irc: elyezer
_______________________________________________ Pulp-dev mailing list [email protected] https://www.redhat.com/mailman/listinfo/pulp-dev
