I have a mild preference that we avoid creating demo branches in the master vpp repo. When faced with similar requirements, I’ve added branch(es) to ephemeral downstream mirrors.
I suppose one could destroy demo branches in the master vpp repo, but “something could go wrong...” Thoughts? Thanks... Dave From: Dave Wallace [mailto:dwallac...@gmail.com] Sent: Wednesday, November 15, 2017 5:17 PM To: 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>; Ole Troan (otroan) <otr...@cisco.com>; vpp-dev@lists.fd.io Subject: Discussion Topic: creating demo branches in git.fd.io/vpp 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
