Virtual Media repository request

[Ed Tanous]

On Mon, Dec 19, 2022 at 6:02 AM Czarnowski, Przemyslaw <
przemyslaw.hawrylewicz.czarnowski at linux.intel.com> wrote:

> On 23.12.2021 02:01, Czarnowski, Przemyslaw wrote:
> > On 20.12.2021 13:54, Czarnowski, Przemyslaw wrote:
> >>
> >> I plan to start pushing changes here this week.
> >>
> > Replying to myself, but just pushed a series of first 4 patches to
> review.
> >
> > It is just a skeleton (infrastructure to build main flows on) but wanted
> > to get the first reviews for initial changes (transition from old
> > content to the new one in particular).
> >
>
> I would like to rise the request for new service of Virtual Media
> repository once again.
>
> Recently I've made an attempt to push VM service patches once again
> after UT has been added. In the meantime, I've noticed that in order to
> make a graceful transition between old and new solution the final switch
> between the old and new code should be made at the moment when the last
> patch is accepted.
>
> There are two main reason why I would like to recall the discussion.
> First is the voice of the maintainer of the old service.


What does "voice" mean in the above?  Can you elaborate on the problem, and
give some specific examples (ideally links to the gerrit reviews)?


> Second -
> problems with linting and CI which wants to build and test both projects
> simultaneously.
>

Same thing here, can you give specific examples?  The linting is just
enforcing the coding standard, and testing two executables at the same time
is something many other repositories do.


>
> Of course the decision does not belong to me. I just do not want mess
> with current CI to support this transitional state.
>

My opinion still remains the same, let's keep everything in one
repository.  If you need help in CI to do that, let's talk about the
specific things that are blocking, and we can go from there.


>
> --
> Best regards,
> Przemyslaw Czarnowski
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ozlabs.org/pipermail/openbmc/attachments/20221219/72c65230/attachment-0001.htm>