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

[Brian Bouterse]

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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/pulp-dev/attachments/20161109/4479910b/attachment.htm>