[Starlingx-discuss] Cores meeting minutes 8/16/18
Agenda and notes for the 8/16 call: * Governance o The current draft is good and acceptable to the Core team. We suggest appointing four members to the Initial TSC - Dean, Saul, Brent and Ian. We have an open issue in regard to how/when/if the TSC should grow in the Bootstrapping phase. We are looking for guidance from the Foundation in how to handle this. * Project lead for the Networking team? Candidates are Ghada and Forrest. Park this for now until we can ask them if they even want the job. * Centos 7.5 upgrade status and plan o Ada's test content is minimal at this point. Will take time to ramp that up. o Brent can talk to the WR test lead to see if cycles can be run there o Do we pull a branch for this? Only Brian (sniff) and Dean have the ability to create branches right now. Dean to ramp Scott and Saul to that list. o Issues with branching (in general) * They tend to hang around and create technical debt. Can fall behind mainline development - needs to be periodically rebased to master (weekly). * If we do this on mainline all reviews are highly visible. On a branch less so. * There might be hundreds of checkins for this upgrade * People tend to ignore and not review feature branches, but the changes do need active review. o Dean to start a thread on the mailing list to continue the discussion there. Given the above he thinks a feature branch is an easier sell. * EdgeX foundry discussion - Ian o Bruce met with Intel folks working on the project. Possible ways for StarlingX to be part of their overall architecture, in what they call the "System Management" layer. Needs deeper technical / architectural analysis. o We need to be aware of this project and figure out our plan of engagement. * Multti-OS support / enablement o Intel is looking to enable support for Clear Linux. Supporting Ubuntu would have more impact in the community. Key work items would be supporting multiple package managers and (somehow) keeping the KPIs intact. o We (Brent, Ian, Saul, Dean) need to prep for a deep discussion on this topic at the PTG. o Saul is working on a way to abstract out the configuration patches into some other mechanism. o Need to review / design a way to handle multiple installers, how to build the abstraction layers needed in Update, etc... o Containerizing more content in Docker images can help with middleware layers, but they still need an OS image to run against. It may also cause us other issues e.g. how do we update all of the containers when the OS changes. o Ian will facilitate a call to start this effort. * Spec process - discuss o How do we scale specs from small micro-feature (1-2 commits) to major features with multiple commits over a long time? o How to we store, review, process, approve specs? o We should require some level of spec for any feature that introduces new patches o Keep it lightweight, low friction. Provide guidelines to make this easy. o Using a repo for specs allows the discussion to be captured there. Using LP isn't a great way to have a discussion. Dean doesn't recommend using LP Blueprints. Team agrees that we should establish a stx-specs repo. Saul to create the repo with Dean's guidance. o Further discussions on the spec process deferred to next time * http://starlingx.io<http://starlingx.io/> is not using HTTPS. Long term plan is for the Foundation to deploy a new content management system which should be happening Soon(tm).
On Thu, Aug 16, 2018 at 10:04 AM, Jones, Bruce E <bruce.e.jones@intel.com> wrote:
· Centos 7.5 upgrade status and plan [...] o Do we pull a branch for this? Only Brian (sniff) and Dean have the ability to create branches right now. Dean to ramp Scott and Saul to that list.
For the record, this is controlled by the starlingx-release group in Gerrit.
o Issues with branching (in general)
They tend to hang around and create technical debt. Can fall behind mainline development - needs to be periodically rebased to master (weekly).
If we do this on mainline all reviews are highly visible. On a branch less so.
There might be hundreds of checkins for this upgrade
People tend to ignore and not review feature branches, but the changes do need active review.
o Dean to start a thread on the mailing list to continue the discussion there. Given the above he thinks a feature branch is an easier sell.
[Much of this was written yesterday before the meeting so there is overlap with the above; the purpose in writing this down is to start shaping the guidelines we use for this in the future...] Feature branches are useful things, however they have costs and downsides and I believe the bar for creating them should be higher than things like milestone branches. I'll outline the things on my mind to consider here Some of the reasons to create a feature branch is to make it easier to to focus on a set of changes without having other things change out from under you. This can also be done directly in Gerrit using the repo manifest to control what gets pulled out of Gerrit, pulling code directly from one (or a stack of) review. Everyone can do this on their own or can coordinate with shared manifest files. There is also a social benefit in structuring batches of reviews to not make things terrible for other developers in a project. Coordinating that work requires communication (a good thing) but also timezone overlap is extremely helpful here. Working in isolation is rarely friendly to the other developers, and sometimes feature branch reviews get de-prioritized by reviews not working on them directly. This is just something the project team needs to stay aware of and try to minimize. One of the issues with a feature branch is divergence from master over time. This must be countered by periodically rebasing the feature branch on master and not just waiting until the feature branch is ready to be merged back in to master. Doing the work inline will help find merge conflicts as they happen, with the feature branch they are generally only found when doing this rebase. This also puts the burden of resolving the conflicts on the feature branch and not master. I would suggest we set a maximum time between master rebases for each feature branch created to try and balance these issues. Another significant tradeoff is with regards to testing. A feature branch requires a distinct testing effort for things not covered directly by CI/CD. This means additional hours spent by QA people. However when this effort is of a different nature this separation may be desirable, as Brent pointed out on the call this morning in the current case. In the end I am leaning strongly toward creating the feature branch for the 7.5 work due primarily to a) the testing brought up by Brent, and b) the sheer volume of expected reviews. Managing a couple hundred stacked reviews with a manifest may be doable but we just do not have that experience to do work on that scale yet. That said, I would like to see at least weekly rebases with master to keep the divergence to a sane level. Also, we should only branch in the repos where it is actually needed, not in all 50+. The list of those repos that have been branched can be extracted from the manifest file, which will have a matching feature branch similar to the milestone branches. I am sure I've left out in the above some of the things I've mention in conversations earlier this week... dt -- Dean Troyer dtroyer@gmail.com
Let's go ahead and pull a branch for this. Dean, can you enable Saul and/or Yong to do this? brucej -----Original Message----- From: Dean Troyer [mailto:dtroyer@gmail.com] Sent: Thursday, August 16, 2018 11:45 AM To: Jones, Bruce E <bruce.e.jones@intel.com> Cc: starlingx-discuss@lists.starlingx.io Subject: Re: [Starlingx-discuss] Cores meeting minutes 8/16/18 On Thu, Aug 16, 2018 at 10:04 AM, Jones, Bruce E <bruce.e.jones@intel.com> wrote:
· Centos 7.5 upgrade status and plan [...] o Do we pull a branch for this? Only Brian (sniff) and Dean have the ability to create branches right now. Dean to ramp Scott and Saul to that list.
For the record, this is controlled by the starlingx-release group in Gerrit.
o Issues with branching (in general)
They tend to hang around and create technical debt. Can fall behind mainline development - needs to be periodically rebased to master (weekly).
If we do this on mainline all reviews are highly visible. On a branch less so.
There might be hundreds of checkins for this upgrade
People tend to ignore and not review feature branches, but the changes do need active review.
o Dean to start a thread on the mailing list to continue the discussion there. Given the above he thinks a feature branch is an easier sell.
[Much of this was written yesterday before the meeting so there is overlap with the above; the purpose in writing this down is to start shaping the guidelines we use for this in the future...] Feature branches are useful things, however they have costs and downsides and I believe the bar for creating them should be higher than things like milestone branches. I'll outline the things on my mind to consider here Some of the reasons to create a feature branch is to make it easier to to focus on a set of changes without having other things change out from under you. This can also be done directly in Gerrit using the repo manifest to control what gets pulled out of Gerrit, pulling code directly from one (or a stack of) review. Everyone can do this on their own or can coordinate with shared manifest files. There is also a social benefit in structuring batches of reviews to not make things terrible for other developers in a project. Coordinating that work requires communication (a good thing) but also timezone overlap is extremely helpful here. Working in isolation is rarely friendly to the other developers, and sometimes feature branch reviews get de-prioritized by reviews not working on them directly. This is just something the project team needs to stay aware of and try to minimize. One of the issues with a feature branch is divergence from master over time. This must be countered by periodically rebasing the feature branch on master and not just waiting until the feature branch is ready to be merged back in to master. Doing the work inline will help find merge conflicts as they happen, with the feature branch they are generally only found when doing this rebase. This also puts the burden of resolving the conflicts on the feature branch and not master. I would suggest we set a maximum time between master rebases for each feature branch created to try and balance these issues. Another significant tradeoff is with regards to testing. A feature branch requires a distinct testing effort for things not covered directly by CI/CD. This means additional hours spent by QA people. However when this effort is of a different nature this separation may be desirable, as Brent pointed out on the call this morning in the current case. In the end I am leaning strongly toward creating the feature branch for the 7.5 work due primarily to a) the testing brought up by Brent, and b) the sheer volume of expected reviews. Managing a couple hundred stacked reviews with a manifest may be doable but we just do not have that experience to do work on that scale yet. That said, I would like to see at least weekly rebases with master to keep the divergence to a sane level. Also, we should only branch in the repos where it is actually needed, not in all 50+. The list of those repos that have been branched can be extracted from the manifest file, which will have a matching feature branch similar to the milestone branches. I am sure I've left out in the above some of the things I've mention in conversations earlier this week... dt -- Dean Troyer dtroyer@gmail.com
On Thu, Aug 16, 2018 at 6:45 PM, Jones, Bruce E <bruce.e.jones@intel.com> wrote:
Let's go ahead and pull a branch for this. Dean, can you enable Saul and/or Yong to do this?
I went ahead and created a 'f/centos75' branch in stx-tools and stx-integ. I would prefer to only create branches in repos where they are needed so if we need more let me know. I needed to make some changes to the branch-stx.sh script to do this cleanly so went ahead and did it myself. I will make sure Saul and Scott know how this works and will update the wiki docs after https://review.openstack.org/593211merges. dt -- Dean Troyer dtroyer@gmail.com
participants (2)
-
Dean Troyer
-
Jones, Bruce E