On Wed, Nov 9, 2016 at 9:26 AM, Elyezer Rezende <[email protected]> wrote:
> 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? > Each issue will be considered before being closed. > > >> - 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. > Looking at our bug traffic recently, it is quite low. Pulp 2 is not changing very much, so we aren't introducing many new bugs. The pace of change will continue to slow. That is why I predict that a relatively small number of issues will be filed against pulp 2. > > >> 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. > Sprints (milestones) are already defined in one project and shared with all the others in redmine. > > >> 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? > Plugins will require as much refactor/rewrite as the platform. > > >> - 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. > Yes, the code bases are so different, I think we'll soon want to have separate issues to track a fix in 2 and 3, in those cases where a bug applies to both. > > I hope you find my comments useful or at least can open up for some > further conversation. > Definitely. Thanks! Michael
_______________________________________________ Pulp-dev mailing list [email protected] https://www.redhat.com/mailman/listinfo/pulp-dev
