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

[Michael Hrivnak]

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?
>

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