Request for a new vue3 branch in webui-vue

Ed Tanous ed at tanous.net
Thu Jun 27 08:24:13 AEST 2024


On Wed, Jun 26, 2024 at 3:10 PM Patrick Williams <patrick at stwcx.xyz> wrote:
>
> On Wed, Jun 26, 2024 at 02:57:25PM -0700, Ed Tanous wrote:
> > On Wed, Jun 26, 2024 at 2:40 PM Patrick Williams <patrick at stwcx.xyz> wrote:
> > >
> > > On Wed, Jun 26, 2024 at 02:46:29PM -0600, Gunnar M wrote:
> > > > Kiran and his team have volunteered to sync patches merged to master to this new 'vue3' branch bi-weekly. Thank you, Kiran! When the migration to Vue 3 is complete, and all commits are synced over, this 'vue3' branch will become the 'master' branch.
> > >
> > > We need to be careful about how we do this.  You don't want it to appear
> > > on github as a rewrite of the "master" branch and we absolutely need to
> > > at least keep the vue2 code in some branch so that it doesn't get pruned
> > > from the github history.  If we don't do this, it will become impossible
> > > for people to build older OpenBMC releases.
> > >
> > > I would suggest either:
> > >
> > >     a. We do the opposite: create a 'vue2' branch and update the recipe
> > >        to point at it.
> > >
> > >     b. We use this as an opportunity to migrate from 'master' to 'main'
> > >        and use 'main' as the vue3 branch.
> >
> >
> > My expectation was that this branch continues to rebase in patches,
> > and once ready to merge, we would just rebase the series on top of
> > master before pushing it so there's no discontinuity, no merge commit,
> > and autobump would just pick it up.
>
> We would have to give "Kiran and his team" permissions in Gerrit to
> force-push to the "vue3" branch in order to facilitate these rebases.

Sorry, I should've said "My expectation was that this branch continues
to cherry-pick in patches"

There'd only be one rebase and push (not force I think?), right at the
end, and I'm happy to do the final merge if that solves the
permissions problem.  I suspect even if we had to reopen a
sensibly-squashed gerrit series for re-review after we thought the
bugs were solved, that might be reasonable, although it's hard to know
based on what's in there.

> It also means potentially unreviewed content ends up in the branch due
> to this permission.
>
> I'm okay with going this route but wanted to make sure everyone is aware
> of the implications.
>
> --
> Patrick Williams


More information about the openbmc mailing list