[EXTERNAL] Re: Request for a new vue3 branch in webui-vue

Kiran Kumar B kirankumarb at ami.com
Thu Jul 11 14:44:37 AEST 2024


Hi All,

Agree on latest @Gunnar M comments. So shall we process vue3 branch creation further if no other concerns.

Regards,
Kiran.
-----Original Message-----
From: Gunnar M <gunnar at gmills.xyz>
Sent: Thursday, July 4, 2024 2:04 AM
To: Andrew Jeffery <andrew at codeconstruct.com.au>; Ed Tanous <ed at tanous.net>; Patrick Williams <patrick at stwcx.xyz>
Cc: Kiran Kumar B <kirankumarb at ami.com>; openbmc at lists.ozlabs.org; a.nikhil at ibm.com; Renuka.Sharanya.Pundla at ibm.com; Sivaprabu G <sivaprabug at ami.com>
Subject: [EXTERNAL] Re: Request for a new vue3 branch in webui-vue


**CAUTION: The e-mail below is from an external source. Please exercise caution before opening attachments, clicking links, or following guidance.**

> On 06/26/2024 7:06 PM MDT Andrew Jeffery <andrew at codeconstruct.com.au> wrote:
>
>
> On Wed, 2024-06-26 at 15:24 -0700, Ed Tanous wrote:
> > 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,
>
> You don't have to rebase either. Another option is to use `git merge
> -s ours` to join the branch histories but set the tree state in favour
> of one side.
>

Does `git merge -s ours` work? And then go with a new `vue3` branch?

If not, I am okay with using this as an opportunity to migrate from 'master' to 'main'. It is just a bit unexpected. If we go that route, we can add some temporary documentation.

I was thinking Kiran and team would cherry-pick patches merged to 'master' and push them to the 'vue3' branch, leaving the original author's signed-off, etc. I wasn't thinking any special permissions would be needed until "merging" the branches at the end.

Thanks,
Gunnar
-The information contained in this message may be confidential and proprietary to American Megatrends (AMI). This communication is intended to be read only by the individual or entity to whom it is addressed or by their designee. If the reader of this message is not the intended recipient, you are on notice that any distribution of this message, in any form, is strictly prohibited. Please promptly notify the sender by reply e-mail or by telephone at 770-246-8600, and then delete or destroy all copies of the transmission.


More information about the openbmc mailing list