Package Takeover: `toml`

older
data kinds and exhaustiveness of...

Emily Pillmore

12 Mar 2021 12 Mar '21

2:13 a.m.

To whom it may concern, I'd like to take over maintenance of the package `toml`. I have a burning need. I tried to contact Spiros a year ago, but no response has come. The last release was 2017, and it's safe to say the package is totally abandoned. My hackage user is topos. Cheers, E

Attachments:

attachment.html (text/html — 4.1 KB)

Show replies by date

Javran Cheng

12 Mar 12 Mar

2:31 a.m.

Hi Emily, Just in case you are a stack user, you can create a fork (or just modify it locally), and specify your modified version in extra-deps https://docs.haskellstack.org/en/stable/yaml_configuration/#extra-deps of package.yaml - see examples in the doc, "location: <relative path>" can also be specified if the package is only locally modified. Cheers, Javran On Thu, Mar 11, 2021 at 6:14 PM Emily Pillmore wrote:

...

To whom it may concern,

I'd like to take over maintenance of the package `toml`. I have a burning need. I tried to contact Spiros a year ago, but no response has come. The last release was 2017, and it's safe to say the package is totally abandoned. My hackage user is topos.

Cheers, E

_______________________________________________ Haskell-Cafe mailing list To (un)subscribe, modify options or view archives go to: http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe Only members subscribed via the mailman list are allowed to post.

-- Javran (Fang) Cheng

amindfv＠mailbox.org

3:04 a.m.

On Fri, Mar 12, 2021 at 02:13:12AM +0000, Emily Pillmore wrote:

...

To whom it may concern,

I'd like to take over maintenance of the package `toml`. I have a burning need. I tried to contact Spiros a year ago, but no response has come. The last release was 2017, and it's safe to say the package is totally abandoned. My hackage user is topos.

Hi, I'm a maintainer of `toml`. What do you need? Tom

Carter Schonwald

3:36 a.m.

If you’re the maintainer of https://hackage.haskell.org/package/toml could you give emily maintainer / upload perms ? It really needs a new lead :) 2014 is a long time ago (I co wrote the email to spiros way back when. Any progress on this would be great) On Thu, Mar 11, 2021 at 10:05 PM amindfv--- via Haskell-Cafe < haskell-cafe@haskell.org> wrote:

...

On Fri, Mar 12, 2021 at 02:13:12AM +0000, Emily Pillmore wrote:

...
To whom it may concern,

I'd like to take over maintenance of the package `toml`. I have a burning need. I tried to contact Spiros a year ago, but no response has come. The last release was 2017, and it's safe to say the package is totally abandoned. My hackage user is topos.

Hi, I'm a maintainer of `toml`. What do you need?

Tom

_______________________________________________ Haskell-Cafe mailing list To (un)subscribe, modify options or view archives go to: http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe Only members subscribed via the mailman list are allowed to post.

amindfv＠mailbox.org

4:15 a.m.

I'm in the middle of a package overhaul. If there's a burning need for fixes please get in touch (off-list?) and let me know what you need. Thanks, Tom On Thu, Mar 11, 2021 at 10:36:27PM -0500, Carter Schonwald wrote:

...

If you’re the maintainer of https://hackage.haskell.org/package/toml could you give emily maintainer / upload perms ? It really needs a new lead :) 2014 is a long time ago

(I co wrote the email to spiros way back when. Any progress on this would be great)

On Thu, Mar 11, 2021 at 10:05 PM amindfv--- via Haskell-Cafe < haskell-cafe@haskell.org> wrote:

...
On Fri, Mar 12, 2021 at 02:13:12AM +0000, Emily Pillmore wrote:

...
To whom it may concern,

I'd like to take over maintenance of the package `toml`. I have a burning need. I tried to contact Spiros a year ago, but no response has come. The last release was 2017, and it's safe to say the package is totally abandoned. My hackage user is topos.

Hi, I'm a maintainer of `toml`. What do you need?

Tom

_______________________________________________ Haskell-Cafe mailing list To (un)subscribe, modify options or view archives go to: http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe Only members subscribed via the mailman list are allowed to post.

Carter Schonwald

4:43 a.m.

Are you talking about tomland ?? There’s no GitHub url on the toml package from 2014 ... I think the main priority here is having a canonically good toml lib for the community, in a good name space, That meets our needs robustly (I think emily has some interesting AND WORTHY uses in mind). Can you share the dev repo? To be clear: this is in the context hackage is a public commons and its name space is a resource. Do you have any immediate plans/needs for that specific package name? If not, we promise to give some excellent code a great home in the toml name space if you hand it over. Everyone will be happy and joyous at the resulting work that emily will facilitate. And dogs will dance in the streets and children will smile. If you still have any residual concerns, emily and I are happy to hop on a video chat to solve worries therof. Cheers! -Carter On Thu, Mar 11, 2021 at 11:15 PM amindfv@mailbox.org wrote:

...

I'm in the middle of a package overhaul. If there's a burning need for fixes please get in touch (off-list?) and let me know what you need.

Thanks, Tom

...
If you’re the maintainer of https://hackage.haskell.org/package/toml could you give emily

On Thu, Mar 11, 2021 at 10:36:27PM -0500, Carter Schonwald wrote: maintainer /

...
upload perms ? It really needs a new lead :) 2014 is a long time ago

(I co wrote the email to spiros way back when. Any progress on this would be great)

On Thu, Mar 11, 2021 at 10:05 PM amindfv--- via Haskell-Cafe < haskell-cafe@haskell.org> wrote:

...
On Fri, Mar 12, 2021 at 02:13:12AM +0000, Emily Pillmore wrote:

...
To whom it may concern,

I'd like to take over maintenance of the package `toml`. I have a burning need. I tried to contact Spiros a year ago, but no response has come. The last release was 2017, and it's safe to say the package is totally abandoned. My hackage user is topos.

Hi, I'm a maintainer of `toml`. What do you need?

Tom

_______________________________________________ Haskell-Cafe mailing list To (un)subscribe, modify options or view archives go to: http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe Only members subscribed via the mailman list are allowed to post.

amindfv＠mailbox.org

5:09 a.m.

On Thu, Mar 11, 2021 at 11:43:14PM -0500, Carter Schonwald wrote:

...

Are you talking about tomland ??

No, I'm talking about https://hackage.haskell.org/package/toml .

...

There’s no GitHub url on the toml package from 2014 ...

I think the main priority here is having a canonically good toml lib for the community, in a good name space, That meets our needs robustly (I think emily has some interesting AND WORTHY uses in mind).

Can you share the dev repo?

To be clear: this is in the context hackage is a public commons and its name space is a resource. Do you have any immediate plans/needs for that specific package name?

If not, we promise to give some excellent code a great home in the toml name space if you hand it over. Everyone will be happy and joyous at the resulting work that emily will facilitate. And dogs will dance in the streets and children will smile.

Respectfully, this conversation started because of the claim "I have a burning need." I actually cancelled a plan I had tonight because I wanted to be sure I could be responsive if there was some system going down because of e.g. an outdated set of dependencies. Now the discussion is about how "toml" is a nice name and there are interesting ideas for as-yet unwritten code. If there really is a burning need, I'm still around. Otherwise I'm feeling a bit duped. Tom

...

If you still have any residual concerns, emily and I are happy to hop on a video chat to solve worries therof.

Cheers!

-Carter

On Thu, Mar 11, 2021 at 11:15 PM amindfv@mailbox.org wrote:

...
I'm in the middle of a package overhaul. If there's a burning need for fixes please get in touch (off-list?) and let me know what you need.

Thanks, Tom

...
If you’re the maintainer of https://hackage.haskell.org/package/toml could you give emily

On Thu, Mar 11, 2021 at 10:36:27PM -0500, Carter Schonwald wrote: maintainer /

...
upload perms ? It really needs a new lead :) 2014 is a long time ago

(I co wrote the email to spiros way back when. Any progress on this would be great)

On Thu, Mar 11, 2021 at 10:05 PM amindfv--- via Haskell-Cafe < haskell-cafe@haskell.org> wrote:

...
On Fri, Mar 12, 2021 at 02:13:12AM +0000, Emily Pillmore wrote:

...
To whom it may concern,

I'd like to take over maintenance of the package `toml`. I have a burning need. I tried to contact Spiros a year ago, but no response has come. The last release was 2017, and it's safe to say the package is totally abandoned. My hackage user is topos.

Hi, I'm a maintainer of `toml`. What do you need?

Tom

_______________________________________________ Haskell-Cafe mailing list To (un)subscribe, modify options or view archives go to: http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe Only members subscribed via the mailman list are allowed to post.

Emily Pillmore

5:27 a.m.

Tom, I have been eyeing a remake of this package for a long time for some of my projects. To be clear: there is no fire that needs to be put out, but I do have a need. The package has been out of commission for 7 years, and there are certainly no relevant downstream dependencies at this point. Do you have a source repository or existing code that I could see or make use of in the interim period between now and a release? I'm genuinely surprised there was someone else made maintainer of the package without a public takeover. When/how did this happen? Did I miss the takeover announcement? Carter and I were looking into this in February of last year, and the need arose again, so I brought it up today. Thanks, E On Fri, Mar 12, 2021 at 12:09 AM, < amindfv@mailbox.org > wrote:

...

On Thu, Mar 11, 2021 at 11:43:14PM -0500, Carter Schonwald wrote:

...
Are you talking about tomland ??

No, I'm talking about https:/ / hackage. haskell. org/ package/ toml ( https://hackage.haskell.org/package/toml ).

...
There’s no GitHub url on the toml package from 2014 ...

I think the main priority here is having a canonically good toml lib for the community, in a good name space, That meets our needs robustly (I think emily has some interesting AND WORTHY uses in mind).

Can you share the dev repo?

To be clear: this is in the context hackage is a public commons and its name space is a resource. Do you have any immediate plans/needs for that specific package name?

If not, we promise to give some excellent code a great home in the toml name space if you hand it over. Everyone will be happy and joyous at the resulting work that emily will facilitate. And dogs will dance in the streets and children will smile.

Respectfully, this conversation started because of the claim "I have a burning need." I actually cancelled a plan I had tonight because I wanted to be sure I could be responsive if there was some system going down because of e.g. an outdated set of dependencies. Now the discussion is about how "toml" is a nice name and there are interesting ideas for as-yet unwritten code.

If there really is a burning need, I'm still around. Otherwise I'm feeling a bit duped.

Tom

...
If you still have any residual concerns, emily and I are happy to hop on a video chat to solve worries therof.

Cheers!

-Carter

On Thu, Mar 11 , 2021 at 11:15 PM amindfv@ mailbox. org ( amindfv@mailbox.org ) < amindfv@ mailbox. org ( amindfv@mailbox.org ) > wrote:

...
I'm in the middle of a package overhaul. If there's a burning need for fixes please get in touch (off-list?) and let me know what you need.

Thanks, Tom

On Thu, Mar 11, 2021 at 10:36:27PM -0500, Carter Schonwald wrote:

...
If you’re the maintainer of https:/ / hackage. haskell. org/ package/ toml ( https://hackage.haskell.org/package/toml ) could you give emily

maintainer /

...
upload perms ? It really needs a new lead :) 2014 is a long time ago

(I co wrote the email to spiros way back when. Any progress on this would be great)

On Thu, Mar 11 , 2021 at 10:05 PM amindfv--- via Haskell-Cafe < haskell-cafe@ haskell. org ( haskell-cafe@haskell.org ) > wrote:

...
On Fri, Mar 12, 2021 at 02:13:12AM +0000, Emily Pillmore wrote:

...
To whom it may concern,

I'd like to take over maintenance of the package `toml`. I have a

burning need. I tried to contact Spiros a year ago, but no response

has

...
...
come. The last release was 2017, and it's safe to say the package is totally abandoned. My hackage user is topos.

Hi, I'm a maintainer of `toml`. What do you need?

Tom

_______________________________________________ Haskell-Cafe mailing list To (un)subscribe, modify options or view archives go to: http:/ / mail. haskell. org/ cgi-bin/ mailman/ listinfo/ haskell-cafe ( http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe ) Only members subscribed via the mailman list are allowed to post.

