Despite the meeting being canceled, some people showed
              up anyway and we have some useful conversations.  Don't
              consider these minutes, they're just my recollections of
              what was talked about, and these are certainly not
              official minutes.  Corrections are encouraged.
              
              Emily Jiang started by asking about the TCKs and lamenting
              how there wsa no documentation about the structure of the
              TCKs and thus it was difficult to determine how to extract
              pieces of the TCk repo for one particular API in order to
              create a standalone TCK for that API.
              
              I lamented that we had internal documentation on some of
              this that we've never found time to release.  Perhaps some
              of it would be useful, perhaps not, but I'll go back and
              see if there's any hope of springing it loose of Oracle.
              
              I reminded Emily to talk to Andy, who has figured out some
              parts of this.
              
              We talked to David Blevins about EJB and what his plans
              are for EJB.  David was very clear that, given his
              resource and product requirements, he was not going to be
              able to have anyone help on the EJB implementation in
              GlassFish.  So, it's going to be up to the GlassFish
              project team to do this work.
              
              We talked about the EJB interop tests.  David believes
              there are two kinds of EJB interoperability tests - tests
              that use only the EJB APIs to test interoperating with
              remote EJBs, presumably from the same vendor, and tests
              that use the CORBA APIs to test EJB interoperability using
              the IIOP. CSIv2, etc. protocols.  These later tests should
              be removed from the TCK.
              
              Note, however, that the only remote EJB protocol supported
              by GlassFish is the CORBA protocol, so these tests that
              would be removed from the platform TCK would be very
              useful as product tests for GlassFIsh, and we should be
              careful not to lose them or lose that ability to use them
              for GlassFish.  They would also be useful for any other
              products that currently provide this level of
              interoperability and are NOT planning to remove it for
              Jakarta EE 9 even though it is no longer part of the spec
              (not even optional).
              
              Vano Beridze lamented that the Jakarta EE RI, Eclipse
              GlassFish, was clearly not a production level enterprise
              server, so was some other product going to stop in to fill
              that gap.  We explained how there is no longer any RI, how
              it's a market competition to determine who is best.  We
              reminded Vano that Payara Server is very close to
              GlassFish, so contributing to GlassFish may see results in
              Payara server soon, and for that matter many of the
              components are shared with other products so it depends on
              what component you're contributing to.
              
              Vano was interested in contributing to the Face products. 
              We gave hime must of the same "how do I help" advice that
              has been given on mailing lists several times.  Maybe
              someone (Reza?) could write up a Quick Start page for "how
              do I get started helping?"
              
              
              We filled the whole hour with these discussions, and
              could've gone on longer.  A few other people joined and
              left the call and I didn't try to keep track of them,
              sorry.
              
              
              Now I have some advice of my own (not discussed during the
              meeting)...
              
              If you really want to cancel the meeting, for whatever
              reason, it needs to be done at least 12, and preferably 24
              hours before the meeting is scheduled to start.
            
          
          
          
          I think we agreed that I would help out by sending a
            reminder a day before the call with a link to the agenda. It
            is everybody's responsibility to add to the agenda. And an
            empty agenda means we won't do the call. 
           
          
             
              Sometimes it's worthwhile to have a meeting even if there
              is no official agenda.  Consider it an "unmeeting" where
              the agenda is formed at the start of the meeting or during
              the flow of the meeting.  If it turns out to be a failure,
              we can stop doing it.
            
          
          
          
          I agree! it is a good idea. I am happy to do so for
            future meetings.
           
          
             
              If the meeting end early, consider leaving the zoom
              running and displaying a banner that says the meeting
              ended early.  If there's confusion about the start time
              and the meeting starts later than expected for some
              people, consider starting the zoom conference early and
              display a banner that the meeting starts later, e.g., due
              to DST changes.
            
          
          
          
          The meeting is set up so it does not require a host.
            Anybody can log in to the meeting at any time. I won't be
            able to attend the meeting every time due to travel (not
            currently, but usually...). So facilitating this would be up
            to someone in the group.
          
          
          Ivar