W3C home > Mailing lists > Public > www-style@w3.org > March 2017

[CSSWG] Minutes Telecon 2017-03-15 [css-grid] [css-inline]

From: Dael Jackson <daelcss@gmail.com>
Date: Wed, 15 Mar 2017 20:43:45 -0400
Message-ID: <CADhPm3uqPcUvgeNxJr6fyTEf9zD1m-qnPvi1ZsVSJ02fs5b=Tg@mail.gmail.com>
To: www-style@w3.org
=========================================
  These are the official CSSWG minutes.
  Unless you're correcting the minutes,
 Please respond by starting a new thread
   with an appropriate subject line.
=========================================


Grid DoC
--------

  - Issue #1: minmax max value
(https://drafts.csswg.org/css-grid/issues-cr-2016#issue-1)
      - The group agreed that the use case was valid, but that it
          should be solved in a different way then the proposal so
          that the standard min/max priority can be maintained.
      - RESOLVED: Reject this issue for L1 of grid.
  - Issue #8: dominant-baseline should apply to grid/flex containers
      (https://drafts.csswg.org/css-grid/issues-cr-2016#issue-8)
      - RESOLVED: Accept text
  - Issue #16: Defer subgrid
(https://drafts.csswg.org/css-grid/issues-cr-2016#issue-16)
      - TabAtkins & fantasai proposed to not defer as there wasn't a
          solid counter proposal.
      - As the group discussed the proposal, it developed that there
          was a desire to get subgrid right since no implementor had
          yet implemented the partial proposal that was originally
          placed in Grid in order to encourage implementation.
      - RESOLVED: Move subgrid to level 2 of Grid
  - Issue #17: Is fr a length?
(https://drafts.csswg.org/css-grid/issues-cr-2016#issue-17)
      - RESOLVED: length & frs are not combinable, but will
                  reconsider if/when length & auto are combinable
  - RESOLVED: Republish Grid

Driving specs to REC
--------------------

  - Rossen introduced the group to the plan he and astearns
      developed to help the group move specs towards REC.
  - At the beginning of each call there will be a status check for
      all specs that are in CR or are stable WD to see what steps
      have been taken to move them to REC and give authors the
      opportunity to request assistance.
  - This new process will begin on either the 22 or 29 March calls,
      depending on progress agreeing upon the beginning list of
      specs to prioritize.

===== FULL MINUTES BELOW ======

Agenda: https://lists.w3.org/Archives/Public/www-style/2017Mar/0050.html

Present:
  Rachel Andrew
  Rossen Atanassov
  Tab Atkins
  David Baron
  Tantek Çelik
  Alex Critchfield
  Benjamin De Cock
  Elika Etemad
  Daniel Glazman
  Tony Graham
  Dael Jackson
  Brad Kemper
  Chris Lilley
  Peter Linss
  Myles Maxfield
  Anton Prowse
  Melanie Richards
  Geoffrey Sneddon
  Alan Stearns
  Greg Whitworth (IRC only)
  Steve Zilles

Regrets:
  Bert Bos
  Dave Cramer
  Simon Fraser
  Vladamir Levantovsky
  Michael Miller
  Jen Simmons

Scribe: dael

  Rossen: Let's start.
  Rossen: As usual, any extra agenda items?
  <gsnedders> I want to mention
<https://lists.w3.org/Archives/Public/www-style/2017Mar/0042.html> wrt
merging the test repos.
  gsnedders: I want to mention this ^ email.
  fantasai: I'd like to go over the flexbox status.
  fantasai: Anything we can do to get it republished soon-ish.
  Rossen: Perhaps that will be covered in agenda #5.
  Rossen: If we don't cover it then we'll put it separately.
  Rossen: Anything else I might have missed?
  Rossen: I'm only hearing gsnedders addition

Grid DoC
========

  <fantasai> https://drafts.csswg.org/css-grid/issues-cr-2016

minmax max value (Issue #1)
---------------------------

  <fantasai> https://drafts.csswg.org/css-grid/issues-cr-2016#issue-1
  <fantasai> https://lists.w3.org/Archives/Public/www-style/2016Oct/0076.html
  fantasai: First open issue is #1 which is about...we got a message
            from Ollie Williams explaining a case when you have
            conflicting min and max constraints the min wins
            generally, but this is a case where max should win.
  fantasai: We closed as no change for consistency, but his use case
            is valid and it would make more sense if it's possible
            to express this sizing constraint where the max...in
            this use case the optimal was 20% and the max was 250px
            and that wasn't working out.
  fantasai: This is a totally valid use case, it would be nice to
            have a syntax to express it. Maybe fore next grid
            release or something.
  <fantasai> grid-template-columns: 1fr repeat(4, minmax(20%,
             250px)) 1fr
  fantasai: Here's the example^
  fantasai: [explains example]
  fantasai: Perfectly reasonable. We can't solve other than nest the
            grid in a larger container.
  fantasai: Proposal is we reject the proposal, but also request
            that if the WG has a reasonable way to express this
            raise an issue so we can add this.

  Rossen: Comments?
  rachelandrew: It's not a use case that's come up from anyone else
                and I've heard lots this week. It feels like there
                will be lots of little things like this. I feel
                we're going to get an awful lot of this kind of use
                case as people get their hands on grid.
  Rossen: I would agree with rachelandrew and fantasai. Pushing this
          to a different level or in the sizing spec is the path
          forward. Having it punted from L1 grid sounds right.
  Rossen: If there are no other thoughts we can call for resolution
  Rossen: Objections to reject this issue for L1 of grid?
  fantasai: We want to solve the use case, but perhaps in a slightly
            different way.
  Rossen: We can work it out, but not in grid L1.
  fantasai: In L2 we won't invert the order of priority for min/max.
            We'd solve the use case in another way.
  Rossen: For sure. I'm just saying let's cross this bridge when we
          come to it.
  <fantasai> And I'm saying we're not crossing any bridges that
             invert the order of minmax priority

  RESOLVED: Reject this issue for L1 of grid.

dominant-baseline should apply to grid/flex containers (Issue #8)
-----------------------------------------------------------------

  <fantasai> https://drafts.csswg.org/css-grid/issues-cr-2016#issue-8
  <fantasai> https://github.com/w3c/csswg-drafts/issues/798
  fantasai: It's a CSS inline layout issue. Max was pointing out
            that the 'applies to' section doesn't say it applies to
            grid & flexbox and it should. I made the change to
            inline but want the WG to say okay.
  fantasai: Change was to CSS Inline.
  <fantasai> https://drafts.csswg.org/css-inline/#dominant-baseline-property
  fantasai: There's a dominant baseline prop. Link ^
  Rossen: Any feedback?
  Rossen: Other opinions?
  Rossen: Anyone feel we shouldn't apply dominant baseline to grid
          and flex containers?
  fantasai: Also applied alignment-baseline to flex/grid items

  RESOLVED: Accept text

  <dbaron> I find it a bit curious that baseline-shift applies to
           fewer elements than alignment-baseline and
           dominant-baseline.
  <fantasai> dbaron, that's a fair point :) I guess there's no
             reason it couldn't apply to baseline alignment in
             general...
  ACTION: fantasai extend applies to for baseline-shift to match
          alignment-baseline
  <trackbot> Created ACTION-836

Defer subgrid (Issue #16)
-------------------------

  <fantasai> https://drafts.csswg.org/css-grid/issues-cr-2016#issue-16
  <fantasai> https://github.com/w3c/csswg-drafts/issues/958
  fantasai: He's asking to drop subgrid because he wants to see if
            you can implement subgrid independently to each axis.
            TabAtkins and I said if you want something you want
            changed and that destabilizes the spec we'll drop it,
            but so far you've just said I'm not sure about the spec.
            That's our position, but we wanted to know the WGs
            thoughts.
  Rossen: So your opinion is not change the current spec and wait
          for a counter proposal that negates or improves the
          current solution?
  fantasai: Yes.

  tantek: Is anyone else impl subgrid?
  Rossen: FF is.
  tantek: Which is Mats who raised the issue.
  [issue author clarification]

  rachelandrew: I've commented on the thread. I'd love to see
                Mats...I've written my concerns about locked to axis
                and I'd love to see Mats investigation on if it's
                possible to do it more like the original. It would
                be a shame if he doesn't get to do that. I'm
                concerned about how useful the spec will be. I don't
                want him to feel the investigation would not be
                useful.
  TabAtkins: No one is holding up Mats but himself. He thinks we're
             not open to changing and we are.
  fantasai: Maybe he wants us to pull so no one else implements
            until there's investigation?
  Rossen: We certainly welcome the feedback. If Mats is under a
          different opinion I'd love to have him join a call or
          meeting to make sure he feels supported. If he has any
          impl experience and feedback with the current proposal
          we'd love to hear it. This is why we have CRs and call for
          impl feedback.
  Rossen: In the lack of concrete proposal given the work that's
          gone in already to subgrid and the feedback we have gotten
          I don't believe there's enough merit to remove it and say
          we'll have something better, trust us.
  * tantek wonders if Rossen is speaking with chair hat or MSFT hat
           now
  Rossen: Also, we've made significant efforts to make the symmetry
          of grid in respect to rows and columns and it would be
          unfortunate if we spec subgrid to favor one or the other.
  Rossen: And I was speaking as a chair. I'll say if I'm using my
          MSFT hat.
  * fantasai doesn't have any objection to whichever way we go.

  tantek: To see if I can communicate impressions from Mats, I think
          TabAtkins's characterization is true, but when there's a
          spec in CR it indicates a very specific direction and
          there's no indication in the spec text other directions
          are possible and does communicate strongly by its state.
          It's reasonable for Mats to feel that way. I think anyone
          outside the WG would have a similar impression.
  tantek: Mats as far as I can tell is the impl that's most ahead on
          this work and the subgrid is calling for impl feedback. I
          think we shouldn't just prefer...even vague implementor
          feedback trumps aspirational precision. I'm not asking to
          replace the current spec, but it's reasonable to indicate
          with spec text that there's an alternative being
          investigated.
  tantek: That's useful to show Mats his work is valuable and
          communicate to other impl that this is useful to the WG
          and welcome. And say that we are looking for alternatives
          here.
  tantek: That's my proposal, but of course we're in CR which brings
          up should we drop.
  <rachelandrew> +1 to tantek's proposal
  TabAtkins: There's no alternate proposal. It's just vaguely we
             should go back to thinking about independent axes. I
             recall when the original subgrid came up I wanted to
             push another level. It was author and dev concerns that
             made us look at a simplified version for this draft. If
             the group now feels it's more important to get it right
             and push it, that's fine. That's my original position.
  <Rossen> +1 to all of what TabAtkins said
  tantek: That's fair. There is a bit of...we are learning more
          about this conceptual space as we implement. There is new
          info, like we just heard from rachelandrew where there is
          now openness to biasing toward a correct version later.
  tantek: The specific proposal would be that we either separate it
          out or add at least an informative paragraph saying we're
          considering an alternative design that's independent on
          each axis. I agree it's vague but something that
          communicates it's happening. I think you'll see more
          specific proposals follow up.
  TabAtkins: Mats isn't just a third policy. We can tell him please
             work on this. We can point him to the minutes and
             communicate.
  tantek: That's part 1, but part 2 is to more implementers broadly.
  TabAtkins: Igalia monitors the issues list for grid.
  fantasai: Yes, Igalia & Mats follow minutes, but it's our job to
            be clear to everyone, including those that only read
            docs. If there's something important to tell
            implementors it should be in the doc.

  fantasai: Given the current state, we're shipping grid with
            everything except subgrid. Given that I don't object to
            putting that in L2 and doing that as a WD for comments.
  fantasai: I think Mats wanting to investigate is fantastic. We
            didn't do it because Igalia thought it was impossible.
            It would be great if they could talk and agree it's
            possible.
  TabAtkins: I agree which is why this needs to start in an issue
             with a proposal. I know how hard it was to think about
             originally.
  <fantasai> I don't think it was that hard to think about.
  <tantek> I'd like to hear rachelandrew's opinion on moving subgrid
           to a separate spec and spinning that up
  <tantek> at this point would anyone strongly object to moving
           subgrid to a separate spec?
  <tantek> / level
  <fantasai> I would object to moving it to moving it to a different
             module, yes :) Not to a different level.
  Rossen: As an impl or as a chair, I don't have a strong objection
          to moving subgrid out into a different spec or keeping it
          in spec with an explicit sentence that welcomes additional
          contributions. I also don't see how this is any different
          then any work in other specs. They are there to invite
          implementation and through this implementor feedback get
          specs that are more technically sounds as well as from
          user PoV.
  Rossen: If the only thing we're considering is an implementor that
          feels unheard, please invite Mats to join us so he feels
          all his ideas/objections/proposals have been heard.
  tantek: I can follow up with Mats directly.
  Rossen: In addition to the +1 to TabAtkins I also believe grid
          would have been done earlier if we didn't have spin cycles
          for subgrid.
  Rossen: Based on the implementation we had with grid when the
          initial proposal came through we know subgrid would be
          difficult. But there was no objections to pursuing that
          simple version. There hasn't been another version that
          came through.
  Rossen: Here we are discussing this again so it would be good to
          take an option so we can push forward on REC track for
          grid.

  fantasai: In terms of cycles we spent on subgrid, we spent more
            time talking about if it should be there or not instead
            of technical. Also as an editor I spent a minuscule
            amount of time on subgrid vs. the rest.
  Rossen: Agreed.

  Rossen: Do we want to keep subgrid in the grid spec or move it out
          on its own so it can signal additional and stronger
          request for feedback & changes?
  TabAtkins: I think we should only move things that are unstable
             and not ready for this level.
  * fantasai suggests a straw poll so we can move on
  <astearns> +1 to moving to the next level, for stability reasons
  <ChrisL> It sounds like it is less developed than the rest of grid.
  <ChrisL> so, push to next level
  <tantek> ChrisL - it is, less implemented by far (like none vs 3)
  <fantasai> ChrisL, I'm not sure that it's less stable, it just has
             received less attention because it hasn't been
             implemented yet
  Rossen: Okay. We have 3 implementation and none have subgrid. I
          think this speaks volumes.
  rachelandrew: I think move.
  rachelandrew: I really wanted it to be implemented and at the time
                Igalia had the revision there was hope there would
                be implementations. If we're talking changes it's
                better to move so that we say we're not expecting
                impl. And it tells authors we want more feedback. We
                can say we moved it so we can talk about what we
                need.
  <tantek> +1 rachelandrew

  Rossen: Let's try and have a resolution. Objections to moving
          subgrid to its own module?
  <astearns> next level of grid, not it's own
  fantasai: I do. I don't want another module. We can move to grid 2.
  <tantek> I'm fine with level 2
  <gsnedders> I'm +1 on what fantasai said
  <ChrisL> agree with fantasai
  rachelandrew: Yes, I meant a level 2. Not a separate subgrid weird
                thing.
  <ChrisL> +1 to grid l2
  Rossen: Okay, grid level 2. Objections to moving subgrid to level
          2 of grid?

  RESOLVED: Move subgrid to level 2 of Grid

  Rossen: And again, tantek please reach out to Mats and make sure
          he feels he's being heard and supported here.
  TabAtkins: Can we please get Mats to join the WG?
  Rossen: Is he not?
  TabAtkins: I don't think officially. He doesn't have GitHub access.
  <fantasai> We should have all the Igalia and Mozilla devs who
             participate in GitHub to have edit privileges in the
             repo
  Rossen: So tantek you can follow up on that too.
  tantek: I can ask if he wants to officially join. I'll do my best
          to facilitate the communication. I can't force him to join.

Is fr a length? (Issue #17)
---------------------------

  fantasai: I'm skipping issue #15. I have #17- a question about if
            fr are a length.
  <fantasai> https://github.com/w3c/csswg-drafts/issues/955
  fantasai: We said no, but it raised if they should be combinable
            in calc.
  fantasai: I wanted to get a resolution and see if there's interest
            in adding that
  fantasai: to a future level.
  TabAtkins: fr isn't a length: it's length adjacent but you can't
             combine it with lengths.
  Rossen: I would further that that I always thought of fr like auto
          for purposes of distributing space. For that reason we
          don't consider auto as combinable.
  fantasai: Yet. It's been requested.
  TabAtkins: And when we deal with that we can reconsider. As of now
             I think we should just resolve.
  fantasai: fr are not and will not be combinable with length and
            percentage values. Reconsider when auto values are
            combinable.
  <fantasai> proposed resolution: length & frs are not combinable,
             but will reconsider if/when length & auto are combinable
  Rossen: Sounds good.
  Rossen: Objections?

  RESOLVED: length & frs are not combinable, but will reconsider if/
            when length & auto are combinable

Republish
---------

  fantasai: Closing today's issues, we have one open which is 15 and
            we should just do an update officially.
  Rossen: I'm in favor.
  Rossen: Objections?

  RESOLVED: Republish Grid

  ChrisL: Updated CR?
  fantasai: Yes.

  <tantek> are we going to note imminent separation of moving of
           subgrid to level 2?
  <tantek> in this new Grid CR?
  <tantek> can we at least make a note of that happening soon since
           we have a resolution?

  <fantasai> https://github.com/w3c/csswg-drafts/issues/523#issuecomment-282771617
  fantasai: And Rego wanted to confirm the behavior we got for the
            replaced elements in grid is actually what we want.
            Anyone with an opinion please look at his comments (link
            above). If you think it's wrong, post an issue.
            Otherwise we'll assume it's closed. fremy if you could
            look it would be appreciated.

  tantek: Quick question on grid CR. Can we include a note about the
          move?
  ChrisL: I assumed the republish would include the removal.
  tantek: Great. That's awesome too. Thanks.

Driving specs to REC
====================

  <tantek> driving specs to REC ++
  Rossen: I've had multiple discussions with people from W3M, AC
          members, etc. They always ask me why are we not publishing
          more REC.
  <fantasai> because we need more people like gsnedders
  <fantasai> companies send product managers here, but not
             super-awesome QA personnel
  Rossen: That started a little investigative process on how to move
          things forward. Are there things to expedite this.
  Rossen: We've had discussions with astearns and here's our
          proposal:
  Rossen: If we look through all the agendas that we've had this
          year alone we had discussions around almost everything
          being worked on [lists ever spec discussed this year]
  Rossen: Usually when we have time for discussion we're good at
          filling our call time. However, not every topic helps us
          move to REC. They don't come on spec work alone. We need
          tests.
  Rossen: Looking through the current specs, the ones that seem
          closest to driving to REC are...Writing Modes is the
          closest and we're waiting on final test reports.
  Rossen: Text level 3, fonts 3, cascade 3, transforms L1, flexbox,
          variables.
  Rossen: As a P2 we have grid as the first. The rest are open to
          discussion.
  Rossen: So how do we move forward? This is stating the obvious, I
          think.
  Rossen: So how do we make progress?
  <tantek> YES
  <tantek> this is kinda what I was trying to do at the Lisbon f2f
  <tantek> with what specs are going to CR by end of the year
  <tantek> etc.
  <tantek> Rossen++

  Rossen: Our proposal is to dedicate all those specs as the first
          item for every call until they become RESs. We've
          discussed this in the past and usually the first
          objections was "if there's nothing to discuss why have
          them on the agenda" and it's because we're either done or
          stuck on something. If we're stuck we need to figure out
          how to get unstuck.
  Rossen: If there's nothing to do besides tests, let's get tests
          written. Perhaps we'll ask why there are no tests written
          or none reviewed.
  Rossen: So spending 15 minutes out of every call talking about
          people not doing what they were supposed to can suck, but
          it can be really productive. This is how we got SVG from
          something chaotic to something organizes and in CR.
  <dbaron> spending the first 15 minutes of every phone call asking
           people why they haven't done any work really sucks
  <dbaron> last time we did that I stopped attending the calls
  <fantasai> dbaron, +1
  <tantek> dbaron, true, hopefully we can minimize it to 5 min ;)
  <tantek> hopefully we can reframe it as "Is there anything we can
           help with on this spec?"
  <ChrisL> it also sets up an expectation, so people tend to
           prioritize getting stuff done ahead of the call
  <ChrisL> tantek++
  <fantasai> tantek, every call? the same answer almost every call
  <tantek> I am not a fan of shaming or berating people about
           "asking people why they haven't done any work"
  <tantek> in fact I am specifically against any such shaming or
           berating. totally unproductive and demotivating
  <tantek> fantasai, I think it's legitimate to ask "how can we
           help?" and also ok for editor(s) to say "no idea or you
           can't", until they think of something that does.
  <tantek> just asking the question, and respecting the editor(s)
           answers would be a good start
  Rossen: The same objections and comments were made with SVG. We
          ask these questions because we want to ship the spec.
          Those of you that ship on a regular cadence know how to do
          it. This mandated progress is a way to do it.
  Rossen: This is our current proposal from astearns and I.

  fantasai: First, on your list of specs, I think conditional rules,
            cascade and V&U should be on there.
  Rossen: Cascade was there.
  fantasai: Conditional rules, V&U, Backgrounds.
  fantasai: Text 3 isn't even in CR. I'm in favor of working on
            them, but there's things in addition to testing.
  fantasai: Second comment is until there are people doing testing
            as a significant part of their to do we won't make
            significant progress. Most of this work is not telecon
            work. It needs people that care about gathering tests.
  <gsnedders> (I was basically going to say what fantasai did)
  fantasai: Until we have people that have the time to do that we'll
            just talk status which is not useful. That's the problem
            we need to solve. We need QA people. It doesn't have to
            be actual QA people, but people who can QA. It can also
            be QA people. But if it's people doing this in their
            spare time we won't make progress.
  Rossen: In reply, once we see the testing work for a spec has
          taken off we can deallocate this spec out of conference
          call. Until then we need to support this work.

  ChrisL: I did publish for css 3 fonts there areas missing tests. A
          good 2/3 could be tested from myles' font, but it's mac OS
          only font. I can't make tests. That's what I'm stuck on.
          If I can get unstuck I can commit to tests. I'm asking for
          help.
  <gsnedders> ChrisL: I can potentially take a quick look, FWIW
  Rossen: Send me an e-mail and I'll connect you with out fonts guys.
  <tantek> ^^^ great example of the need help? ask for help. pattern

  myles: A couple thoughts.
  myles: I want to echo fantasai that the work remaining doesn't
         need to be on the call.
  myles: Second is I'm still fairly new as an editor so...I would
         love to take my specs to REC, but I need an mentor. I'm
         happy to work with ChrisL or anyone else.
  * ChrisL thinks Myles is doing a fantastic job editing fonts 4,
           actually
  myles: Point 3, ChrisL the font I'm confident I can make it work,
         I just need time. Which is kind of like point 1. The people
         doing this in their spare time, it's a matter of time and
         priorities.
  Rossen: I totally agree. Time is the only currency we have to
          spend and if we're constantly on credit we have problems.
          I want to force those conversations so people can ask for
          help. Given that we've made you the editor and you need
          mentoring, this is the time for you to ask. If we don't
          force those conversations we'll be stuck where there are
          all kinds of things to do and the progress gets slower.

  <fantasai> We should *absolutely* make sure that people feel
             welcome to bring up any issues that need WG discussion
             or help from other people. Just don't think that
             dedicating time every call to testing work is useful if
             none of that work is being done and there is therefore
             nothing to discuss. :)
  <tantek> fantasai, beyond "feel welcome", I think it's important
           to signal that the group prioritizes that
  <fantasai> tantek, sure
  <fantasai> tantek, don't mind to have a standing agenda item
             that's "Does anyone working on testing have anything to
             discuss"

  tantek: In response to fantasai, Rossen if we prioritize the CRs
          and then the mature WD as separate clusters I think that
          would help.
  Rossen: Definitely. The order we came up with was initial review
          of specs that seem close and stable enough in terms of not
          too much in terms of changes and mostly impl in browsers.
          We welcome feedback similar to fantasai's. We missed some.
          We can continue to refine the list on the private ML and
          continue to go forward.
  Rossen: If we don't start next call, perhaps, we should start the
          following. If we don't solidify the set of specs for next
          week, that is.
  <tantek> also we should encourage editors of CRs that need help to
           prioritize their requests / issues
  <tantek> over new WDs etc.
  Rossen: We're on the top of the hour. This is something that will
          take getting used to, but in the long run I'm hopeful and
          I think we'll get good results and send good signals to
          the rest of the community.

  fantasai: I just want to repeat that if you want to get to rec we
            need to get QA people in here, not just devs that also
            write specs.
  Rossen: Yes. That's noted. We'll see what can be done. As a group
          we have to be able to get our specs to REC.
  <tantek> fantasai, agreed, and we can also note that more broadly,
           e.g. to AC/AB that we are looking for more QA help.

  gsnedders: I just want to mention that the merge with
             web-platform-tests will happen in under a fortnight.
  <gsnedders> https://lists.w3.org/Archives/Public/www-style/2017Mar/0042.html
              is the email I mentioned about that.
  Rossen: Thanks everyone. We'll chat next week.
Received on Thursday, 16 March 2017 00:44:50 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 16 March 2017 00:44:50 UTC