amindfv＠mailbox.org

5:56 a.m.

On Fri, Mar 12, 2021 at 05:27:57AM +0000, Emily Pillmore wrote:

...

Tom,

I have been eyeing a remake of this package for a long time for some of my projects. To be clear: there is no fire that needs to be put out, but I do have a need. The package has been out of commission for 7 years, and there are certainly no relevant downstream dependencies at this point. Do you have a source repository or existing code that I could see or make use of in the interim period between now and a release?

Again, trying to be respectful here, but "burning" kinda does imply "fire," and "need" certainly does imply "need." It's now seeming more just like a desire for the package name. If you're looking for a modern TOML parser asap, I'd recommend one of these popular ones: https://hackage.haskell.org/package/htoml https://hackage.haskell.org/package/tomland https://hackage.haskell.org/package/toml-parser The last one is probably most similar to the `toml` package. It's great. `htoml` was also based on `toml`. If none of these fits the bill, there are more on Hackage. Tom

...

I'm genuinely surprised there was someone else made maintainer of the package without a public takeover. When/how did this happen? Did I miss the takeover announcement? Carter and I were looking into this in February of last year, and the need arose again, so I brought it up today.

Thanks,

E

On Fri, Mar 12, 2021 at 12:09 AM, < amindfv@mailbox.org > wrote:

...
On Thu, Mar 11, 2021 at 11:43:14PM -0500, Carter Schonwald wrote:

...
Are you talking about tomland ??

No, I'm talking about https:/ / hackage. haskell. org/ package/ toml ( https://hackage.haskell.org/package/toml ).

...
There’s no GitHub url on the toml package from 2014 ...

I think the main priority here is having a canonically good toml lib for the community, in a good name space, That meets our needs robustly (I think emily has some interesting AND WORTHY uses in mind).

Can you share the dev repo?

To be clear: this is in the context hackage is a public commons and its name space is a resource. Do you have any immediate plans/needs for that specific package name?

If not, we promise to give some excellent code a great home in the toml name space if you hand it over. Everyone will be happy and joyous at the resulting work that emily will facilitate. And dogs will dance in the streets and children will smile.

Respectfully, this conversation started because of the claim "I have a burning need." I actually cancelled a plan I had tonight because I wanted to be sure I could be responsive if there was some system going down because of e.g. an outdated set of dependencies. Now the discussion is about how "toml" is a nice name and there are interesting ideas for as-yet unwritten code.

If there really is a burning need, I'm still around. Otherwise I'm feeling a bit duped.

Tom

...
If you still have any residual concerns, emily and I are happy to hop on a video chat to solve worries therof.

Cheers!

-Carter

On Thu, Mar 11 , 2021 at 11:15 PM amindfv@ mailbox. org ( amindfv@mailbox.org ) < amindfv@ mailbox. org ( amindfv@mailbox.org ) > wrote:

...
I'm in the middle of a package overhaul. If there's a burning need for fixes please get in touch (off-list?) and let me know what you need.

Thanks, Tom

On Thu, Mar 11, 2021 at 10:36:27PM -0500, Carter Schonwald wrote:

...
If you’re the maintainer of https:/ / hackage. haskell. org/ package/ toml ( https://hackage.haskell.org/package/toml ) could you give emily

maintainer /

...
upload perms ? It really needs a new lead :) 2014 is a long time ago

(I co wrote the email to spiros way back when. Any progress on this would be great)

On Thu, Mar 11 , 2021 at 10:05 PM amindfv--- via Haskell-Cafe < haskell-cafe@ haskell. org ( haskell-cafe@haskell.org ) > wrote:

...
On Fri, Mar 12, 2021 at 02:13:12AM +0000, Emily Pillmore wrote:

> > > To whom it may concern, > > > > I'd like to take over maintenance of the package `toml`. I have a > >

burning need. I tried to contact Spiros a year ago, but no response

has

...
...
come. The last release was 2017, and it's safe to say the package is totally abandoned. My hackage user is topos.

Hi, I'm a maintainer of `toml`. What do you need?

Tom

_______________________________________________ Haskell-Cafe mailing list To (un)subscribe, modify options or view archives go to: http:/ / mail. haskell. org/ cgi-bin/ mailman/ listinfo/ haskell-cafe ( http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe ) Only members subscribed via the mailman list are allowed to post.

Emily Pillmore

6:28 a.m.

Tom, Look, I don't want to debate syntax and semantics here, but "burning need/desire/ambition" etc ( https://idioms.thefreedictionary.com/burning+desire ) is an extremely common colloquialism that doesn't imply an emergency, just a strongly felt urge. I can't apologize for my wording, but I'm sorry for the situation nonetheless.

...

It's now seeming more just like a desire for the package name.

I'm going to look at `toml-parser` in the meantime, but no toml library does what I have in mind (namely a full fledged implementation of the spec, streaming, deriving etc.), nor do many of them provide bidirectional serialization save `tomland`. To reiterate Carter's point, hackage names are a community resource, and they deserve to be thought through carefully, so yes, the package name is part of the request. I do alot of community service to make sure things that take up precious Hackage real-estate are treated well, which is why `toml` posed an opportunity. To that point, anything you put out is something I am interested in investing time and effort into making a standard. Do you have any code currently, or is this a TODO on your list? Going through your hackage libraries, I see no source repository listings, issue trackers, or even an email to reach you by. - E On Fri, Mar 12, 2021 at 12:56 AM, < amindfv@mailbox.org > wrote:

...

On Fri, Mar 12, 2021 at 05:27:57AM +0000, Emily Pillmore wrote:

...
Tom,

I have been eyeing a remake of this package for a long time for some of my projects. To be clear: there is no fire that needs to be put out, but I do have a need. The package has been out of commission for 7 years, and there are certainly no relevant downstream dependencies at this point. Do you have a source repository or existing code that I could see or make use of in the interim period between now and a release?

Again, trying to be respectful here, but "burning" kinda does imply "fire," and "need" certainly does imply "need." It's now seeming more just like a desire for the package name.

If you're looking for a modern TOML parser asap, I'd recommend one of these popular ones:

