+2, (3 w/jdl) though be prepared to see questions about when the repo will be updated for the rest of time. (GitHub can be a kind of roach motel for code.)
Cherry-picking is OK, when it’s a 1-2x thing, but when you start carrying diverging branches, the occurrence of “oops, forgot that one” starts to rise. Jim > On Nov 15, 2017, at 2:55 PM, Dave Barach (dbarach) <dbar...@cisco.com> wrote: > > +1... > > -----Original Message----- > From: Ole Troan [mailto:otr...@employees.org] > Sent: Wednesday, November 15, 2017 5:49 PM > To: Dave Wallace <dwallac...@gmail.com> > Cc: Ed Warnicke <hagb...@gmail.com>; Dave Barach (dbarach) > <dbar...@cisco.com>; Keith Burns (krb) <k...@cisco.com>; Florin Coras > (fcoras) <fco...@cisco.com>; John Lo (loj) <l...@cisco.com>; Luke, Chris > <chris_l...@comcast.com>; Damjan Marion <dmarion.li...@gmail.com>; Neale > Ranns (nranns) <nra...@cisco.com>; vpp-dev@lists.fd.io > Subject: Re: [vpp-dev] Discussion Topic: creating demo branches in > git.fd.io/vpp > > Just as a data-point. > What we have done for IETF hackathons is to create a branch on github. E.g: > > https://github.com/vpp-dev/vpp/tree/ietf100-nat > > This allows us to do "high speed collaboration". Then cherry pick what has > value after the event. > Perhaps something similar could be done for "demos"? > > Cheers, > Ole > >> On 16 Nov 2017, at 06:17, Dave Wallace <dwallac...@gmail.com> wrote: >> >> Folks, >> >> Per the action item from this yesterday's VPP weekly meeting, I'm asking for >> opinions from the VPP community on allowing the creation of demo branches in >> the VPP git repo. >> >> The definition of a demo branch is defined as a branch pulled from master >> that: >> >> 1) Purpose is to demonstrate a VPP use case at a public conference/symposium >> (kubecon 2017 as the 1st instance). >> 2) The branch will never be merged back into master. >> 2) Commits to the branch will be cherry-picked/double-committed to master. >> >> Some comments I recall from memory (please forgive me if I have left any >> comments out): >> >> Pro: Will allow utilization of LF infra to utilize CI process >> Pro: Will allow publishing of demo artifacts for ease of reproduction of the >> demo. >> Con: Will pollute repo with ephemeral code that will rapidly become out of >> date / dead. >> Con: Sets precedent which may cause large numbers of non-production branches >> over time. >> >> Please feel add additional Pro/Con comments here. Comments are welcome from >> all members of the VPP community. >> >> I will begin with my thoughts since yesterday's meeting: >> >> Con: In order for the CI infra to be utilized, the addition of demo branch >> specific jenkins jobs needs to be added to ci-management (polluting that >> repo as well). >> Con: May add overhead to CSIT project in triaging any CSIT failures on the >> demo branch. >> Con: Adds overhead to already over-subscribed committer task workload >> (reviewing commits to demo branch & double commits to main) >> >> >> IMHO, this proposal has the potential to cause the VPP committer workload to >> spiral out of control thus disrupting the regular release cadence. >> >> ---- >> @Ed, >> >> It might be a good idea to include the ci-management and CSIT projects in >> this discussion since those projects may be affected by this proposal. I'll >> let you decide whether or not to add additional projects to the discussion? >> >> As the TSC Chairperson, I will let you decide when to close the discussion >> and call for a vote of the committers (whom I addressed directly on this >> email). >> ---- >> >> Thanks, >> -daw- >> >> _______________________________________________ >> vpp-dev mailing list >> vpp-dev@lists.fd.io >> https://lists.fd.io/mailman/listinfo/vpp-dev > > _______________________________________________ > vpp-dev mailing list > vpp-dev@lists.fd.io > https://lists.fd.io/mailman/listinfo/vpp-dev _______________________________________________ vpp-dev mailing list vpp-dev@lists.fd.io https://lists.fd.io/mailman/listinfo/vpp-dev
