You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@arrow.apache.org by Antoine Pitrou <an...@python.org> on 2022/08/24 15:24:19 UTC
[VOTE] Format: Rules and procedures for Canonical extension types
Hello,
I would like to propose we vote for the following set of rules for
registering well-known ("canonical") extension types.
* Canonical extension types are described and maintained in a separate
document under the format specifications directory:
https://github.com/apache/arrow/tree/master/docs/source/format (note
this gets turned into HTML docs by Sphinx =>
https://arrow.apache.org/docs/index.html)
* Each canonical extension type requires a separate discussion and vote
on the mailing-list
* The specification text to be added *must* follow these requirements
1) It *must* have a well-defined name starting with "org.apache.arrow."
2) Its parameters, if any, *must* be described in the proposal
3) Its serialization *must* be described in the proposal and should
not require unduly work or unusual software dependencies (for example, a
trivial custom text format or JSON would be acceptable)
4) Its expected semantics *should* be described as well and any
potential ambiguities or pain points addressed or at least mentioned
* The extension type *should* have one implementation submitted;
preferably two if non-trivial (for example if parameterized)
The vote will be open for at least 72 hours.
[ ] +1 Accept this proposal
[ ] +0
[ ] -1 Do not accept this proposal because...
Regards
Antoine.
Re: [RESULT][VOTE] Format: Rules and procedures for Canonical extension types
Posted by Antoine Pitrou <an...@python.org>.
The PR was submitted and merged here:
https://github.com/apache/arrow/pull/14167
We can now start discussing specific canonical types!
Regards
Antoine.
Le 30/08/2022 à 18:06, Antoine Pitrou a écrit :
>
> Hello,
>
> With 3 binding +1 votes, 3 non-binding +1 votes, and no -1 vote, the
> vote has passed.
>
> Also, vote discussion has shown that the first rule should be updated to
> mandate the name starts with "arrow." instead of "org.apache.arrow.".
>
> The next step will be to prepare a PR adding these rules to the specs
> chapter of the project documentation.
>
> Regards
>
> Antoine.
>
>
> Le 24/08/2022 à 17:24, Antoine Pitrou a écrit :
>>
>> Hello,
>>
>> I would like to propose we vote for the following set of rules for
>> registering well-known ("canonical") extension types.
>>
>>
>> * Canonical extension types are described and maintained in a separate
>> document under the format specifications directory:
>> https://github.com/apache/arrow/tree/master/docs/source/format (note
>> this gets turned into HTML docs by Sphinx =>
>> https://arrow.apache.org/docs/index.html)
>>
>> * Each canonical extension type requires a separate discussion and vote
>> on the mailing-list
>>
>> * The specification text to be added *must* follow these requirements
>>
>> 1) It *must* have a well-defined name starting with "org.apache.arrow."
>> 2) Its parameters, if any, *must* be described in the proposal
>> 3) Its serialization *must* be described in the proposal and should
>> not require unduly work or unusual software dependencies (for example, a
>> trivial custom text format or JSON would be acceptable)
>> 4) Its expected semantics *should* be described as well and any
>> potential ambiguities or pain points addressed or at least mentioned
>>
>> * The extension type *should* have one implementation submitted;
>> preferably two if non-trivial (for example if parameterized)
>>
>>
>> The vote will be open for at least 72 hours.
>>
>> [ ] +1 Accept this proposal
>> [ ] +0
>> [ ] -1 Do not accept this proposal because...
>>
>>
>> Regards
>>
>> Antoine.
[RESULT][VOTE] Format: Rules and procedures for Canonical extension types
Posted by Antoine Pitrou <an...@python.org>.
Hello,
With 3 binding +1 votes, 3 non-binding +1 votes, and no -1 vote, the
vote has passed.
Also, vote discussion has shown that the first rule should be updated to
mandate the name starts with "arrow." instead of "org.apache.arrow.".
The next step will be to prepare a PR adding these rules to the specs
chapter of the project documentation.
Regards
Antoine.
Le 24/08/2022 à 17:24, Antoine Pitrou a écrit :
>
> Hello,
>
> I would like to propose we vote for the following set of rules for
> registering well-known ("canonical") extension types.
>
>
> * Canonical extension types are described and maintained in a separate
> document under the format specifications directory:
> https://github.com/apache/arrow/tree/master/docs/source/format (note
> this gets turned into HTML docs by Sphinx =>
> https://arrow.apache.org/docs/index.html)
>
> * Each canonical extension type requires a separate discussion and vote
> on the mailing-list
>
> * The specification text to be added *must* follow these requirements
>
> 1) It *must* have a well-defined name starting with "org.apache.arrow."
> 2) Its parameters, if any, *must* be described in the proposal
> 3) Its serialization *must* be described in the proposal and should
> not require unduly work or unusual software dependencies (for example, a
> trivial custom text format or JSON would be acceptable)
> 4) Its expected semantics *should* be described as well and any
> potential ambiguities or pain points addressed or at least mentioned
>
> * The extension type *should* have one implementation submitted;
> preferably two if non-trivial (for example if parameterized)
>
>
> The vote will be open for at least 72 hours.
>
> [ ] +1 Accept this proposal
> [ ] +0
> [ ] -1 Do not accept this proposal because...
>
>
> Regards
>
> Antoine.
Re: [VOTE] Format: Rules and procedures for Canonical extension types
Posted by Rok Mihevc <ro...@gmail.com>.
+1 (non-binding) and preference for the "arrow." namespace.
Rok
Re: [VOTE] Format: Rules and procedures for Canonical extension types
Posted by Sutou Kouhei <ko...@clear-code.com>.
+1 with "arrow." prefix because we already use "ARROW:" not
"ORG.APACHE.ARROW:" for reserved metadata name prefix.
https://arrow.apache.org/docs/format/Columnar.html#custom-application-metadata
> The ARROW pattern is a reserved namespace for internal
> Arrow use in the custom_metadata fields. For example,
> ARROW:extension:name.
Thanks,
--
kou
In <33...@python.org>
"[VOTE] Format: Rules and procedures for Canonical extension types" on Wed, 24 Aug 2022 17:24:19 +0200,
Antoine Pitrou <an...@python.org> wrote:
>
> Hello,
>
> I would like to propose we vote for the following set of rules for
> registering well-known ("canonical") extension types.
>
>
> * Canonical extension types are described and maintained in a separate
> * document under the format specifications directory:
> https://github.com/apache/arrow/tree/master/docs/source/format (note
> this gets turned into HTML docs by Sphinx =>
> https://arrow.apache.org/docs/index.html)
>
> * Each canonical extension type requires a separate discussion and vote
> * on the mailing-list
>
> * The specification text to be added *must* follow these requirements
>
> 1) It *must* have a well-defined name starting with
> "org.apache.arrow."
> 2) Its parameters, if any, *must* be described in the proposal
> 3) Its serialization *must* be described in the proposal and should
> not require unduly work or unusual software dependencies (for example,
> a trivial custom text format or JSON would be acceptable)
> 4) Its expected semantics *should* be described as well and any
> potential ambiguities or pain points addressed or at least mentioned
>
> * The extension type *should* have one implementation submitted;
> * preferably two if non-trivial (for example if parameterized)
>
>
> The vote will be open for at least 72 hours.
>
> [ ] +1 Accept this proposal
> [ ] +0
> [ ] -1 Do not accept this proposal because...
>
>
> Regards
>
> Antoine.
Re: [VOTE] Format: Rules and procedures for Canonical extension types
Posted by Jorge Cardoso Leitão <jo...@gmail.com>.
+1
Really well written, thanks for driving this!
On Mon, 29 Aug 2022, 11:16 Antoine Pitrou, <an...@python.org> wrote:
>
> Hello,
>
> Just a heads up that more PMC votes are needed here.
>
>
>
> Le 24/08/2022 à 17:24, Antoine Pitrou a écrit :
> >
> > Hello,
> >
> > I would like to propose we vote for the following set of rules for
> > registering well-known ("canonical") extension types.
> >
> >
> > * Canonical extension types are described and maintained in a separate
> > document under the format specifications directory:
> > https://github.com/apache/arrow/tree/master/docs/source/format (note
> > this gets turned into HTML docs by Sphinx =>
> > https://arrow.apache.org/docs/index.html)
> >
> > * Each canonical extension type requires a separate discussion and vote
> > on the mailing-list
> >
> > * The specification text to be added *must* follow these requirements
> >
> > 1) It *must* have a well-defined name starting with
> "org.apache.arrow."
> > 2) Its parameters, if any, *must* be described in the proposal
> > 3) Its serialization *must* be described in the proposal and should
> > not require unduly work or unusual software dependencies (for example, a
> > trivial custom text format or JSON would be acceptable)
> > 4) Its expected semantics *should* be described as well and any
> > potential ambiguities or pain points addressed or at least mentioned
> >
> > * The extension type *should* have one implementation submitted;
> > preferably two if non-trivial (for example if parameterized)
> >
> >
> > The vote will be open for at least 72 hours.
> >
> > [ ] +1 Accept this proposal
> > [ ] +0
> > [ ] -1 Do not accept this proposal because...
> >
> >
> > Regards
> >
> > Antoine.
>
Re: [VOTE] Format: Rules and procedures for Canonical extension types
Posted by Antoine Pitrou <an...@python.org>.
Hello,
Just a heads up that more PMC votes are needed here.
Le 24/08/2022 à 17:24, Antoine Pitrou a écrit :
>
> Hello,
>
> I would like to propose we vote for the following set of rules for
> registering well-known ("canonical") extension types.
>
>
> * Canonical extension types are described and maintained in a separate
> document under the format specifications directory:
> https://github.com/apache/arrow/tree/master/docs/source/format (note
> this gets turned into HTML docs by Sphinx =>
> https://arrow.apache.org/docs/index.html)
>
> * Each canonical extension type requires a separate discussion and vote
> on the mailing-list
>
> * The specification text to be added *must* follow these requirements
>
> 1) It *must* have a well-defined name starting with "org.apache.arrow."
> 2) Its parameters, if any, *must* be described in the proposal
> 3) Its serialization *must* be described in the proposal and should
> not require unduly work or unusual software dependencies (for example, a
> trivial custom text format or JSON would be acceptable)
> 4) Its expected semantics *should* be described as well and any
> potential ambiguities or pain points addressed or at least mentioned
>
> * The extension type *should* have one implementation submitted;
> preferably two if non-trivial (for example if parameterized)
>
>
> The vote will be open for at least 72 hours.
>
> [ ] +1 Accept this proposal
> [ ] +0
> [ ] -1 Do not accept this proposal because...
>
>
> Regards
>
> Antoine.
Re: [VOTE] Format: Rules and procedures for Canonical extension types
Posted by Antoine Pitrou <an...@python.org>.
Le 25/08/2022 à 02:08, Weston Pace a écrit :
> +1 (non-binding). This is maybe implied but I would add that
> modification of extension types must also require a vote and should be
> backwards compatible. Furthermore, extension types (particularly
> those with extensive parameterization/serialization should discuss how
> future additions would be made. For example, if serialized via JSON
> than readers should tolerate (and ignore) unexpected keys.
That's a good point, and I agree those additions would make sense.
As for "arrow" vs. "org.apache.arrow", that's fine with me. I'm not sure
a new vote needs to be re-cast with that sole modification.
Regards
Antoine.
>
> On Wed, Aug 24, 2022 at 10:56 AM Neal Richardson
> <ne...@gmail.com> wrote:
>>
>> I agree with Micah. Moreover, adding "org.apache" does not disambiguate
>> anything; "arrow" should be the reserved namespace for canonical
>> (extension) types.
>>
>> Neal
>>
>> On Wed, Aug 24, 2022 at 12:31 PM Micah Kornfield <em...@gmail.com>
>> wrote:
>>
>>> Sorry for beling late. I'm -0.5 on "org.apache.arrow." given people
>>> previously raising naming concerns about having "apache" and "arrow"
>>> coupled together. I think just "arrow" makes sense here.
>>>
>>> I also am not sure about relaxing the 2 language requirement for simple
>>> implementations, but feel less strongly about this.
>>>
>>> On Wed, Aug 24, 2022 at 9:25 AM Pradeep Gollakota
>>> <pg...@google.com.invalid> wrote:
>>>
>>>> +1 (non-binding) With a slight preference for well defined names starting
>>>> with "arrow." instead of "org.apache.arrow."
>>>>
>>>> On Wed, Aug 24, 2022 at 12:16 PM David Li <li...@apache.org> wrote:
>>>>
>>>>> +1 (binding)
>>>>>
>>>>> Just to check, these rules will presumably be committed into the
>>>>> documentation as well?
>>>>>
>>>>> On Wed, Aug 24, 2022, at 11:24, Antoine Pitrou wrote:
>>>>>> Hello,
>>>>>>
>>>>>> I would like to propose we vote for the following set of rules for
>>>>>> registering well-known ("canonical") extension types.
>>>>>>
>>>>>>
>>>>>> * Canonical extension types are described and maintained in a
>>> separate
>>>>>> document under the format specifications directory:
>>>>>> https://github.com/apache/arrow/tree/master/docs/source/format (note
>>>>>> this gets turned into HTML docs by Sphinx =>
>>>>>> https://arrow.apache.org/docs/index.html)
>>>>>>
>>>>>> * Each canonical extension type requires a separate discussion and
>>> vote
>>>>>> on the mailing-list
>>>>>>
>>>>>> * The specification text to be added *must* follow these requirements
>>>>>>
>>>>>> 1) It *must* have a well-defined name starting with
>>>>> "org.apache.arrow."
>>>>>> 2) Its parameters, if any, *must* be described in the proposal
>>>>>> 3) Its serialization *must* be described in the proposal and
>>> should
>>>>>> not require unduly work or unusual software dependencies (for
>>> example,
>>>> a
>>>>>> trivial custom text format or JSON would be acceptable)
>>>>>> 4) Its expected semantics *should* be described as well and any
>>>>>> potential ambiguities or pain points addressed or at least mentioned
>>>>>>
>>>>>> * The extension type *should* have one implementation submitted;
>>>>>> preferably two if non-trivial (for example if parameterized)
>>>>>>
>>>>>>
>>>>>> The vote will be open for at least 72 hours.
>>>>>>
>>>>>> [ ] +1 Accept this proposal
>>>>>> [ ] +0
>>>>>> [ ] -1 Do not accept this proposal because...
>>>>>>
>>>>>>
>>>>>> Regards
>>>>>>
>>>>>> Antoine.
>>>>>
>>>>
>>>>
>>>> --
>>>> Pradeep
>>>>
>>>
Re: [VOTE] Format: Rules and procedures for Canonical extension types
Posted by Weston Pace <we...@gmail.com>.
+1 (non-binding). This is maybe implied but I would add that
modification of extension types must also require a vote and should be
backwards compatible. Furthermore, extension types (particularly
those with extensive parameterization/serialization should discuss how
future additions would be made. For example, if serialized via JSON
than readers should tolerate (and ignore) unexpected keys.
On Wed, Aug 24, 2022 at 10:56 AM Neal Richardson
<ne...@gmail.com> wrote:
>
> I agree with Micah. Moreover, adding "org.apache" does not disambiguate
> anything; "arrow" should be the reserved namespace for canonical
> (extension) types.
>
> Neal
>
> On Wed, Aug 24, 2022 at 12:31 PM Micah Kornfield <em...@gmail.com>
> wrote:
>
> > Sorry for beling late. I'm -0.5 on "org.apache.arrow." given people
> > previously raising naming concerns about having "apache" and "arrow"
> > coupled together. I think just "arrow" makes sense here.
> >
> > I also am not sure about relaxing the 2 language requirement for simple
> > implementations, but feel less strongly about this.
> >
> > On Wed, Aug 24, 2022 at 9:25 AM Pradeep Gollakota
> > <pg...@google.com.invalid> wrote:
> >
> > > +1 (non-binding) With a slight preference for well defined names starting
> > > with "arrow." instead of "org.apache.arrow."
> > >
> > > On Wed, Aug 24, 2022 at 12:16 PM David Li <li...@apache.org> wrote:
> > >
> > > > +1 (binding)
> > > >
> > > > Just to check, these rules will presumably be committed into the
> > > > documentation as well?
> > > >
> > > > On Wed, Aug 24, 2022, at 11:24, Antoine Pitrou wrote:
> > > > > Hello,
> > > > >
> > > > > I would like to propose we vote for the following set of rules for
> > > > > registering well-known ("canonical") extension types.
> > > > >
> > > > >
> > > > > * Canonical extension types are described and maintained in a
> > separate
> > > > > document under the format specifications directory:
> > > > > https://github.com/apache/arrow/tree/master/docs/source/format (note
> > > > > this gets turned into HTML docs by Sphinx =>
> > > > > https://arrow.apache.org/docs/index.html)
> > > > >
> > > > > * Each canonical extension type requires a separate discussion and
> > vote
> > > > > on the mailing-list
> > > > >
> > > > > * The specification text to be added *must* follow these requirements
> > > > >
> > > > > 1) It *must* have a well-defined name starting with
> > > > "org.apache.arrow."
> > > > > 2) Its parameters, if any, *must* be described in the proposal
> > > > > 3) Its serialization *must* be described in the proposal and
> > should
> > > > > not require unduly work or unusual software dependencies (for
> > example,
> > > a
> > > > > trivial custom text format or JSON would be acceptable)
> > > > > 4) Its expected semantics *should* be described as well and any
> > > > > potential ambiguities or pain points addressed or at least mentioned
> > > > >
> > > > > * The extension type *should* have one implementation submitted;
> > > > > preferably two if non-trivial (for example if parameterized)
> > > > >
> > > > >
> > > > > The vote will be open for at least 72 hours.
> > > > >
> > > > > [ ] +1 Accept this proposal
> > > > > [ ] +0
> > > > > [ ] -1 Do not accept this proposal because...
> > > > >
> > > > >
> > > > > Regards
> > > > >
> > > > > Antoine.
> > > >
> > >
> > >
> > > --
> > > Pradeep
> > >
> >
Re: [VOTE] Format: Rules and procedures for Canonical extension types
Posted by Neal Richardson <ne...@gmail.com>.
I agree with Micah. Moreover, adding "org.apache" does not disambiguate
anything; "arrow" should be the reserved namespace for canonical
(extension) types.
Neal
On Wed, Aug 24, 2022 at 12:31 PM Micah Kornfield <em...@gmail.com>
wrote:
> Sorry for beling late. I'm -0.5 on "org.apache.arrow." given people
> previously raising naming concerns about having "apache" and "arrow"
> coupled together. I think just "arrow" makes sense here.
>
> I also am not sure about relaxing the 2 language requirement for simple
> implementations, but feel less strongly about this.
>
> On Wed, Aug 24, 2022 at 9:25 AM Pradeep Gollakota
> <pg...@google.com.invalid> wrote:
>
> > +1 (non-binding) With a slight preference for well defined names starting
> > with "arrow." instead of "org.apache.arrow."
> >
> > On Wed, Aug 24, 2022 at 12:16 PM David Li <li...@apache.org> wrote:
> >
> > > +1 (binding)
> > >
> > > Just to check, these rules will presumably be committed into the
> > > documentation as well?
> > >
> > > On Wed, Aug 24, 2022, at 11:24, Antoine Pitrou wrote:
> > > > Hello,
> > > >
> > > > I would like to propose we vote for the following set of rules for
> > > > registering well-known ("canonical") extension types.
> > > >
> > > >
> > > > * Canonical extension types are described and maintained in a
> separate
> > > > document under the format specifications directory:
> > > > https://github.com/apache/arrow/tree/master/docs/source/format (note
> > > > this gets turned into HTML docs by Sphinx =>
> > > > https://arrow.apache.org/docs/index.html)
> > > >
> > > > * Each canonical extension type requires a separate discussion and
> vote
> > > > on the mailing-list
> > > >
> > > > * The specification text to be added *must* follow these requirements
> > > >
> > > > 1) It *must* have a well-defined name starting with
> > > "org.apache.arrow."
> > > > 2) Its parameters, if any, *must* be described in the proposal
> > > > 3) Its serialization *must* be described in the proposal and
> should
> > > > not require unduly work or unusual software dependencies (for
> example,
> > a
> > > > trivial custom text format or JSON would be acceptable)
> > > > 4) Its expected semantics *should* be described as well and any
> > > > potential ambiguities or pain points addressed or at least mentioned
> > > >
> > > > * The extension type *should* have one implementation submitted;
> > > > preferably two if non-trivial (for example if parameterized)
> > > >
> > > >
> > > > The vote will be open for at least 72 hours.
> > > >
> > > > [ ] +1 Accept this proposal
> > > > [ ] +0
> > > > [ ] -1 Do not accept this proposal because...
> > > >
> > > >
> > > > Regards
> > > >
> > > > Antoine.
> > >
> >
> >
> > --
> > Pradeep
> >
>
Re: [VOTE] Format: Rules and procedures for Canonical extension types
Posted by Micah Kornfield <em...@gmail.com>.
Sorry for beling late. I'm -0.5 on "org.apache.arrow." given people
previously raising naming concerns about having "apache" and "arrow"
coupled together. I think just "arrow" makes sense here.
I also am not sure about relaxing the 2 language requirement for simple
implementations, but feel less strongly about this.
On Wed, Aug 24, 2022 at 9:25 AM Pradeep Gollakota
<pg...@google.com.invalid> wrote:
> +1 (non-binding) With a slight preference for well defined names starting
> with "arrow." instead of "org.apache.arrow."
>
> On Wed, Aug 24, 2022 at 12:16 PM David Li <li...@apache.org> wrote:
>
> > +1 (binding)
> >
> > Just to check, these rules will presumably be committed into the
> > documentation as well?
> >
> > On Wed, Aug 24, 2022, at 11:24, Antoine Pitrou wrote:
> > > Hello,
> > >
> > > I would like to propose we vote for the following set of rules for
> > > registering well-known ("canonical") extension types.
> > >
> > >
> > > * Canonical extension types are described and maintained in a separate
> > > document under the format specifications directory:
> > > https://github.com/apache/arrow/tree/master/docs/source/format (note
> > > this gets turned into HTML docs by Sphinx =>
> > > https://arrow.apache.org/docs/index.html)
> > >
> > > * Each canonical extension type requires a separate discussion and vote
> > > on the mailing-list
> > >
> > > * The specification text to be added *must* follow these requirements
> > >
> > > 1) It *must* have a well-defined name starting with
> > "org.apache.arrow."
> > > 2) Its parameters, if any, *must* be described in the proposal
> > > 3) Its serialization *must* be described in the proposal and should
> > > not require unduly work or unusual software dependencies (for example,
> a
> > > trivial custom text format or JSON would be acceptable)
> > > 4) Its expected semantics *should* be described as well and any
> > > potential ambiguities or pain points addressed or at least mentioned
> > >
> > > * The extension type *should* have one implementation submitted;
> > > preferably two if non-trivial (for example if parameterized)
> > >
> > >
> > > The vote will be open for at least 72 hours.
> > >
> > > [ ] +1 Accept this proposal
> > > [ ] +0
> > > [ ] -1 Do not accept this proposal because...
> > >
> > >
> > > Regards
> > >
> > > Antoine.
> >
>
>
> --
> Pradeep
>
Re: [VOTE] Format: Rules and procedures for Canonical extension types
Posted by Pradeep Gollakota <pg...@google.com.INVALID>.
+1 (non-binding) With a slight preference for well defined names starting
with "arrow." instead of "org.apache.arrow."
On Wed, Aug 24, 2022 at 12:16 PM David Li <li...@apache.org> wrote:
> +1 (binding)
>
> Just to check, these rules will presumably be committed into the
> documentation as well?
>
> On Wed, Aug 24, 2022, at 11:24, Antoine Pitrou wrote:
> > Hello,
> >
> > I would like to propose we vote for the following set of rules for
> > registering well-known ("canonical") extension types.
> >
> >
> > * Canonical extension types are described and maintained in a separate
> > document under the format specifications directory:
> > https://github.com/apache/arrow/tree/master/docs/source/format (note
> > this gets turned into HTML docs by Sphinx =>
> > https://arrow.apache.org/docs/index.html)
> >
> > * Each canonical extension type requires a separate discussion and vote
> > on the mailing-list
> >
> > * The specification text to be added *must* follow these requirements
> >
> > 1) It *must* have a well-defined name starting with
> "org.apache.arrow."
> > 2) Its parameters, if any, *must* be described in the proposal
> > 3) Its serialization *must* be described in the proposal and should
> > not require unduly work or unusual software dependencies (for example, a
> > trivial custom text format or JSON would be acceptable)
> > 4) Its expected semantics *should* be described as well and any
> > potential ambiguities or pain points addressed or at least mentioned
> >
> > * The extension type *should* have one implementation submitted;
> > preferably two if non-trivial (for example if parameterized)
> >
> >
> > The vote will be open for at least 72 hours.
> >
> > [ ] +1 Accept this proposal
> > [ ] +0
> > [ ] -1 Do not accept this proposal because...
> >
> >
> > Regards
> >
> > Antoine.
>
--
Pradeep
Re: [VOTE] Format: Rules and procedures for Canonical extension types
Posted by David Li <li...@apache.org>.
+1 (binding)
Just to check, these rules will presumably be committed into the documentation as well?
On Wed, Aug 24, 2022, at 11:24, Antoine Pitrou wrote:
> Hello,
>
> I would like to propose we vote for the following set of rules for
> registering well-known ("canonical") extension types.
>
>
> * Canonical extension types are described and maintained in a separate
> document under the format specifications directory:
> https://github.com/apache/arrow/tree/master/docs/source/format (note
> this gets turned into HTML docs by Sphinx =>
> https://arrow.apache.org/docs/index.html)
>
> * Each canonical extension type requires a separate discussion and vote
> on the mailing-list
>
> * The specification text to be added *must* follow these requirements
>
> 1) It *must* have a well-defined name starting with "org.apache.arrow."
> 2) Its parameters, if any, *must* be described in the proposal
> 3) Its serialization *must* be described in the proposal and should
> not require unduly work or unusual software dependencies (for example, a
> trivial custom text format or JSON would be acceptable)
> 4) Its expected semantics *should* be described as well and any
> potential ambiguities or pain points addressed or at least mentioned
>
> * The extension type *should* have one implementation submitted;
> preferably two if non-trivial (for example if parameterized)
>
>
> The vote will be open for at least 72 hours.
>
> [ ] +1 Accept this proposal
> [ ] +0
> [ ] -1 Do not accept this proposal because...
>
>
> Regards
>
> Antoine.