18:06:21 <CaseyODL> #startmeeting tws
18:06:21 <odl_meetbot> Meeting started Mon Dec 11 18:06:21 2017 UTC.  The chair is CaseyODL. Information about MeetBot at http://ci.openstack.org/meetbot.html.
18:06:21 <odl_meetbot> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
18:06:21 <odl_meetbot> The meeting name has been set to 'tws'
18:06:40 <abhijitkumbhare> vishnoianil is joining in 5 min
18:07:16 <CaseyODL> #topic Groups.io
18:07:16 <abhijitkumbhare> #topic Groups.io migration
18:07:19 <bjohnson> #info Brady Johnson
18:08:08 <lori> CaseyODL: do we need to be chair to info in things?
18:09:20 <lori> #info Groups.io has many of the features of Mailman, but a modern interface, better security and extra features
18:10:06 <lori> #info extra features include muting threads, integrations with many popular services
18:11:48 <lori> #info Groups.io was tested with ODPi, tested with email in China, with Exchange and Apple clients, with email from different geographical regions
18:12:30 <lori> #info it would be interesting to have less mailing lists, using the features of Groups.io
18:12:52 <lori> #info one such list would be a general support mailing list
18:13:39 <lori> #info vorburger suggests to have two support lists: one user support and one dev support list
18:14:42 <lori> #info CaseyODL ask how do we direct unexperienced users to the right list
18:15:37 <lori> #info CaseyODL also suggests to obsolete project specific mailing lists in favor of topics/hashtags on a general list
18:16:33 <lori> #info dfarrell07 says that in OPNFV they use tagging in the subject line, and that has issues, people don't get it right, and they're not too happy with that
18:17:08 <lori> #info vishnoianil says that it is easy to have typos, which makes this error prone
18:18:18 <lori> #info bjohnson asks who benefits by switching to one list
18:18:41 <lori> #info CaseyODL says that it would help users who don't know which lists to ask
18:19:08 <lori> #info there is still a feeling that complexity is not going to be reduced by this move
18:19:43 <lori> #info the Groups.io interface allows easy searching through all groups
18:20:35 <lori> #info CaseyODL suggests to use tags, but have groups based on category (kernel, support, protocol, etc.)
18:21:59 <lori> #info vorburger and vishnoianil say they don't want to receive email for all app projects for example, and have to setup filtering
18:22:26 <lori> #info filtering can be set up in the group config too, not just in the email client (like mailman topics)
18:23:45 <lori> #info one option to make it possible to use the old email aliases is to set up forwarding rules for the old lists
18:24:10 <abhijitkumbhare> Back in a minute
18:24:45 <lori> #action CaseyODL to check if the above is possible (forwarding an email alias to a hashtag in a new group)
18:30:25 <lori> #info it seems like the same people usualy subscribe to the project specific lists of a cluster of projects, which are not the same as the kernel, apps, and other categories
18:32:42 <lori> #action CaseyODL will look into options for mailing list consolidation
18:33:06 <zxiiro> An opinion I've always had is to have 1 general dev mailing list where all the projects go in by default and then projects that grow and become too chatty can create their own separate list.
18:33:41 <zxiiro> For example projects that have like 1 email a quarter don't really benefit from having a separate mailing list.
18:35:02 <CaseyODL> #topic Release streamlining
18:35:02 <lori> #action CaseyODL to send out email to the community to continue the discussion about the email list consolidation
18:36:40 <lori> #info the current release process has several issues slowing things down
18:36:52 <lori> #info people ignoring CSIT requirements
18:37:29 <lori> #info release engineering (RE) is unable to unblock the release due to unresponsive projects
18:38:02 <lori> #info the all-in-one distribution is forcing arbitrary linking of unrelated projects
18:38:25 <lori> #info unresposinsive projects are more-or-less freeloaders for maintenance
18:39:00 <lori> #info one solution is focus on core projects, which have to be there for ODL to actually work
18:39:24 <lori> #info and then on active/responsive projects, which are consumed a lot downstream
18:39:38 <lori> #info make sure these projects are stable
18:39:47 <jamoluhrsen> anipbu, joining tws?
18:40:14 <lori> #info make sure core projects have a healthy committer team and it's easy to onboard committers
18:41:20 <lori> #info RE has a bit more control now to make things go faster by merging e.g. version bumping related patches and so on
18:41:45 <lori> #info we need to define requirements for projects to be "admitted" into this list of "core" projects
18:42:20 <lori> #info e.g., dependencies of core projects need to be in the core
18:49:28 <lori> #info the proposal is to have three buckets: 1. core projects which need to work all the time; 2. projects meeting the requirements for distribution, like passing jenkins jobs; which are part of the Karaf distro ZIP file; and 3. unresposnsive projects not included in the ZIP file, but which can still be loaded manually from the Karaf console
19:06:56 <jamoluhrsen> #link https://docs.google.com/presentation/d/1wAG_zQ0IkFdh9kZgjKtMbTP-x7jJOvnOgFO5iehebpE/edit#slide=id.g2bfeb64f3c_0_7 <-- new distro model slide deck
19:08:05 <lori> #info the plan is to have this hashed out in Oxygen timeframe so it can be applied to the Fluorine release
19:09:26 <lori> #endmeeting