The content of 3209 as a "feature epic" captures the claim of functionality from the user's perspective, so it's silent on how the internals work. Pulp doesn't have formal planning requirements yet, so we're kind of making it up this idea of what a good "epic looks like" as we go. I'm interested on more perspectives make a good epic feature plan.
For this feature, implementation-wise, it's the same database model as originally proposed by @mhrivnak. Details of the implementation aspects and internals are in the child tickets of the epic (2909). Featureset-wise the design is what we captured on the MVP calls; there were no changes from the feature as written on the MVP page. If there is more we can do to answer questions or make the tickets more clear, please send more ideas/questions. On Thu, Jan 4, 2018 at 5:20 PM, Jeff Ortel <[email protected]> wrote: > Looking at 3209, I don't see the actual design documented. > > > On 01/03/2018 04:58 PM, Dennis Kliban wrote: > > @bmbouter, @daviddavis, and I have put together a plan for implementing > repository version use cases. The overall design is captured in issue > 3209[0]. The individual use cases are captured in the child stories. > > Please take a look at these stories and provide feedback ASAP. We'd like > to add most of these stories to the sprint during planning on Friday. > > > [0] https://pulp.plan.io/issues/3209 > > > _______________________________________________ > Pulp-dev mailing > [email protected]https://www.redhat.com/mailman/listinfo/pulp-dev > > > > _______________________________________________ > Pulp-dev mailing list > [email protected] > https://www.redhat.com/mailman/listinfo/pulp-dev > >
_______________________________________________ Pulp-dev mailing list [email protected] https://www.redhat.com/mailman/listinfo/pulp-dev
