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

[Ina Panova]

I tend to agree with Brian.

I agree that with creation of another project will confuse more the users.
I also like the idea of creation new tags, or renaming existing ones more than creation of new project.


--------
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."


----- Original Message -----
From: "Brian Bouterse" <bbouters at redhat.com>
To: "Elyezer Rezende" <erezende at redhat.com>
Cc: pulp-dev at redhat.com
Sent: Wednesday, November 9, 2016 10:24:31 PM
Subject: Re: [Pulp-dev] RFC: new redmine project for pulp 3 ?

I would like to continue using our existing Redmine projects as we transition from 2.y to 3.y. I think users will be even more confused in our already confusing Redmine. Also I want to keep the Redmine Care-And-Feeding™ to a minimum. 

I can understand the challenge in currently tracking a "pulp 3 MVP" vs "pulp 3 after-MVP" issue. I have a few ideas in this area: 

* Let's not spend any time/energy on Pulp 3 post MVP things. This is an opportunity cost argument, and any time spent planning for after the MVP delays the MVP. 
* If we absolutely have to have a way to enter and track those things we can make a 'Pulp 3 Future Feature' or 'Pulp 3 After MVP'. There are only a few (like ~2) issues like this that I know of. 
* Maybe renaming the 'Pulp 3' tag to 'Pulp 3 MVP' would be good? 
* We can probably delete the prefactor tag. I think that ship has sailed. 

In terms of how to deal with the fact that almost all of our bugs won't be relevant to Pulp3, as we are closer to the Pulp3 release date we can put together a simple plan then. I don't think a new Redmine project will help us with this work and more than a mass tag would for example. 

Thoughts? 


On Wed, Nov 9, 2016 at 9:26 AM, Elyezer Rezende < erezende at redhat.com > 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? 



- 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 
Pulp-dev at redhat.com 
https://www.redhat.com/mailman/listinfo/pulp-dev 



_______________________________________________
Pulp-dev mailing list
Pulp-dev at redhat.com
https://www.redhat.com/mailman/listinfo/pulp-dev