https:/ / hackage. haskell. org/ package/ htoml ( https://hackage.haskell.org/package/htoml ) https:/ / hackage. haskell. org/ package/ tomland ( https://hackage.haskell.org/package/tomland ) https:/ / hackage. haskell. org/ package/ toml-parser ( https://hackage.haskell.org/package/toml-parser )

The last one is probably most similar to the `toml` package. It's great. `htoml` was also based on `toml`.

If none of these fits the bill, there are more on Hackage.

Tom

...
I'm genuinely surprised there was someone else made maintainer of the package without a public takeover. When/how did this happen? Did I miss the takeover announcement? Carter and I were looking into this in February of last year, and the need arose again, so I brought it up today.

Thanks,

E

On Fri, Mar 12, 2021 at 12:09 AM, < amindfv@ mailbox. org ( amindfv@mailbox.org ) > wrote:

...
On Thu, Mar 11, 2021 at 11:43:14PM -0500, Carter Schonwald wrote:

...
Are you talking about tomland ??

No, I'm talking about https:/ / hackage. haskell. org/ package/ toml ( https:/ / hackage. haskell. org/ package/ toml ( https://hackage.haskell.org/package/toml ) ).

...
There’s no GitHub url on the toml package from 2014 ...

I think the main priority here is having a canonically good toml lib for the community, in a good name space, That meets our needs robustly (I think emily has some interesting AND WORTHY uses in mind).

Can you share the dev repo?

To be clear: this is in the context hackage is a public commons and its name space is a resource. Do you have any immediate plans/needs for that specific package name?

If not, we promise to give some excellent code a great home in the toml name space if you hand it over. Everyone will be happy and joyous at the resulting work that emily will facilitate. And dogs will dance in the streets and children will smile.

Respectfully, this conversation started because of the claim "I have a burning need." I actually cancelled a plan I had tonight because I wanted to be sure I could be responsive if there was some system going down because of e.g. an outdated set of dependencies. Now the discussion is about how "toml" is a nice name and there are interesting ideas for as-yet unwritten code.

If there really is a burning need, I'm still around. Otherwise I'm feeling a bit duped.

Tom

...
If you still have any residual concerns, emily and I are happy to hop on a video chat to solve worries therof.

Cheers!

-Carter

On Thu, Mar 11 , 2021 at 11:15 PM amindfv@ mailbox. org ( amindfv@ mailbox. org ( amindfv@mailbox.org ) ) < amindfv@ mailbox. org ( amindfv@ mailbox. org ( amindfv@mailbox.org ) ) > wrote:

...
I'm in the middle of a package overhaul. If there's a burning need for fixes please get in touch (off-list?) and let me know what you need.

Thanks, Tom

On Thu, Mar 11, 2021 at 10:36:27PM -0500, Carter Schonwald wrote:

...
If you’re the maintainer of https:/ / hackage. haskell. org/ package/ toml ( https:/ / hackage. haskell. org/ package/ toml ( https://hackage.haskell.org/package/toml ) ) could you give emily

maintainer /

...
upload perms ? It really needs a new lead :) 2014 is a long time ago

(I co wrote the email to spiros way back when. Any progress on this would be great)

On Thu, Mar 11 , 2021 at 10:05 PM amindfv--- via Haskell-Cafe < haskell-cafe@ haskell. org ( haskell-cafe@ haskell. org ( haskell-cafe@haskell.org ) ) > wrote:

> > > On Fri, Mar 12, 2021 at 02:13:12AM +0000, Emily Pillmore wrote: > > >> >> >> To whom it may concern, >> >> >> >> I'd like to take over maintenance of the package `toml`. I have a >> >> > > > > burning need. I tried to contact Spiros a year ago, but no response > >

has

...
> > > come. The last release was 2017, and it's safe to say the package is > totally abandoned. My hackage user is topos. > > > > Hi, I'm a maintainer of `toml`. What do you need? > > > > Tom > > > > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: http:/ / mail. > haskell. org/ cgi-bin/ mailman/ listinfo/ haskell-cafe ( > http:/ / mail. haskell. org/ cgi-bin/ mailman/ listinfo/ haskell-cafe ( > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe ) ) Only > members subscribed via the mailman list are allowed to post. > >

amindfv＠mailbox.org

7:01 a.m.

On Fri, Mar 12, 2021 at 06:28:44AM +0000, Emily Pillmore wrote:

...

Tom,

Look, I don't want to debate syntax and semantics here, but "burning need/desire/ambition" etc ( https://idioms.thefreedictionary.com/burning+desire ) is an extremely common colloquialism that doesn't imply an emergency, just a strongly felt urge. I can't apologize for my wording, but I'm sorry for the situation nonetheless.

I also don't want to debate semantics but I can tell you "I have a burning need" on a Hackage takeover has a different connotation of urgency than "I have a burning desire to write a toml parsing library and to have it be named 'toml'". I still feel duped and now condescended to as well. I do nonetheless appreciate your apology for the situation.

...

...
It's now seeming more just like a desire for the package name.

I'm going to look at `toml-parser` in the meantime, but no toml library does what I have in mind (namely a full fledged implementation of the spec, streaming, deriving etc.), nor do many of them provide bidirectional serialization save `tomland`. To reiterate Carter's point, hackage names are a community resource, and they deserve to be thought through carefully, so yes, the package name is part of the request. I do alot of community service to make sure things that take up precious Hackage real-estate are treated well, which is why `toml` posed an opportunity.

I'm actually open to the idea of using a simple name like "toml" for a best-in-class Haskell library, but I'd want to see proof that it is clearly the best in terms of implementation and adoption. I of course think my plans for toml parsing are the most wonderful, but if a consensus favorite package emerges and it's not mine I will step aside.

...

To that point, anything you put out is something I am interested in investing time and effort into making a standard. Do you have any code currently, or is this a TODO on your list? Going through your hackage libraries, I see no source repository listings, issue trackers, or even an email to reach you by.

I do have code, yes. As mentioned earlier I'm in the middle of a rewrite. If there's more to discuss maybe we should move this conversation off-list as it's no longer about a package takeover? Tom

Dmitrii Kovanikov

12:04 p.m.

Hi everyone, I feel extremely sad about this discussion for multiple reasons. But regarding the technical agenda:

...

I'm going to look at `toml-parser` in the meantime, but no toml library does what I have in mind (namely a full fledged implementation of the spec, streaming, deriving etc.), nor do many of them provide bidirectional serialization save `tomland`.

This does sound very disappointing to me and I don't fully understand the needs. Because: * tomland is the official TOML parsing library in Haskell according to the TOML spec wiki https://github.com/toml-lang/toml/wiki * tomland fully supports the spec version 0.5.0, and the latest spec 1.0.0 was published relatively recently. And to my knowledge, it is the only Haskell library that supports the latest spec. * tomland is the most popular TOML parsing library according to reverse dependencies https://packdeps.haskellers.com/reverse on Hackage * tomland is based on explicit values, but nevertheless it provides deriving via Generics I feel very confused about this situation. And again I feel like people the Haskell committees members are not willing to recognise other's people work and would rather rewrite everything from scratch instead of collaborating with existing projects created by people outside of committees. Even outside the Haskell community (the TOML org), tomland was acknowledged as the official TOML library, but not in the Haskell community itself. At least, the following steps could be taken first: * Why not open issues to tomland (or other libraries) and discuss the features you want? We maintain tomland for multiple years. The latest release was Feb 12 2021 (a month ago!). We constantly improve the implementation, fix parsing issues, improve interface and error-handling. Attempting to rewrite all this from scratch instead of collaborating with existing maintainers feels very unfriendly. * If you want to have the official TOML parsing library under the `toml` namespace on Hackage, again, why not ask the maintainers if they consider moving the library? And only after this discussion act accordingly. * If you are concerned about the lack of people working on the `tomland` library (which I don't fully understand, because in Kowainik we always have at least two people maintaining packages), then why not ask to add as a maintainer, instead of rewriting another library? Or even ask to move to the official `haskell` organization on GitHub, if you want to have more people maintaining the official package. I mean, how am I supposed to feel motivated working on Haskell open-source projects, if my work can be just discarded at any time, the official library will be appointed without even communicating this desire? If I weren't subscribed to this thread, I probably wouldn't even know that something is going behind backs. We've put a lot of effort into tomland. We literally spent years of maintenance, UX improvements, bug fixes, writing tutorials and blog posts about the library and its implementation. And it is still not enough just to be respected and even give the chance to reply to the users needs? That sounds very concerning to me. I don' feel like Haskell tech can move forward if people's (specifically if they are not associated with any Haskell leaders) work is disrespected. Best regards, Dmitrii On Fri, 12 Mar 2021 at 07:02, amindfv--- via Haskell-Cafe < haskell-cafe@haskell.org> wrote:

...

On Fri, Mar 12, 2021 at 06:28:44AM +0000, Emily Pillmore wrote:

...
Tom,

Look, I don't want to debate syntax and semantics here, but "burning need/desire/ambition" etc ( https://idioms.thefreedictionary.com/burning+desire ) is an extremely common colloquialism that doesn't imply an emergency, just a strongly felt urge. I can't apologize for my wording, but I'm sorry for the situation nonetheless.

I also don't want to debate semantics but I can tell you "I have a burning need" on a Hackage takeover has a different connotation of urgency than "I have a burning desire to write a toml parsing library and to have it be named 'toml'". I still feel duped and now condescended to as well. I do nonetheless appreciate your apology for the situation.

...
...
It's now seeming more just like a desire for the package name.

I'm going to look at `toml-parser` in the meantime, but no toml library does what I have in mind (namely a full fledged implementation of the spec, streaming, deriving etc.), nor do many of them provide bidirectional serialization save `tomland`. To reiterate Carter's point, hackage names are a community resource, and they deserve to be thought through carefully, so yes, the package name is part of the request. I do alot of community service to make sure things that take up precious Hackage real-estate are treated well, which is why `toml` posed an opportunity.

I'm actually open to the idea of using a simple name like "toml" for a best-in-class Haskell library, but I'd want to see proof that it is clearly the best in terms of implementation and adoption. I of course think my plans for toml parsing are the most wonderful, but if a consensus favorite package emerges and it's not mine I will step aside.

...
To that point, anything you put out is something I am interested in

investing time and effort into making a standard. Do you have any code currently, or is this a TODO on your list? Going through your hackage libraries, I see no source repository listings, issue trackers, or even an email to reach you by.

I do have code, yes. As mentioned earlier I'm in the middle of a rewrite. If there's more to discuss maybe we should move this conversation off-list as it's no longer about a package takeover?

Tom

_______________________________________________ Haskell-Cafe mailing list To (un)subscribe, modify options or view archives go to: http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe Only members subscribed via the mailman list are allowed to post.

Carter Schonwald

12:40 p.m.

Hey Dmitrii, I believe emily has in mind fully incremental streaming support. Which requires a wildly different internal architecture than all the stuff in the aeson inspired design family https://github.com/cartazio/streaming-machine-json Is an example of a constant space json parser with fully incremental consumption and emissions. An predecessor was used in a work prject 5 years ago and it could handle multi gig json monsters like a champ. I never released it to hackage because I want to have a better / more reusable design. Parsing the same 3-10gb json with aeson was impossible on a machine that had hundreds of gigs of ram. :) I believe emily has in mind similar levels of robustness On Fri, Mar 12, 2021 at 7:08 AM Dmitrii Kovanikov wrote:

...

Hi everyone,

I feel extremely sad about this discussion for multiple reasons. But regarding the technical agenda:

...
I'm going to look at `toml-parser` in the meantime, but no toml library does what I have in mind (namely a full fledged implementation of the spec, streaming, deriving etc.), nor do many of them provide bidirectional serialization save `tomland`.

This does sound very disappointing to me and I don't fully understand the needs. Because:

* tomland is the official TOML parsing library in Haskell according to the TOML spec wiki https://github.com/toml-lang/toml/wiki * tomland fully supports the spec version 0.5.0, and the latest spec 1.0.0 was published relatively recently. And to my knowledge, it is the only Haskell library that supports the latest spec. * tomland is the most popular TOML parsing library according to reverse dependencies https://packdeps.haskellers.com/reverse on Hackage * tomland is based on explicit values, but nevertheless it provides deriving via Generics

I feel very confused about this situation. And again I feel like people the Haskell committees members are not willing to recognise other's people work and would rather rewrite everything from scratch instead of collaborating with existing projects created by people outside of committees. Even outside the Haskell community (the TOML org), tomland was acknowledged as the official TOML library, but not in the Haskell community itself.

At least, the following steps could be taken first:

* Why not open issues to tomland (or other libraries) and discuss the features you want? We maintain tomland for multiple years. The latest release was Feb 12 2021 (a month ago!). We constantly improve the implementation, fix parsing issues, improve interface and error-handling. Attempting to rewrite all this from scratch instead of collaborating with existing maintainers feels very unfriendly. * If you want to have the official TOML parsing library under the `toml` namespace on Hackage, again, why not ask the maintainers if they consider moving the library? And only after this discussion act accordingly. * If you are concerned about the lack of people working on the `tomland` library (which I don't fully understand, because in Kowainik we always have at least two people maintaining packages), then why not ask to add as a maintainer, instead of rewriting another library? Or even ask to move to the official `haskell` organization on GitHub, if you want to have more people maintaining the official package.

I mean, how am I supposed to feel motivated working on Haskell open-source projects, if my work can be just discarded at any time, the official library will be appointed without even communicating this desire? If I weren't subscribed to this thread, I probably wouldn't even know that something is going behind backs. We've put a lot of effort into tomland. We literally spent years of maintenance, UX improvements, bug fixes, writing tutorials and blog posts about the library and its implementation. And it is still not enough just to be respected and even give the chance to reply to the users needs?

That sounds very concerning to me. I don' feel like Haskell tech can move forward if people's (specifically if they are not associated with any Haskell leaders) work is disrespected.

Best regards, Dmitrii

On Fri, 12 Mar 2021 at 07:02, amindfv--- via Haskell-Cafe < haskell-cafe@haskell.org> wrote:

...
On Fri, Mar 12, 2021 at 06:28:44AM +0000, Emily Pillmore wrote:

...
Tom,

Look, I don't want to debate syntax and semantics here, but "burning need/desire/ambition" etc ( https://idioms.thefreedictionary.com/burning+desire ) is an extremely common colloquialism that doesn't imply an emergency, just a strongly felt urge. I can't apologize for my wording, but I'm sorry for the situation nonetheless.

I also don't want to debate semantics but I can tell you "I have a burning need" on a Hackage takeover has a different connotation of urgency than "I have a burning desire to write a toml parsing library and to have it be named 'toml'". I still feel duped and now condescended to as well. I do nonetheless appreciate your apology for the situation.

...
...
It's now seeming more just like a desire for the package name.

I'm going to look at `toml-parser` in the meantime, but no toml library does what I have in mind (namely a full fledged implementation of the spec, streaming, deriving etc.), nor do many of them provide bidirectional serialization save `tomland`. To reiterate Carter's point, hackage names are a community resource, and they deserve to be thought through carefully, so yes, the package name is part of the request. I do alot of community service to make sure things that take up precious Hackage real-estate are treated well, which is why `toml` posed an opportunity.

I'm actually open to the idea of using a simple name like "toml" for a best-in-class Haskell library, but I'd want to see proof that it is clearly the best in terms of implementation and adoption. I of course think my plans for toml parsing are the most wonderful, but if a consensus favorite package emerges and it's not mine I will step aside.

...
To that point, anything you put out is something I am interested in

investing time and effort into making a standard. Do you have any code currently, or is this a TODO on your list? Going through your hackage libraries, I see no source repository listings, issue trackers, or even an email to reach you by.

I do have code, yes. As mentioned earlier I'm in the middle of a rewrite. If there's more to discuss maybe we should move this conversation off-list as it's no longer about a package takeover?

Tom

_______________________________________________ Haskell-Cafe mailing list To (un)subscribe, modify options or view archives go to: http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe Only members subscribed via the mailman list are allowed to post.

_______________________________________________ Haskell-Cafe mailing list To (un)subscribe, modify options or view archives go to: http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe Only members subscribed via the mailman list are allowed to post.

Dmitrii Kovanikov

1:10 p.m.

The TOML format is optimized for human-readability, not space efficiency. And it has some data redundancy, which makes it great for the application configuration use-case but not so great as a serialization format. If you are using TOML to serialise data or you need to parse 3-10 GB of application configuration, there's a chance that something can be improved without streaming TOML parsing. So streaming TOML parser looks like a very specific use-case that doesn't justify taking someone's package and making it the official TOML parser. Best regards, Dmitrii On Fri, 12 Mar 2021 at 12:40, Carter Schonwald wrote:

...

Hey Dmitrii, I believe emily has in mind fully incremental streaming support. Which requires a wildly different internal architecture than all the stuff in the aeson inspired design family

https://github.com/cartazio/streaming-machine-json Is an example of a constant space json parser with fully incremental consumption and emissions.

An predecessor was used in a work prject 5 years ago and it could handle multi gig json monsters like a champ. I never released it to hackage because I want to have a better / more reusable design. Parsing the same 3-10gb json with aeson was impossible on a machine that had hundreds of gigs of ram. :)

I believe emily has in mind similar levels of robustness

On Fri, Mar 12, 2021 at 7:08 AM Dmitrii Kovanikov wrote:

...
Hi everyone,

I feel extremely sad about this discussion for multiple reasons. But regarding the technical agenda:

...
I'm going to look at `toml-parser` in the meantime, but no toml library does what I have in mind (namely a full fledged implementation of the spec, streaming, deriving etc.), nor do many of them provide bidirectional serialization save `tomland`.

This does sound very disappointing to me and I don't fully understand the needs. Because:

* tomland is the official TOML parsing library in Haskell according to the TOML spec wiki https://github.com/toml-lang/toml/wiki * tomland fully supports the spec version 0.5.0, and the latest spec 1.0.0 was published relatively recently. And to my knowledge, it is the only Haskell library that supports the latest spec. * tomland is the most popular TOML parsing library according to reverse dependencies https://packdeps.haskellers.com/reverse on Hackage * tomland is based on explicit values, but nevertheless it provides deriving via Generics

I feel very confused about this situation. And again I feel like people the Haskell committees members are not willing to recognise other's people work and would rather rewrite everything from scratch instead of collaborating with existing projects created by people outside of committees. Even outside the Haskell community (the TOML org), tomland was acknowledged as the official TOML library, but not in the Haskell community itself.

At least, the following steps could be taken first:

* Why not open issues to tomland (or other libraries) and discuss the features you want? We maintain tomland for multiple years. The latest release was Feb 12 2021 (a month ago!). We constantly improve the implementation, fix parsing issues, improve interface and error-handling. Attempting to rewrite all this from scratch instead of collaborating with existing maintainers feels very unfriendly. * If you want to have the official TOML parsing library under the `toml` namespace on Hackage, again, why not ask the maintainers if they consider moving the library? And only after this discussion act accordingly. * If you are concerned about the lack of people working on the `tomland` library (which I don't fully understand, because in Kowainik we always have at least two people maintaining packages), then why not ask to add as a maintainer, instead of rewriting another library? Or even ask to move to the official `haskell` organization on GitHub, if you want to have more people maintaining the official package.

I mean, how am I supposed to feel motivated working on Haskell open-source projects, if my work can be just discarded at any time, the official library will be appointed without even communicating this desire? If I weren't subscribed to this thread, I probably wouldn't even know that something is going behind backs. We've put a lot of effort into tomland. We literally spent years of maintenance, UX improvements, bug fixes, writing tutorials and blog posts about the library and its implementation. And it is still not enough just to be respected and even give the chance to reply to the users needs?

That sounds very concerning to me. I don' feel like Haskell tech can move forward if people's (specifically if they are not associated with any Haskell leaders) work is disrespected.

Best regards, Dmitrii

On Fri, 12 Mar 2021 at 07:02, amindfv--- via Haskell-Cafe < haskell-cafe@haskell.org> wrote:

...
On Fri, Mar 12, 2021 at 06:28:44AM +0000, Emily Pillmore wrote:

...
Tom,

Look, I don't want to debate syntax and semantics here, but "burning need/desire/ambition" etc ( https://idioms.thefreedictionary.com/burning+desire ) is an extremely common colloquialism that doesn't imply an emergency, just a strongly felt urge. I can't apologize for my wording, but I'm sorry for the situation nonetheless.

I also don't want to debate semantics but I can tell you "I have a burning need" on a Hackage takeover has a different connotation of urgency than "I have a burning desire to write a toml parsing library and to have it be named 'toml'". I still feel duped and now condescended to as well. I do nonetheless appreciate your apology for the situation.

...
...
It's now seeming more just like a desire for the package name.

I'm going to look at `toml-parser` in the meantime, but no toml library does what I have in mind (namely a full fledged implementation of the spec, streaming, deriving etc.), nor do many of them provide bidirectional serialization save `tomland`. To reiterate Carter's point, hackage names are a community resource, and they deserve to be thought through carefully, so yes, the package name is part of the request. I do alot of community service to make sure things that take up precious Hackage real-estate are treated well, which is why `toml` posed an opportunity.

I'm actually open to the idea of using a simple name like "toml" for a best-in-class Haskell library, but I'd want to see proof that it is clearly the best in terms of implementation and adoption. I of course think my plans for toml parsing are the most wonderful, but if a consensus favorite package emerges and it's not mine I will step aside.

...
To that point, anything you put out is something I am interested in

investing time and effort into making a standard. Do you have any code currently, or is this a TODO on your list? Going through your hackage libraries, I see no source repository listings, issue trackers, or even an email to reach you by.

I do have code, yes. As mentioned earlier I'm in the middle of a rewrite. If there's more to discuss maybe we should move this conversation off-list as it's no longer about a package takeover?

Tom

_______________________________________________ Haskell-Cafe mailing list To (un)subscribe, modify options or view archives go to: http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe Only members subscribed via the mailman list are allowed to post.

_______________________________________________ Haskell-Cafe mailing list To (un)subscribe, modify options or view archives go to: http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe Only members subscribed via the mailman list are allowed to post.

Carter Schonwald

1:22 p.m.

hey dimtrii, i'm sure theres other pieces, thats just the one i'm spec robust engineering is for robustness. not for assuming sane users or nonadversarial inputs relatedly/on that topic, you should probably consider using the float parser in the scientific package rather than https://hackage.haskell.org/package/tomland-1.3.2.0/docs/src/Toml.Parser.Val..., theres some easy to design malicious inputs otherwise (talking about robustness made me look to see if you were using what for parsing floats! ) On Fri, Mar 12, 2021 at 8:11 AM Dmitrii Kovanikov wrote:

...

The TOML format is optimized for human-readability, not space efficiency. And it has some data redundancy, which makes it great for the application configuration use-case but not so great as a serialization format. If you are using TOML to serialise data or you need to parse 3-10 GB of application configuration, there's a chance that something can be improved without streaming TOML parsing.

So streaming TOML parser looks like a very specific use-case that doesn't justify taking someone's package and making it the official TOML parser.

Best regards, Dmitrii

On Fri, 12 Mar 2021 at 12:40, Carter Schonwald wrote:

...
Hey Dmitrii, I believe emily has in mind fully incremental streaming support. Which requires a wildly different internal architecture than all the stuff in the aeson inspired design family

https://github.com/cartazio/streaming-machine-json Is an example of a constant space json parser with fully incremental consumption and emissions.

An predecessor was used in a work prject 5 years ago and it could handle multi gig json monsters like a champ. I never released it to hackage because I want to have a better / more reusable design. Parsing the same 3-10gb json with aeson was impossible on a machine that had hundreds of gigs of ram. :)

I believe emily has in mind similar levels of robustness

On Fri, Mar 12, 2021 at 7:08 AM Dmitrii Kovanikov wrote:

...
Hi everyone,

I feel extremely sad about this discussion for multiple reasons. But regarding the technical agenda:

...
I'm going to look at `toml-parser` in the meantime, but no toml library does what I have in mind (namely a full fledged implementation of the spec, streaming, deriving etc.), nor do many of them provide bidirectional serialization save `tomland`.

This does sound very disappointing to me and I don't fully understand the needs. Because:

* tomland is the official TOML parsing library in Haskell according to the TOML spec wiki https://github.com/toml-lang/toml/wiki * tomland fully supports the spec version 0.5.0, and the latest spec 1.0.0 was published relatively recently. And to my knowledge, it is the only Haskell library that supports the latest spec. * tomland is the most popular TOML parsing library according to reverse dependencies https://packdeps.haskellers.com/reverse on Hackage * tomland is based on explicit values, but nevertheless it provides deriving via Generics

I feel very confused about this situation. And again I feel like people the Haskell committees members are not willing to recognise other's people work and would rather rewrite everything from scratch instead of collaborating with existing projects created by people outside of committees. Even outside the Haskell community (the TOML org), tomland was acknowledged as the official TOML library, but not in the Haskell community itself.

At least, the following steps could be taken first:

* Why not open issues to tomland (or other libraries) and discuss the features you want? We maintain tomland for multiple years. The latest release was Feb 12 2021 (a month ago!). We constantly improve the implementation, fix parsing issues, improve interface and error-handling. Attempting to rewrite all this from scratch instead of collaborating with existing maintainers feels very unfriendly. * If you want to have the official TOML parsing library under the `toml` namespace on Hackage, again, why not ask the maintainers if they consider moving the library? And only after this discussion act accordingly. * If you are concerned about the lack of people working on the `tomland` library (which I don't fully understand, because in Kowainik we always have at least two people maintaining packages), then why not ask to add as a maintainer, instead of rewriting another library? Or even ask to move to the official `haskell` organization on GitHub, if you want to have more people maintaining the official package.

I mean, how am I supposed to feel motivated working on Haskell open-source projects, if my work can be just discarded at any time, the official library will be appointed without even communicating this desire? If I weren't subscribed to this thread, I probably wouldn't even know that something is going behind backs. We've put a lot of effort into tomland. We literally spent years of maintenance, UX improvements, bug fixes, writing tutorials and blog posts about the library and its implementation. And it is still not enough just to be respected and even give the chance to reply to the users needs?

That sounds very concerning to me. I don' feel like Haskell tech can move forward if people's (specifically if they are not associated with any Haskell leaders) work is disrespected.

Best regards, Dmitrii

On Fri, 12 Mar 2021 at 07:02, amindfv--- via Haskell-Cafe < haskell-cafe@haskell.org> wrote:

...
On Fri, Mar 12, 2021 at 06:28:44AM +0000, Emily Pillmore wrote:

...
Tom,

Look, I don't want to debate syntax and semantics here, but "burning need/desire/ambition" etc ( https://idioms.thefreedictionary.com/burning+desire ) is an extremely common colloquialism that doesn't imply an emergency, just a strongly felt urge. I can't apologize for my wording, but I'm sorry for the situation nonetheless.

I also don't want to debate semantics but I can tell you "I have a burning need" on a Hackage takeover has a different connotation of urgency than "I have a burning desire to write a toml parsing library and to have it be named 'toml'". I still feel duped and now condescended to as well. I do nonetheless appreciate your apology for the situation.

...
...
It's now seeming more just like a desire for the package name.

I'm going to look at `toml-parser` in the meantime, but no toml library does what I have in mind (namely a full fledged implementation of the spec, streaming, deriving etc.), nor do many of them provide bidirectional serialization save `tomland`. To reiterate Carter's point, hackage names are a community resource, and they deserve to be thought through carefully, so yes, the package name is part of the request. I do alot of community service to make sure things that take up precious Hackage real-estate are treated well, which is why `toml` posed an opportunity.

I'm actually open to the idea of using a simple name like "toml" for a best-in-class Haskell library, but I'd want to see proof that it is clearly the best in terms of implementation and adoption. I of course think my plans for toml parsing are the most wonderful, but if a consensus favorite package emerges and it's not mine I will step aside.

...
To that point, anything you put out is something I am interested in

investing time and effort into making a standard. Do you have any code currently, or is this a TODO on your list? Going through your hackage libraries, I see no source repository listings, issue trackers, or even an email to reach you by.

I do have code, yes. As mentioned earlier I'm in the middle of a rewrite. If there's more to discuss maybe we should move this conversation off-list as it's no longer about a package takeover?

Tom

_______________________________________________ Haskell-Cafe mailing list To (un)subscribe, modify options or view archives go to: http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe Only members subscribed via the mailman list are allowed to post.

_______________________________________________ Haskell-Cafe mailing list To (un)subscribe, modify options or view archives go to: http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe Only members subscribed via the mailman list are allowed to post.

Imants Cekusins

1:26 p.m.

How about naming all official / recommended / _the_ packages with a prefix / suffix (e.g. base-*) and requiring an approval to create such packages? This way, the required name would always be available when needed.

Carter Schonwald

1:40 p.m.

def a good idea to figure out, though that and or any other solution is as much about making sure the anthropology of the culture over time supports the convention as much as anything else, On Fri, Mar 12, 2021 at 8:29 AM Imants Cekusins wrote:

...

How about naming all official / recommended / _the_ packages with a prefix / suffix (e.g. base-*) and requiring an approval to create such packages?

This way, the required name would always be available when needed. _______________________________________________ Haskell-Cafe mailing list To (un)subscribe, modify options or view archives go to: http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe Only members subscribed via the mailman list are allowed to post.

erik

3:34 p.m.

Tom wrote:

...

We won't find a general principle that holds in all cases but I do think it is worth discussing and perhaps coming up with some voluntary principles that maintainers can sign up to. Looking to how other language ecosystems handle this issue may be helpful.

I am a bystander in this discussion, but reading it I couldn't help but think about how developers in other languages typically avoid this problem (and I don't think this will come as a surprise to anyone here) by giving libraries non-prosaic names. Relatedly, as a developer selecting dependencies for a project, I want to know "what do most people use to solve this particular problem?" It wouldn't matter to me whether the answer is a package named something whimsical and weird as long as it looks well- (and recently!) maintained and there is information on how to use it. I wouldn't presume to offer this as a recommendation to this group, but I was a little surprised by the antagonistic direction of this conversation. Indeed, if there's a new and better approach to TOML parsing (and if I have that particular problem in the future...), I'd be happy to rely on that new approach (and the efforts of those involved), no matter what the package is called. To be honest, though, it's tough for me to tell if Emily's original request is about forking a codebase or simply taking over the name and producing an entirely new codebase? In any case, the work sounds interesting. On Fri, Mar 12, 2021 at 5:42 AM Carter Schonwald wrote:

...

def a good idea to figure out, though that and or any other solution is as much about making sure the anthropology of the culture over time supports the convention as much as anything else,

On Fri, Mar 12, 2021 at 8:29 AM Imants Cekusins wrote:

...
How about naming all official / recommended / _the_ packages with a prefix / suffix (e.g. base-*) and requiring an approval to create such packages?

This way, the required name would always be available when needed. _______________________________________________ Haskell-Cafe mailing list To (un)subscribe, modify options or view archives go to: http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe Only members subscribed via the mailman list are allowed to post.

_______________________________________________ Haskell-Cafe mailing list To (un)subscribe, modify options or view archives go to: http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe Only members subscribed via the mailman list are allowed to post.

-- Erik Aker

Sven Panne

3:31 p.m.

Am Fr., 12. März 2021 um 14:29 Uhr schrieb Imants Cekusins

...

:

...

How about naming all official / recommended / _the_ packages with a prefix / suffix (e.g. base-*) and requiring an approval to create such packages?

I highly doubt that any finite (let alone: small) group of people has the competence to decide what "the" package for a given task should be, given the vast number of topics packages cover. It is OK for mainstream topics, but even then different people have different needs and views. What happens when people not really competent in a given topic try to standardize things as "the" way to do it can e.g. be seen in C++'s SG13, a completely failed attempt to standardize 2D graphics. Apart from a relatively small, undisputed set of things, let the community decide what "the" way to do things should be, basically using "survival of the fittest". If one library is definitely better than another, then it will be used much more often, at least most of the time. An e.g. well-curated "official" overview of libraries for different topics can help here. I think that discussions about package names are quite irrelevant, it is all about discoverability of a package, and the package name doesn't help there at all most of the time. Googling "haskell toml", you get tomland and htoml as the first 2 hits. I would have never guessed the first name BTW, and I actually don't care that much: Even if it's called "gnlpft" and it is the 1st hit on Google and does its task well: So be it! Typing whatever package name into a .cabal file is the least of your problems when choosing a library. Another good example: "aeson". It's not really the first name coming to your mind when you think about JSON, but people don't have a problem discovering it. A more problematic thing than the package names IMHO is the choice of names for the hierarchical modules within a package: If things somehow clash by accident here, you have bigger problems. There is no process whatsoever (at least I don't know one) how these names are allocated. There were some proposals by Malcolm W. and Simon M. some 10-20 years ago IIRC, but these were only rough sketches. Cheers, S.

Henning Thielemann

3:46 p.m.

On Fri, 12 Mar 2021, Sven Panne wrote:

...

Even if it's called "gnlpft" and it is the 1st hit on Google

I think the correct name must be "gnlpfth", because 'h' stands for the Heart that beats for you night and day.

...

Another good example: "aeson". It's not really the first name coming to your mind when you think about JSON, but people don't have a problem discovering it.

This was the first example I also had to think of.

...

A more problematic thing than the package names IMHO is the choice of names for the hierarchical modules within a package: If things somehow clash by accident here, you have bigger problems. There is no process whatsoever (at least I don't know one) how these names are allocated. There were some proposals by Malcolm W. and Simon M. some 10-20 years ago IIRC, but these were only rough sketches.

Most module names today end up in the "Data" folder. :-)

Ivan Perez

3:33 p.m.

This is something I'd strongly vote against. It will likely create yet more fights between people for control of any committee that designates which packages are "recommended". Let the community figure out which packages are best. Let's instead encourage collaboration and agreement at package level, so we work together towards having better packages, as opposed to many not-so-good ones. Ivan On Fri, 12 Mar 2021 at 08:29, Imants Cekusins wrote:

...

How about naming all official / recommended / _the_ packages with a prefix / suffix (e.g. base-*) and requiring an approval to create such packages?

This way, the required name would always be available when needed. _______________________________________________ Haskell-Cafe mailing list To (un)subscribe, modify options or view archives go to: http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe Only members subscribed via the mailman list are allowed to post.

Emily Pillmore

5:13 p.m.

Dmiitri,

...

This does sound very disappointing to me and I don't fully understand the needs.

...

I feel very confused about this situation. And again I feel like people the Haskell committees members are not willing to recognise other's people work and would rather rewrite everything from scratch instead of collaborating with existing projects created by people outside of committees.

You're right. You *don't* fully understand my needs! You have not asked, and just assumed that what I want is exactly what you provide in `tomland`! I am looking at `toml` for a personal side project, not for official business, and I disagree with the existing choices, so I'd like to develop my own and saw a chance to make use of a namespace that was neglected for years on Hackage. This has nothing to do with any technical agenda or anything in my official capacity. In my comments, I said the phrase "develop it into *a* standard" ("standard" as in "good", or of high quality make), not " *the* standard" as in the preferred choice. Multiple standards can exist. I have not said this is official, and I have not said this will be blessed. I have not even mentioned HF or its agendas, or my role in either. This does not preempt you or your libraries, nor does it make a statement about the quality of your work.

...

* Why not open issues to tomland (or other libraries) and discuss the features you want? We maintain tomland for multiple years. The latest release was Feb 12 2021 (a month ago!). We constantly improve the implementation, fix parsing issues, improve interface and error-handling. Attempting to rewrite all this from scratch instead of collaborating with existing maintainers feels very unfriendly.

* If you want to have the official TOML parsing library under the `toml` namespace on Hackage, again, why not ask the maintainers if they consider moving the library? And only after this discussion act accordingly.

* If you are concerned about the lack of people working on the `tomland` library (which I don't fully understand, because in Kowainik we always have at least two people maintaining packages), then why not ask to add as a maintainer, instead of rewriting another library? Or even ask to move to the official `haskell` organization on GitHub, if you want to have more people maintaining the official package.

* Because i have a feature set in mind that seems more appropriate for a new library. * The maintainer (Spiros) has been inactive for 7 years. There is no maintainer listed or source repo available. We messaged Spiros last year, and received no response. I went through the proper channels to check that this was the right thing to do. However, I did not expect Tom Murphy to have been added to the maintainers list, which was a new development, and we'll work with each other to figure out a solution. * This is putting words in my mouth. I have no concerns about the lack of people working on `tomland`.

...

I mean, how am I supposed to feel motivated working on Haskell open-source projects, if my work can be just discarded at any time, the official library will be appointed without even communicating this desire? If I weren't subscribed to this thread, I probably wouldn't even know that something is going behind backs. We've put a lot of effort into tomland. We literally spent years of maintenance, UX improvements, bug fixes, writing tutorials and blog posts about the library and its implementation. And it is still not enough just to be respected and even give the chance to reply to the users needs?

This is not an official project, so these points are moot. Instead of jumping to these conclusions, you could have asked me to clarify any points of contention you may have seen. I'm curious as to why you took this tack, and feel disrespected when `tomland` is the go-to TOML library in Haskell, and as you say, has been recognized outside of the community by the TOML org itself. We can take this offline though.I suspect you are bringing a ton of baggage into the conversation that was not a result of this thread. - E On Fri, Mar 12, 2021 at 8:10 AM, Dmitrii Kovanikov < kovanikov@gmail.com > wrote:

...

The TOML format is optimized for human-readability, not space efficiency. And it has some data redundancy, which makes it great for the application configuration use-case but not so great as a serialization format. If you are using TOML to serialise data or you need to parse 3-10 GB of application configuration, there's a chance that something can be improved without streaming TOML parsing.

So streaming TOML parser looks like a very specific use-case that doesn't justify taking someone's package and making it the official TOML parser.

Best regards, Dmitrii

On Fri, 12 Mar 2021 at 12:40, Carter Schonwald < carter. schonwald@ gmail. com ( carter.schonwald@gmail.com ) > wrote:

...
Hey Dmitrii, I believe emily has in mind fully incremental streaming support. Which requires a wildly different internal architecture than all the stuff in the aeson inspired design family

https:/ / github. com/ cartazio/ streaming-machine-json ( https://github.com/cartazio/streaming-machine-json ) Is an example of a constant space json parser with fully incremental consumption and emissions.

An predecessor was used in a work prject 5 years ago and it could handle multi gig json monsters like a champ. I never released it to hackage because I want to have a better / more reusable design. Parsing the same 3-10gb json with aeson was impossible on a machine that had hundreds of gigs of ram. :)

I believe emily has in mind similar levels of robustness

On Fri, Mar 12, 2021 at 7:08 AM Dmitrii Kovanikov < kovanikov@ gmail. com ( kovanikov@gmail.com ) > wrote:

...
Hi everyone,

I feel extremely sad about this discussion for multiple reasons. But regarding the technical agenda:

...
I'm going to look at `toml-parser` in the meantime, but no toml library does what I have in mind (namely a full fledged implementation of the spec, streaming, deriving etc.), nor do many of them provide bidirectional serialization save `tomland`.

This does sound very disappointing to me and I don't fully understand the needs. Because:

* tomland is the official TOML parsing library in Haskell according to the TOML spec wiki ( https://github.com/toml-lang/toml/wiki ) * tomland fully supports the spec version 0.5.0, and the latest spec 1.0.0 was published relatively recently. And to my knowledge, it is the only Haskell library that supports the latest spec. * tomland is the most popular TOML parsing library according to reverse dependencies ( https://packdeps.haskellers.com/reverse ) on Hackage * tomland is based on explicit values, but nevertheless it provides deriving via Generics

I feel very confused about this situation. And again I feel like people the Haskell committees members are not willing to recognise other's people work and would rather rewrite everything from scratch instead of collaborating with existing projects created by people outside of committees. Even outside the Haskell community (the TOML org), tomland was acknowledged as the official TOML library, but not in the Haskell community itself.

At least, the following steps could be taken first:

* Why not open issues to tomland (or other libraries) and discuss the features you want? We maintain tomland for multiple years. The latest release was Feb 12 2021 (a month ago!). We constantly improve the implementation, fix parsing issues, improve interface and error-handling. Attempting to rewrite all this from scratch instead of collaborating with existing maintainers feels very unfriendly. * If you want to have the official TOML parsing library under the `toml` namespace on Hackage, again, why not ask the maintainers if they consider moving the library? And only after this discussion act accordingly. * If you are concerned about the lack of people working on the `tomland` library (which I don't fully understand, because in Kowainik we always have at least two people maintaining packages), then why not ask to add as a maintainer, instead of rewriting another library? Or even ask to move to the official `haskell` organization on GitHub, if you want to have more people maintaining the official package.

I mean, how am I supposed to feel motivated working on Haskell open-source projects, if my work can be just discarded at any time, the official library will be appointed without even communicating this desire? If I weren't subscribed to this thread, I probably wouldn't even know that something is going behind backs. We've put a lot of effort into tomland. We literally spent years of maintenance, UX improvements, bug fixes, writing tutorials and blog posts about the library and its implementation. And it is still not enough just to be respected and even give the chance to reply to the users needs?

That sounds very concerning to me. I don' feel like Haskell tech can move forward if people's (specifically if they are not associated with any Haskell leaders) work is disrespected.

Best regards, Dmitrii

On Fri, 12 Mar 2021 at 07:02, amindfv--- via Haskell-Cafe < haskell-cafe@ haskell. org ( haskell-cafe@haskell.org ) > wrote:

...
...
On Fri, Mar 12, 2021 at 06:28:44AM +0000, Emily Pillmore wrote:

...
Tom,

Look, I don't want to debate syntax and semantics here, but "burning need/desire/ambition" etc ( https:/ / idioms. thefreedictionary. com/ burning+desire ( https://idioms.thefreedictionary.com/burning+desire ) ) is an extremely common colloquialism that doesn't imply an emergency, just a strongly felt urge. I can't apologize for my wording, but I'm sorry for the situation nonetheless.

I also don't want to debate semantics but I can tell you "I have a burning need" on a Hackage takeover has a different connotation of urgency than "I have a burning desire to write a toml parsing library and to have it be named 'toml'". I still feel duped and now condescended to as well. I do nonetheless appreciate your apology for the situation.

...
...
It's now seeming more just like a desire for the package name.

I'm going to look at `toml-parser` in the meantime, but no toml library does what I have in mind (namely a full fledged implementation of the spec, streaming, deriving etc.), nor do many of them provide bidirectional serialization save `tomland`. To reiterate Carter's point, hackage names are a community resource, and they deserve to be thought through carefully, so yes, the package name is part of the request. I do alot of community service to make sure things that take up precious Hackage real-estate are treated well, which is why `toml` posed an opportunity.

I'm actually open to the idea of using a simple name like "toml" for a best-in-class Haskell library, but I'd want to see proof that it is clearly the best in terms of implementation and adoption. I of course think my plans for toml parsing are the most wonderful, but if a consensus favorite package emerges and it's not mine I will step aside.

...
To that point, anything you put out is something I am interested in

investing time and effort into making a standard. Do you have any code currently, or is this a TODO on your list? Going through your hackage libraries, I see no source repository listings, issue trackers, or even an email to reach you by.

I do have code, yes. As mentioned earlier I'm in the middle of a rewrite. If there's more to discuss maybe we should move this conversation off-list as it's no longer about a package takeover?

Tom

...
_______________________________________________ Haskell-Cafe mailing list To (un)subscribe, modify options or view archives go to: http:/ / mail. haskell. org/ cgi-bin/ mailman/ listinfo/ haskell-cafe ( http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe ) Only members subscribed via the mailman list are allowed to post.

_______________________________________________ Haskell-Cafe mailing list To (un)subscribe, modify options or view archives go to: http:/ / mail. haskell. org/ cgi-bin/ mailman/ listinfo/ haskell-cafe ( http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe ) Only members subscribed via the mailman list are allowed to post.

_______________________________________________ Haskell-Cafe mailing list To (un)subscribe, modify options or view archives go to: http:/ / mail. haskell. org/ cgi-bin/ mailman/ listinfo/ haskell-cafe ( http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe ) Only members subscribed via the mailman list are allowed to post.

Joachim Durchholz

13 Mar 13 Mar

7:38 a.m.

Am 12.03.21 um 18:13 schrieb Emily Pillmore:

...

I'm curious as to why you took this tack, and feel disrespected when `tomland` is the go-to TOML library in Haskell, and as you say, has been recognized outside of the community by the TOML org itself.

I understand your irritation at Tom derailing your request into a discussion about all kinds of unrelated things. (I'm irritated myself how he's emphasizing his feelings in so many of his messages; it's not an irrelevant topic but he has made his feelings clear enough, and the focus should be on other things as well.) However, since you state that the existing packages do not meet your needs and want to restructure the code, maybe taking over Tom's package(s) isn't a good idea anyway - restructuring tends to affect the public API, and library users would have reason to object to that. You already have the code - nothing prevents you from taking it and adapting it to your needs. And you don't need the name. Either your library is getting enough traction that it will be mentioned, and then search engines will find it regardless of its name; or your library will end being useful mainly for yourself, and then the name doesn't matter. Regards, Jo

Henning Thielemann

12 Mar 12 Mar

11:36 a.m.

On Thu, 11 Mar 2021, amindfv--- via Haskell-Cafe wrote:

...

Again, trying to be respectful here, but "burning" kinda does imply "fire," and "need" certainly does imply "need." It's now seeming more just like a desire for the package name.

I have nothing to do with 'toml' but the many takeover requests in the recent past make me nervous that if I am away from Haskell programming for some weeks or months brings me in danger of losing my packages. Btw. for some years I was not subscribed to Haskell Cafe because of high traffic and I would have missed such takeover request. I think the preference should be to create a fork. Tom, could you please add a Maintainer field at hackage/toml via the Hackage revision feature?

Tom Ellis

11:50 a.m.

On Fri, Mar 12, 2021 at 12:36:16PM +0100, Henning Thielemann wrote:

...

On Thu, 11 Mar 2021, amindfv--- via Haskell-Cafe wrote:

...
Again, trying to be respectful here, but "burning" kinda does imply "fire," and "need" certainly does imply "need." It's now seeming more just like a desire for the package name.

I have nothing to do with 'toml' but the many takeover requests in the recent past make me nervous that if I am away from Haskell programming for some weeks or months brings me in danger of losing my packages. Btw. for some years I was not subscribed to Haskell Cafe because of high traffic and I would have missed such takeover request. I think the preference should be to create a fork.

This raises an interesting question: to whom does the entry in the package namespace belong? There's a tacit assumption that it belongs to the first person who registered it. Arguably though it could be deemed to belong to the community. The more "generic" the name the more water that argument seems to hold. The solution of "create a fork" could equally well be turned around to apply to a package maintainer who returns after a long absence to find that the community has taken over maintenance of her package. I don't think there's any absolute sense in which that is the wrong answer. We won't find a general principle that holds in all cases but I do think it is worth discussing and perhaps coming up with some voluntary principles that maintainers can sign up to. Looking to how other language ecosystems handle this issue may be helpful. Tom

Carter Schonwald

11:54 a.m.

Agreed. On Fri, Mar 12, 2021 at 6:51 AM Tom Ellis < tom-lists-haskell-cafe-2017@jaguarpaw.co.uk> wrote:

...

On Fri, Mar 12, 2021 at 12:36:16PM +0100, Henning Thielemann wrote:

...
On Thu, 11 Mar 2021, amindfv--- via Haskell-Cafe wrote:

...
Again, trying to be respectful here, but "burning" kinda does imply "fire," and "need" certainly does imply "need." It's now seeming more just like a desire for the package name.

I have nothing to do with 'toml' but the many takeover requests in the recent past make me nervous that if I am away from Haskell programming for some weeks or months brings me in danger of losing my packages. Btw. for some years I was not subscribed to Haskell Cafe because of high traffic and I would have missed such takeover request. I think the preference should be to create a fork.

This raises an interesting question: to whom does the entry in the package namespace belong? There's a tacit assumption that it belongs to the first person who registered it. Arguably though it could be deemed to belong to the community. The more "generic" the name the more water that argument seems to hold.

The solution of "create a fork" could equally well be turned around to apply to a package maintainer who returns after a long absence to find that the community has taken over maintenance of her package. I don't think there's any absolute sense in which that is the wrong answer.

We won't find a general principle that holds in all cases but I do think it is worth discussing and perhaps coming up with some voluntary principles that maintainers can sign up to. Looking to how other language ecosystems handle this issue may be helpful.

Tom _______________________________________________ Haskell-Cafe mailing list To (un)subscribe, modify options or view archives go to: http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe Only members subscribed via the mailman list are allowed to post.

amindfv＠mailbox.org

6:02 p.m.

On Fri, Mar 12, 2021 at 11:50:06AM +0000, Tom Ellis wrote:

...

On Fri, Mar 12, 2021 at 12:36:16PM +0100, Henning Thielemann wrote:

...
On Thu, 11 Mar 2021, amindfv--- via Haskell-Cafe wrote:

...
Again, trying to be respectful here, but "burning" kinda does imply "fire," and "need" certainly does imply "need." It's now seeming more just like a desire for the package name.

I have nothing to do with 'toml' but the many takeover requests in the recent past make me nervous that if I am away from Haskell programming for some weeks or months brings me in danger of losing my packages. Btw. for some years I was not subscribed to Haskell Cafe because of high traffic and I would have missed such takeover request. I think the preference should be to create a fork.

This raises an interesting question: to whom does the entry in the package namespace belong? There's a tacit assumption that it belongs to the first person who registered it. Arguably though it could be deemed to belong to the community. The more "generic" the name the more water that argument seems to hold.

As I said earlier, I'm open to this line of reasoning if there's a clear winner in terms of mindshare and functionality. As it is there are multiple popular, relatively mature packages, and the request was to give the name to a project which doesn't yet exist except in stub form. "Belonging to the community" is a tricky concept, too - imagine the community speaks and declares tomland the winner, and tomland gets moved to the 'toml' namespace. Then, a couple years down the line, people find they want streaming parsing and in the meantime Carter and Emily have written great code. Do we then kick The Package Formerly Known As Tomland out of the 'toml' spot and put an entirely different project there? That's quite a breaking change for people with 'toml' in their .cabal files. For what it's worth, my rewrite isn't a whole-cloth reimagning but instead is a fairly straightforward modernization of the existing 'toml' code. Tom

Emily Pillmore

6:29 p.m.

Fwiw, I agree with the notion that "belonging to the community" is tricky, and entitled to a certain degree. That being said (and this might be where there is confusion in terms of what everyone believes or doesn't believe surround the subject), I think a diversity of projects that answer a particular need is better than a single monolithic choice. For example, I also work on the `waargonaut` series of libraries which offer an alternative solution to JSON in contrast to `aeson`: a succinct zipper-based approach to parsing which is faster in some cases than the one used in `aeson`, and the controversial stance that deriving JSON schema is an anti-pattern. And despite there being contention in that last point, the succinct-zipper approach has led many to choose it for streaming JSON, and we've been able to POC improvements to the `aeson` parser based on things we've done in `waargonaut`. By no means will `waargonaut` ever be the blessed choice, but it is still useful and valuable just for existing and trying something different. So in my mind, at least, competition is friendly and doesn't dilute any particular market share if it's significantly different. At the very least, I'd like to at least not have `toml` in its current state appear as a viable candidate in the list of hackage packages without being more up to date and presenting a sound choice, if not the most ideal. And i'm perfectly happy with saying "Hey, Tom got here first, c'est la vie" and helping him renovate the library if he's just looking at modernizing the existing code! This doesn't really entail kicking anyone out or blessing any package in particular. It's more janitorial to me. - E On Fri, Mar 12, 2021 at 1:02 PM, amindfv--- < haskell-cafe@haskell.org > wrote:

...

On Fri, Mar 12, 2021 at 11:50:06AM +0000, Tom Ellis wrote:

...
On Fri, Mar 12, 2021 at 12:36:16PM +0100, Henning Thielemann wrote:

...
On Thu, 11 Mar 2021, amindfv--- via Haskell-Cafe wrote:

...
Again, trying to be respectful here, but "burning" kinda does imply "fire," and "need" certainly does imply "need." It's now seeming more just like a desire for the package name.

I have nothing to do with 'toml' but the many takeover requests in the recent past make me nervous that if I am away from Haskell programming for some weeks or months brings me in danger of losing my packages. Btw. for some years I was not subscribed to Haskell Cafe because of high traffic and I would have missed such takeover request. I think the preference should be to create a fork.

This raises an interesting question: to whom does the entry in the package namespace belong? There's a tacit assumption that it belongs to the first person who registered it. Arguably though it could be deemed to belong to the community. The more "generic" the name the more water that argument seems to hold.

As I said earlier, I'm open to this line of reasoning if there's a clear winner in terms of mindshare and functionality. As it is there are multiple popular, relatively mature packages, and the request was to give the name to a project which doesn't yet exist except in stub form.

"Belonging to the community" is a tricky concept, too - imagine the community speaks and declares tomland the winner, and tomland gets moved to the 'toml' namespace. Then, a couple years down the line, people find they want streaming parsing and in the meantime Carter and Emily have written great code. Do we then kick The Package Formerly Known As Tomland out of the 'toml' spot and put an entirely different project there? That's quite a breaking change for people with 'toml' in their .cabal files.

For what it's worth, my rewrite isn't a whole-cloth reimagning but instead is a fairly straightforward modernization of the existing 'toml' code.

Tom _______________________________________________ Haskell-Cafe mailing list To (un)subscribe, modify options or view archives go to: http:/ / mail. haskell. org/ cgi-bin/ mailman/ listinfo/ haskell-cafe ( http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe ) Only members subscribed via the mailman list are allowed to post.

Hécate

3:37 p.m.

I think you shouldn't reasonably fear a takeover demand on the mailing-list if you don't disappear for years without a clear successor. Le 12/03/2021 à 12:36, Henning Thielemann a écrit :

...

On Thu, 11 Mar 2021, amindfv--- via Haskell-Cafe wrote:

...
Again, trying to be respectful here, but "burning" kinda does imply "fire," and "need" certainly does imply "need." It's now seeming more just like a desire for the package name.

I have nothing to do with 'toml' but the many takeover requests in the recent past make me nervous that if I am away from Haskell programming for some weeks or months brings me in danger of losing my packages. Btw. for some years I was not subscribed to Haskell Cafe because of high traffic and I would have missed such takeover request. I think the preference should be to create a fork.

Tom, could you please add a Maintainer field at hackage/toml via the Hackage revision feature? _______________________________________________ Haskell-Cafe mailing list To (un)subscribe, modify options or view archives go to: http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe Only members subscribed via the mailman list are allowed to post.

-- Hécate ✨ 🐦: @TechnoEmpress IRC: Uniaika WWW: https://glitchbra.in RUN: BSD

Carter Schonwald

3:46 p.m.

Yeah, especially since a takeover does require actually documenting you’ve made real efforts to reach the maintainer / last person to do a package upload. On Fri, Mar 12, 2021 at 10:41 AM Hécate wrote:

...

I think you shouldn't reasonably fear a takeover demand on the mailing-list if you don't disappear for years without a clear successor.

Le 12/03/2021 à 12:36, Henning Thielemann a écrit :

...
On Thu, 11 Mar 2021, amindfv--- via Haskell-Cafe wrote:

...
Again, trying to be respectful here, but "burning" kinda does imply "fire," and "need" certainly does imply "need." It's now seeming more just like a desire for the package name.

I have nothing to do with 'toml' but the many takeover requests in the recent past make me nervous that if I am away from Haskell programming for some weeks or months brings me in danger of losing my packages. Btw. for some years I was not subscribed to Haskell Cafe because of high traffic and I would have missed such takeover request. I think the preference should be to create a fork.

Tom, could you please add a Maintainer field at hackage/toml via the Hackage revision feature? _______________________________________________ Haskell-Cafe mailing list To (un)subscribe, modify options or view archives go to: http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe Only members subscribed via the mailman list are allowed to post.

-- Hécate ✨ 🐦: @TechnoEmpress IRC: Uniaika WWW: https://glitchbra.in RUN: BSD

_______________________________________________ Haskell-Cafe mailing list To (un)subscribe, modify options or view archives go to: http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe Only members subscribed via the mailman list are allowed to post.

Henning Thielemann

3:49 p.m.

On Fri, 12 Mar 2021, Hécate wrote:

...

I think you shouldn't reasonably fear a takeover demand on the mailing-list if you don't disappear for years without a clear successor.

I ask you to defend my packages, if I am unavailable for some time! :-)

Hécate

4:03 p.m.

I shall defend them to best of my abilities! Le 12/03/2021 à 16:49, Henning Thielemann a écrit :

...

On Fri, 12 Mar 2021, Hécate wrote:

...
I think you shouldn't reasonably fear a takeover demand on the mailing-list if you don't disappear for years without a clear successor.

I ask you to defend my packages, if I am unavailable for some time! :-)

-- Hécate ✨ 🐦: @TechnoEmpress IRC: Uniaika WWW: https://glitchbra.in RUN: BSD

Bryan Richter

4:37 p.m.

There's some wringing of hands about dark powers taking over packages in the dead of night that I find uncalled for. Ironically, then, I'm still curious to hear the answer to Emily's question. Was there, in fact, a previous package takeover of toml that wasn't publicly announced? Or is amindfv the original maintainer that everyone didn't know they were looking for? On Fri, 12 Mar 2021, 18.04 Hécate, wrote:

...

I shall defend them to best of my abilities!

Le 12/03/2021 à 16:49, Henning Thielemann a écrit :

...
On Fri, 12 Mar 2021, Hécate wrote:

...
I think you shouldn't reasonably fear a takeover demand on the mailing-list if you don't disappear for years without a clear successor.

I ask you to defend my packages, if I am unavailable for some time! :-)

-- Hécate ✨ 🐦: @TechnoEmpress IRC: Uniaika WWW: https://glitchbra.in RUN: BSD

_______________________________________________ Haskell-Cafe mailing list To (un)subscribe, modify options or view archives go to: http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe Only members subscribed via the mailman list are allowed to post.

Henning Thielemann

4:42 p.m.

On Fri, 12 Mar 2021, Bryan Richter wrote:

...

There's some wringing of hands about dark powers taking over packages in the dead of night that I find uncalled for. Ironically, then, I'm still curious to hear the answer to Emily's question. Was there, in fact, a previous package takeover of toml that wasn't publicly announced?

I don't think there is any need for a public announcment if a package creator hands over maintainership to another developer.

Brandon Allbery

4:55 p.m.

That depends. Can I in fact, were I looking for a maintainer, find out who to contact about the package? Ideally without much digging. On Fri, Mar 12, 2021 at 11:44 AM Henning Thielemann < lemming@henning-thielemann.de> wrote:

...

On Fri, 12 Mar 2021, Bryan Richter wrote:

...
There's some wringing of hands about dark powers taking over packages in the dead of night that I find uncalled for. Ironically, then, I'm still curious to hear the answer to Emily's question. Was there, in fact, a previous package takeover of toml that wasn't publicly announced?

I don't think there is any need for a public announcment if a package creator hands over maintainership to another developer. _______________________________________________ Haskell-Cafe mailing list To (un)subscribe, modify options or view archives go to: http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe Only members subscribed via the mailman list are allowed to post.

-- brandon s allbery kf8nh allbery.b@gmail.com

Henning Thielemann

4:59 p.m.

On Fri, 12 Mar 2021, Brandon Allbery wrote:

...

That depends. Can I in fact, were I looking for a maintainer, find out who to contact about the package? Ideally without much digging.

That's what the Cabal.Maintainer field is for. It is missing in toml, which is bad.

Bryan Richter

5:15 p.m.

Can I suggest to the Hackage Whoever a slight change in policy? I think the shock of seeing a package takeover request for your own package is understandably, uh, shocking, and makes the ensuing discussion tense. I also feel like most takeover requests follow this pattern; rarely does a package end up changing hands. Perhaps it's a problem of tone. Rather than suggesting "State your intention to take over the package in a public forum ", step 2 should lighten up and state, "After trying to reach the maintainer for a reasonable amount of time, reach out to the public to expand your search." https://wiki.haskell.org/Taking_over_a_package On Fri, 12 Mar 2021, 18.59 Henning Thielemann, < lemming@henning-thielemann.de> wrote:

...

On Fri, 12 Mar 2021, Brandon Allbery wrote:

...
That depends. Can I in fact, were I looking for a maintainer, find out who to contact about the package? Ideally without much digging.

That's what the Cabal.Maintainer field is for. It is missing in toml, which is bad.

Henning Thielemann

5:36 p.m.

On Fri, 12 Mar 2021, Bryan Richter wrote:

...

Rather than suggesting "State your intention to take over the package in a public forum ", step 2 should lighten up and state, "After trying to reach the maintainer for a reasonable amount of time, reach out to the public to expand your search."

Sounds much better to me.

...

https://wiki.haskell.org/Taking_over_a_package

Carter Schonwald

5:37 p.m.

But that’s in fact what happened here! :) On Fri, Mar 12, 2021 at 12:27 PM Bryan Richter wrote:

...

Can I suggest to the Hackage Whoever a slight change in policy?

I think the shock of seeing a package takeover request for your own package is understandably, uh, shocking, and makes the ensuing discussion tense. I also feel like most takeover requests follow this pattern; rarely does a package end up changing hands.

Perhaps it's a problem of tone.

Rather than suggesting "State your intention to take over the package in a public forum ", step 2 should lighten up and state, "After trying to reach the maintainer for a reasonable amount of time, reach out to the public to expand your search."

https://wiki.haskell.org/Taking_over_a_package

On Fri, 12 Mar 2021, 18.59 Henning Thielemann, < lemming@henning-thielemann.de> wrote:

...
On Fri, 12 Mar 2021, Brandon Allbery wrote:

...
That depends. Can I in fact, were I looking for a maintainer, find out who to contact about the package? Ideally without much digging.

That's what the Cabal.Maintainer field is for. It is missing in toml, which is bad.

_______________________________________________ Haskell-Cafe mailing list To (un)subscribe, modify options or view archives go to: http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe Only members subscribed via the mailman list are allowed to post.

amindfv＠mailbox.org

6:29 p.m.

On Fri, Mar 12, 2021 at 07:15:12PM +0200, Bryan Richter wrote:

...

Can I suggest to the Hackage Whoever a slight change in policy?

I think the shock of seeing a package takeover request for your own package is understandably, uh, shocking, and makes the ensuing discussion tense. I also feel like most takeover requests follow this pattern; rarely does a package end up changing hands.

Perhaps it's a problem of tone.

I wasn't at all shocked at the original request. I figured, correctly, Emily had looked at the package on Hackage and not seen a maintainer listed. Seemed like an easy fix. If you look at the original messages I was ready and willing to help. The shock, if there was any, came from what felt like an unwarranted claim of an urgent need, and a push to take it over even after I materialized.

...

Rather than suggesting "State your intention to take over the package in a public forum ", step 2 should lighten up and state, "After trying to reach the maintainer for a reasonable amount of time, reach out to the public to expand your search."

I don't have a problem with the original wording but I do like your change. Tom

...

https://wiki.haskell.org/Taking_over_a_package

On Fri, 12 Mar 2021, 18.59 Henning Thielemann, < lemming@henning-thielemann.de> wrote:

...
On Fri, 12 Mar 2021, Brandon Allbery wrote:

...
That depends. Can I in fact, were I looking for a maintainer, find out who to contact about the package? Ideally without much digging.

That's what the Cabal.Maintainer field is for. It is missing in toml, which is bad.

...

_______________________________________________ Haskell-Cafe mailing list To (un)subscribe, modify options or view archives go to: http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe Only members subscribed via the mailman list are allowed to post.

Gershom B

9:26 p.m.

On Mar 12, 2021, 12:27 PM -0500, Bryan Richter , wrote:

...

Can I suggest to the Hackage Whoever a slight change in policy?

I think the shock of seeing a package takeover request for your own package is understandably, uh, shocking, and makes the ensuing discussion tense. I also feel like most takeover requests follow this pattern; rarely does a package end up changing hands.

Perhaps it's a problem of tone.

Rather than suggesting "State your intention to take over the package in a public forum ", step 2 should lighten up and state, "After trying to reach the maintainer for a reasonable amount of time, reach out to the public to expand your search."

https://wiki.haskell.org/Taking_over_a_package

The proposed change is not just a tone change. The point of step 2 is that an official request be filed in a public forum and sufficient time then pass that we can be confident the maintainer has been publicly informed of the issue. It’s not about having a heavy tone or the like. This whole fracas is simply the result of confusion and miscommunication — a package appeared unmaintained, but it turned out that there was a maintainer, but it was hard to tell because the maintainer was not listed on the last uploaded package. The correct fix for this is everyone chill out, go for a walk, and then get on with more productive things. By the way, I should mention that there _is_ a hackage audit log of who has been added to maintainer (and trustee and admin) groups, and by whom, since there seemed to be some confusion about that. Best, Gershom

Bryan Richter

13 Mar 13 Mar

6:52 a.m.

Fair point: my suggestion was unclear. I agree that explicitly stating a takeover request is important. I meant to suggest widening the search as an intermediate step between direct contact with the maintainer and the takeover announcement, itself. It could be step 1.B.? For the record, I think that Emily, Tom, and others acted reasonably and in good faith in this thread, although my own tone was regrettably snappy. I do think the existing policy works, but I stand by my (clarified) suggestion. Even if the actual maintainer is unruffled by the sudden appearance of a takeover announcement, as in this case, the wider public --- most of whom probably aren't even aware of the policy --- should also be considered. I think it's easier to avoid [confusion] than resist it. If people keep getting confused by the same thing, maybe it's the thing itself that needs clarification. On Fri, 12 Mar 2021, 23.27 Gershom B, wrote:

...

On Mar 12, 2021, 12:27 PM -0500, Bryan Richter , wrote:

Can I suggest to the Hackage Whoever a slight change in policy?

I think the shock of seeing a package takeover request for your own package is understandably, uh, shocking, and makes the ensuing discussion tense. I also feel like most takeover requests follow this pattern; rarely does a package end up changing hands.

Perhaps it's a problem of tone.

Rather than suggesting "State your intention to take over the package in a public forum ", step 2 should lighten up and state, "After trying to reach the maintainer for a reasonable amount of time, reach out to the public to expand your search."

https://wiki.haskell.org/Taking_over_a_package

The proposed change is not just a tone change. The point of step 2 is that an official request be filed in a public forum and sufficient time then pass that we can be confident the maintainer has been publicly informed of the issue. It’s not about having a heavy tone or the like.

This whole fracas is simply the result of confusion and miscommunication — a package appeared unmaintained, but it turned out that there was a maintainer, but it was hard to tell because the maintainer was not listed on the last uploaded package. The correct fix for this is everyone chill out, go for a walk, and then get on with more productive things.

By the way, I should mention that there _is_ a hackage audit log of who has been added to maintainer (and trustee and admin) groups, and by whom, since there seemed to be some confusion about that.

Best, Gershom _______________________________________________ Haskell-Cafe mailing list To (un)subscribe, modify options or view archives go to: http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe Only members subscribed via the mailman list are allowed to post.

Bertram Felgenhauer

2:42 p.m.

Gershom B wrote:

...

By the way, I should mention that there _is_ a hackage audit log of who has been added to maintainer (and trustee and admin) groups, and by whom, since there seemed to be some confusion about that.

The list of maintainers is public; in this case, https://hackage.haskell.org/package/toml/maintainers/ But that doesn't solve the problem of *contacting* a maintainer; all you get is a name and a list of other packages they maintain. Still, maybe it would help if this feature was more prominent? A direct link from the package description page could work, though it's not obvious where the best place is. An unobtrusive but perhaps too subtle place would be the "package maintainers" phrase under "Maintainer's Corner". The obvious place to look is in the summary box, but that is already very crowded. Cheers, Bertram

Bertram Felgenhauer

3:06 p.m.

I wrote:

...

https://hackage.haskell.org/package/toml/maintainers/

Still, maybe it would help if this feature was more prominent?

See also https://github.com/haskell/hackage-server/issues/918 Cheers, Bertram

Roman

4:55 p.m.

Emily,

...

Carter and I were looking into this in February of last year, and the need arose again, so I brought it up today.

...

I have been eyeing a remake of this package for a long time for some of my projects. To be clear: there is no fire that needs to be put out, but I do have a need.

It's not a "need" (not a technical one at least), it's a desire to control a certain package name. Even if there was no responsive maintainer, I'd argue that if anything that name should be given to Kowainik who already support the de facto standard Haskell library for dealing with TOML, 'cause their package fits your criteria (I absolutely do not agree with that criteria, but that's irrelevant) hackage names are a community resource, and they deserve to be thought

...

through carefully

much better than your yet-to-be-written library (despite the fact that you'll most certainly produce a great library). If "Hackage real-estate" is that "precious", as you put it, it shouldn't be given away on the basis of a promise to write a standard library, there should be actual code to compare. I'm genuinely surprised there was someone else made maintainer of the

...

package without a public takeover. When/how did this happen?

I do not feel like the author of a library takes the responsibility to inform the public about giving someone permissions to their own library by uploading it to Hackage. There *should* be some package metadata that specifies a way to contact the maintainer, but that issue is now fixed. сб, 13 мар. 2021 г. в 18:07, Bertram Felgenhauer via Haskell-Cafe < haskell-cafe@haskell.org>:

...

I wrote:

...
https://hackage.haskell.org/package/toml/maintainers/

Still, maybe it would help if this feature was more prominent?

See also https://github.com/haskell/hackage-server/issues/918

Cheers,

Bertram _______________________________________________ Haskell-Cafe mailing list To (un)subscribe, modify options or view archives go to: http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe Only members subscribed via the mailman list are allowed to post.

amindfv＠mailbox.org

9:07 p.m.

This is being amicably resolved off-list. Tom On Sat, Mar 13, 2021 at 07:55:41PM +0300, Roman wrote:

...

Emily,

...
Carter and I were looking into this in February of last year, and the need arose again, so I brought it up today.

...
I have been eyeing a remake of this package for a long time for some of my projects. To be clear: there is no fire that needs to be put out, but I do have a need.

It's not a "need" (not a technical one at least), it's a desire to control a certain package name. Even if there was no responsive maintainer, I'd argue that if anything that name should be given to Kowainik who already support the de facto standard Haskell library for dealing with TOML, 'cause their package fits your criteria (I absolutely do not agree with that criteria, but that's irrelevant)

hackage names are a community resource, and they deserve to be thought

...
through carefully

much better than your yet-to-be-written library (despite the fact that you'll most certainly produce a great library). If "Hackage real-estate" is that "precious", as you put it, it shouldn't be given away on the basis of a promise to write a standard library, there should be actual code to compare.

I'm genuinely surprised there was someone else made maintainer of the

...
package without a public takeover. When/how did this happen?

I do not feel like the author of a library takes the responsibility to inform the public about giving someone permissions to their own library by uploading it to Hackage. There *should* be some package metadata that specifies a way to contact the maintainer, but that issue is now fixed.

сб, 13 мар. 2021 г. в 18:07, Bertram Felgenhauer via Haskell-Cafe < haskell-cafe@haskell.org>:

...
I wrote:

...
https://hackage.haskell.org/package/toml/maintainers/

Still, maybe it would help if this feature was more prominent?

See also https://github.com/haskell/hackage-server/issues/918

Cheers,

Bertram _______________________________________________ Haskell-Cafe mailing list To (un)subscribe, modify options or view archives go to: http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe Only members subscribed via the mailman list are allowed to post.

...

_______________________________________________ Haskell-Cafe mailing list To (un)subscribe, modify options or view archives go to: http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe Only members subscribed via the mailman list are allowed to post.

amindfv＠mailbox.org

12 Mar 12 Mar

6:19 p.m.

On Fri, Mar 12, 2021 at 05:59:31PM +0100, Henning Thielemann wrote:

...

On Fri, 12 Mar 2021, Brandon Allbery wrote:

...
That depends. Can I in fact, were I looking for a maintainer, find out who to contact about the package? Ideally without much digging.

That's what the Cabal.Maintainer field is for. It is missing in toml, which is bad.

Fixed.

...

_______________________________________________ Haskell-Cafe mailing list To (un)subscribe, modify options or view archives go to: http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe Only members subscribed via the mailman list are allowed to post.

Viktor Dukhovni

4:57 p.m.

...

On Mar 12, 2021, at 2:42 PM, Henning Thielemann wrote:

I don't think there is any need for a public announcment if a package creator hands over maintainership to another developer.

Well, there have been some rather unfortunate transfers of control of widely used packages (in other ecosystems than hackage) to shady operators who made malicious changes. This is more directly a concern for browser plugins, or "apps", but also applies to Python, Ruby, Node and ultimately even Haskell. Supply chain security is a hard problem, and any transparency in changes of control would be great. If release tarballs are digitally signed, and contributors can be expected to not hand over their own keys when transferring control, but rather to arrange for new keys to be authorised to continue to make releases, then such changes of control could be noted on hackage as a change in which key signed a new release. Cautious users might pin the release keys trusted to sign a given dependency, and could then review and approve imports of these if signed by not yet trusted keys. There could even be a role for trusted reviewers (and ideally a means to compensate them for their work). I did mention this is a hard problem... -- Viktor.

Chris Dornan

5:10 p.m.

...

...
I don't think there is any need for a public announcment if a package creator hands over maintainership to another developer.

...

Well, there have been some rather unfortunate transfers of control of widely used packages (in other ecosystems than hackage) to shady operators who made malicious changes. This is more directly a concern for browser plugins, or "apps", but also applies to Python, Ruby, Node and ultimately even Haskell.

Viktor makes some great points, but we do not have any such checks in place at the moment. Currently it is accepted that a package maintainer can get help maintaining a package through whatever means. The original package maintainer can step off at a later time, leaving the new maintainers in charge. At this stage, I think we should stop piling in on Tom -- it does not seem right, at all. Chris On Fri, 12 Mar 2021 at 16:59, Viktor Dukhovni wrote:

...

...
On Mar 12, 2021, at 2:42 PM, Henning Thielemann < lemming@henning-thielemann.de> wrote:

I don't think there is any need for a public announcment if a package creator hands over maintainership to another developer.

Well, there have been some rather unfortunate transfers of control of widely used packages (in other ecosystems than hackage) to shady operators who made malicious changes. This is more directly a concern for browser plugins, or "apps", but also applies to Python, Ruby, Node and ultimately even Haskell.

Supply chain security is a hard problem, and any transparency in changes of control would be great.

If release tarballs are digitally signed, and contributors can be expected to not hand over their own keys when transferring control, but rather to arrange for new keys to be authorised to continue to make releases, then such changes of control could be noted on hackage as a change in which key signed a new release.

Cautious users might pin the release keys trusted to sign a given dependency, and could then review and approve imports of these if signed by not yet trusted keys. There could even be a role for trusted reviewers (and ideally a means to compensate them for their work). I did mention this is a hard problem...

-- Viktor.

_______________________________________________ Haskell-Cafe mailing list To (un)subscribe, modify options or view archives go to: http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe Only members subscribed via the mailman list are allowed to post.

Imants Cekusins

4:57 p.m.

re: maintainer of toml package: https://hackage.haskell.org/packages/search?terms=toml Maintainer: seliopou, TomMurphy https://hackage.haskell.org/package/toml Maintainer: none no repo in https://hackage.haskell.org/package/toml-0.1.3/toml.cabal Let's see how soon the next version is uploaded with maintainer and repo specified. A repo would be nice, wouldn't it?

amindfv＠mailbox.org

6:38 p.m.

On Fri, Mar 12, 2021 at 06:57:59PM +0200, Imants Cekusins wrote:

...

Let's see how soon the next version is uploaded with maintainer and repo specified. A repo would be nice, wouldn't it?

Tbh this type of scrutiny is making me less likely to want to publish unfinished code because it would only open me up to criticism (this code doesn't have feature X, I don't think this code is being worked on fast enough, etc.). I've already said I'll give up the package name if there's a clear consensus from the larger community. A WIP repo might be nice for you but I'm not required to publish anything before I feel it's ready. Tom

Imants Cekusins

7:55 p.m.

Well, a repo with history of the published code is often specified in the .cabal file. This allows for overview of changes between versions. Forks and PRs are also convenient. A few repo hosts also include issue tracker which can also be used to communicate with authors / maintainers. Clarity helps. On Fri 12 Mar 2021, 20:38 amindfv@mailbox.org, wrote:

...

On Fri, Mar 12, 2021 at 06:57:59PM +0200, Imants Cekusins wrote:

...
Let's see how soon the next version is uploaded with maintainer and repo specified. A repo would be nice, wouldn't it?

Tbh this type of scrutiny is making me less likely to want to publish unfinished code because it would only open me up to criticism (this code doesn't have feature X, I don't think this code is being worked on fast enough, etc.). I've already said I'll give up the package name if there's a clear consensus from the larger community. A WIP repo might be nice for you but I'm not required to publish anything before I feel it's ready.

Tom

1579

Age (days ago)

1580

Last active (days ago)

List overview

Download

51 comments

20 participants

participants (20)

amindfv＠mailbox.org
Bertram Felgenhauer
Brandon Allbery
Bryan Richter
Carter Schonwald
Chris Dornan
Dmitrii Kovanikov
Emily Pillmore
erik
Gershom B
Henning Thielemann
Hécate
Imants Cekusins
Ivan Perez
Javran Cheng
Joachim Durchholz
Roman
Sven Panne
Tom Ellis
Viktor Dukhovni