Skip to content

Commit 03f1ef3

Browse files
Merge pull request #39 from MSanKeys963/add_meeting_notes
Add meeting notes for 2023-04-20 and 2023-05-04.
2 parents e63c013 + e88af3a commit 03f1ef3

File tree

2 files changed

+84
-0
lines changed

2 files changed

+84
-0
lines changed

meetings/2023-04-20.md

Lines changed: 15 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,15 @@
1+
---
2+
layout: default
3+
title: 20th April
4+
description: ZEPs Meeting Notes for 2023-04-20
5+
parent: ZEP meetings
6+
nav_order: 19
7+
---
8+
9+
# 2023-04-20
10+
11+
**Attending:** Jeremy Maitin-Shepard (JMS), Jonathan Striebel (JS), Ryan Abernathey (RA)
12+
13+
## TL;DR:
14+
15+
During the discussion on the V3 specification, the community explored different codecs, including `array → array`, `array → bytes`, and `bytes → array`, and evaluated their advantages and disadvantages. They also debated whether to include codecs in the metadata or not.

meetings/2023-05-04.md

Lines changed: 69 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,69 @@
1+
---
2+
layout: default
3+
title: 4th May
4+
description: ZEPs Meeting Notes for 2023-05-04
5+
parent: ZEP meetings
6+
nav_order: 20
7+
---
8+
9+
# 2023-05-04
10+
11+
**Attending:** Ward Fisher (WF), Josh Moore (JM), Sanket Verma (SV), Jonathan Striebel (JS), Jeremy Maitin-Shepard (JMS), Ryan Abernathey (RA)
12+
13+
## TL;DR:
14+
15+
During the meeting, SV provided an update on the current voting status for [ZEP0001](https://github.com/zarr-developers/zarr-specs/issues/227), while WF plans to vote soon with the assistance of colleagues at Unidata. RA suggested that we should be open to changes in the living document, i.e. V3 Spec and not adhere strictly to the by-laws. JS recommended having a list of contributors on the ZEP0001 page. SV also discussed pending tasks on the ZEP0001 project board before finalising the spec. JMS briefly discussed Mark’s [comments](https://github.com/zarr-developers/zarr-specs/pull/152#issuecomment-1533335795) on the sharding PR, and the meeting concluded with an impromptu discussion about organising a Zarr conference.
16+
17+
**Updates:**
18+
19+
- [ZEP0001](https://github.com/zarr-developers/zarr-specs/issues/227) review
20+
- Ends in 2 days on 5/6 @ 23:59
21+
- 2 votes so far
22+
- Constantine - `ABSTAIN`
23+
- Jeremy - `YES`
24+
- 8 votes pending - (if we leave zarr-python out then 7)
25+
26+
**Meeting Minutes:**
27+
28+
- SV: summary on votes so far (as above)
29+
- WF: Working with the colleagues @ Unidata - will be voting on the V3 Spec soon!
30+
- RA: wouldn't stick hard-and-fast to the by-laws if they need
31+
- JS: Mostly giving people a point in time for veto. It's a living document.
32+
- WF: comparing to markdown, might be good to have this process
33+
- SV: @Ward - Is there a PR you're looking to submit for ZEP1 review?
34+
- WF: User attributes for the metadata field - a bit certainity in `must_understand` flag and user defined attributes - we can have arbitary tags in user attributes specifying it doesn't require `must_understand` flag - will prepare a PR for the same
35+
- JMS: think of the review as an intent to implement
36+
- JM: agree, looking forward to using this to garner motivation
37+
- JS: looking forward to a retrospective; smaller changes.
38+
- RA: specturm of processes; OGC is the most heavy-handed; STAC is most agile (what's their trick? everything has an implementation)
39+
- JM: STAC still needs to do the major upgrade to V2 - something I'm looking forward to
40+
- `must_understand` flag
41+
- JMS: Still not clear on Dennis' objection
42+
- WF: (for Dennis) worried about future changes painting us into a corner - good to keep Dennis in loop and listen to his concerns
43+
- JS: Point where you can see both the sides - it's not a deal breaker for the V3 Spec
44+
- RA: Any downside for making `must_understand` flag a required attribute for an extension? - Seems lightweight and can satisfy Dennis
45+
- JS: To rephrase JMS's point - "You can do this but then it's not possible to have non-object entries in the config again."
46+
- JMS: We haven't clarified in codecs the presence of unknown attributes in codecs!
47+
- JS: Would be good to have a list of contributors for the ZEP1
48+
- SV: Will complete it before we finalise ZEP1
49+
- JM: Would be good to put Zarr Spec on Zenodo as well!
50+
- SV: State of the [ZEP1 project board](https://github.com/orgs/zarr-developers/projects/2/views/2)
51+
- 2 issues in meta and 1 under discussion
52+
- JS: We can ignore the one under discussion - RA can take care of the [OGC](https://github.com/zarr-developers/zarr-specs/issues/42) one
53+
- RA: We can update the community standard we already have with OGC
54+
- JS: Not super happy with how we do the Spec work atm - see [#179](https://github.com/zarr-developers/zarr-specs/issues/179) - we need to address this once V3 gets finalised
55+
- SV: What does updating V3 at OGC means? Does it supersedes V2 or V3 gets published at a new URL alongside V2?
56+
- All: Don't know! RA can take care of it.
57+
- RA: geozarr has become a comparison of geo/weather specs
58+
- but will remain a convention
59+
- JM: love to hear more. Maybe we can have a Zarr conventions convention ;)
60+
- RA: all spatial/temporal. with infinite time, would be great to work together.
61+
- JMS: Discussion on [comments](https://github.com/zarr-developers/zarr-specs/pull/152#issuecomment-1533335795) by Mark on Sharding PR
62+
- Would be a good thing to add checksum of the index not the individual chunks (data) - will add 4 extra bytes to the index - JMS favour this!
63+
- JS: Would be good to ask Norman - but I also favour the idea
64+
- Impromptu discussion on organsing a Zarr Conference
65+
- JS: Really good idea! We should have it
66+
- JMS: In-person has more values
67+
- JS: Would be good co-locate with other conferences
68+
- JM: From my experience it was difficult to get together folks from different fields - maybe we can look for hosts like Janelia, NASA etc.
69+
- JM: Thermo fisher is also looking into Zarr

0 commit comments

Comments
 (0)