jq icon indicating copy to clipboard operation
jq copied to clipboard

About the jq's release process (Was: Is jq is still alive/maintained ?)

Open tst2005 opened this issue 3 years ago • 48 comments

Hello,

jq is a already powerfull enough for most of use. it does not need new release too often but ... There are lot of PR for bugfixes and interesting improvements.

is @stedolan still maintaining jq ? if it is a "dead" project, Am I alone to think about a fork ?

Regards,

tst2005 avatar Apr 26 '21 10:04 tst2005

Also wondering this. It would be a shame if it stopped being developed and maintained. Maintainers, is there anyway to help you out?

carlsmedstad avatar Apr 28 '21 09:04 carlsmedstad

Hey, so I'm still around- the main issue is that I've been super busy with work and dealing with life this last year that it's been especially hard to find the time/energy to devote to jq.

We'd definitely appreciate help- I've got a couple small changes floating around that I need to finish up which should improve some build behaviors (I think I can make the CI builds more reliable- they keep breaking. Should also be able to fix some things around the math functions that got brought up "recently"). I'll also try and dig up that list of things that needed finishing in order to cut the next release and see if I can set up some issues for it and a milestone so that it's clear what needs doing. (Depending on what's left on that, I might just say we should cut a release and schedule myself some time to do it).

Beyond that, I need to go review all the open PRs- I know I've seen some good stuff come through my email- and also try to clean up the issue tracker some.

wtlangford avatar Apr 28 '21 23:04 wtlangford

Thanks for your answers.

@carlsmedstad : IMHO, I don't think it is a shame if @stedolan can not or don't want maintain jq anymore. I prefer saying a big thank for the work already done.

Today I see the stedolan's jq repository has 19.3k stars, 1.1k fork, 121 PR, 574 issues. 121/1100 --> ~10% of forks are PR 574/1100 --> ~50% of forks equal to an issue (bug/ask/feature request/...)

There different solutions to get a projet maintained, :

  • the original author is still here, he can do stuff to transfert the role to another guy/community.
  • the original author is not here. The repository is forked to a new "official/maintained" one, it is difficult to make people create issue/PR on the new repo because all current search result still anwer the original repository.

For now I don't read people answering "I forked and I can maintain jq", @wtlangford you are the closest one but you already told us you are busy.

I'm in the same case. I want a maintained jq, I can contribute but I don't have enough time to be the only one to maintain jq.

When nobody has the time to maintain the projet, we can try to make a github "organisation" like "jq-community" or "jq-maintainers". It imply to work together (it is not always easy).

My personnal goal and possible contribution is targeted on jq builtin

I'm currently using jq 1.5, the only interesting thing I take from jq 1.6 is some builtin (made in jq language it self) then I took them and load on jq 1.5 before using them.

The most work I'm doing around jq is provide a set of usefull functions/samples for my colleages and myself. Some of them could be jq builtin, some other not. jq is powerfull but not always easy to use.

I want more sample in documentation for builtin and more wiki cookbook) for functions that is not built in but interesting enough to exist.

For me, there are a few number of missing feature in jq. The only main one for me is the ability to check if a function is already defined or not. For example: It could be usefull to be able to define a math pow function (made in jq language), only if a "C native" pow not already available.

tst2005 avatar Apr 29 '21 09:04 tst2005

I would like to help maintaining this project if you could invite me as a collaborator. Maybe @pkoppstein would be willing to help, too. I have already submitted some pull request, including the fix for the CI (#2141, #2193). Based on my experience of gojq, I believe I have throughout knowledge of jq filters. But I'm afraid there are many difficulties in this project though; changing the behaviors will likely to break some scripts in the world, even if it is likely broken behaviors (like leaf_paths misjudging falcy values #1163 and index returning bytes offsets #1430). But still I can help reviewing document fixes or closing questions.

itchyny avatar Apr 29 '21 11:04 itchyny

@wtlangford Fully understand that, really appreciate the work you do. I'm not too familiar with the project yet but I'll try to get to it this weekend and see where I could help out.

@tst2005 Sorry, I did not intend to come off as negative or demanding. I just wanted to get across that I appreciate the project and would like to help.

carlsmedstad avatar Apr 29 '21 15:04 carlsmedstad

@wtlangford Thanks for all hard work. Im also willing to help out with review, documenting, testing and whatnot

wader avatar Apr 29 '21 15:04 wader

I create a https://github.com/jqmaintainers organisation, @wader @carlsmedstad @itchyny @wtlangford I invited you all to join. EDIT: I also invited @leonid-s-usov @nicowilliams @pkoppstein, any help is welcome ;)

tst2005 avatar Apr 30 '21 11:04 tst2005

Hi!

I feel bad that at some point I fell out of the work that I've started on a couple of core developments here. Back then I had some spare period between jobs but since I've entered my current position I haven't been having any spare time/brain to continue working on this.

I am very sad to see how this amazing project is struggling currently and I would encourage @nicowilliams and @wtlangford to seriously consider picking a responsible maintainer who will be able to put the required effort into moving this forward.

Personally, I am still planning to find some time to finalize my work on a very promising feature that Nico has started. It is going to open the way to extending JQ with custom filters and producers, like fetching stuff from APIs, or running queries against DBs from within the jq script.

leonid-s-usov avatar Apr 30 '21 12:04 leonid-s-usov

That maintenance is landing on one person who may or may not actually have the time because they have other obligations such as a day job is precisely the problem. Making a GH organization and seeing to it that we have enough people who can actually do the work would go a very long way in the right direction.

davidfetter avatar Apr 30 '21 18:04 davidfetter

@tst2005 - Some thoughts in response to your post:

  1. jq has had pow/2 since 1.5.

  2. Since the (official) Cookbook has become a collection of short essays rather than a "library" of ready-to-go functions, one thought would be to create a new page on the wiki for code snippets. Perhaps "library" or "snippets" or "supplemental builtins" would be a suitable title?

  3. There are currently 475 jq entries (mostly worked examples) at rosettacode.org (http://rosettacode.org/wiki/Category:Jq).

FractalTree

pkoppstein avatar Apr 30 '21 20:04 pkoppstein

Decision such as migrating to an organization should happen after deliberation of current maintainers.

itchyny avatar Apr 30 '21 23:04 itchyny

@pkoppstein

1. jq has had pow/2 since 1.5.

I know it is was just a simple example. It can be use to make compat from 1.5 to 1.6 for sql-like function.

2. Since the (official) Cookbook has become a collection of short essays rather than a "library" of ready-to-go functions, one thought would be to create a new page on the wiki for code snippets.  Perhaps "library" or "snippets" or "supplemental builtins" would be a suitable title?

For me there are 3 kind of functions:

  • very usefull : must be included (embedded as built-in)
  • usefull : we hesitate to put it as built-in. then put them in a maintained extended.jq file, easily loadable/usable
  • misc : there are stuff that can be usefull but in very limited case, it can be placed in cookbook.
3. There are currently 475 jq entries (mostly worked examples) at rosettacode.org (http://rosettacode.org/wiki/Category:Jq).

I'm not sure to understand. What you wanna do with that ?

tst2005 avatar May 01 '21 16:05 tst2005

@itchyny

Decision such as migrating to an organization should happen after deliberation of current maintainers.

He didn't react/commit for years. I supposed he does care of jq anymore. I will be happy if he answer us !

tst2005 avatar May 01 '21 16:05 tst2005

@itchyny

Decision such as migrating to an organization should happen after deliberation of current maintainers.

He didn't react/commit for years. I supposed he does care of jq anymore. I will be happy if he answer us !

So these days, @nicowilliams and I are the two maintainers. I'll chat with him about it and see what he thinks

For me, there are a few number of missing feature in jq. The only main one for me is the ability to check if a function is already defined or not.

While slightly off-topic for this thread, I do want to point out that this isn't really possible, due to how jq's internal linker works. When we're parsing your code, we just note that you referred to a symbol by name. Later, we do a pass through to try and link your symbols to already defined things. If we can't find a symbol by that name, linking fails. So there's not really a way to do that, without introducing some kind of preprocessor, and that's not something I'm particularly enamored of.

It can be use to make compat from 1.5 to 1.6 for sql-like function.

So one of the nice things about jq is that most of our standard library is defined as jq code (https://github.com/stedolan/jq/blob/master/src/builtin.jq). So as long as it doesn't actually depend on a new language feature, you can just copy over the needed library functions.

That said, per my comments earlier, I'm going to spend some time today doing some cleaning/organizing of issues/PRs so that we can see what's left before a 1.7 release.

wtlangford avatar May 01 '21 16:05 wtlangford

@tst2005 -

  1. I mentioned rosettacode.org because you wrote:

I want more sample in documentation for builtin and more wiki cookbook) for functions that is not built in but interesting enough to exist.

  1. Regarding builtin.jq vs extended.jq vs misc.jq - it takes quite a lot of joint discussion and time before anything new makes its way into builtin.jq, and whether an extended.jq will ever make it into the official distribution has not yet even been discussed to my knowledge, so it seems to me that one or perhaps two new pages on the wiki would be helpful for experimentation and discussion, as well as perhaps being quite useful.

  2. Regarding your comment:

He didn't react/commit for years.

You are perhaps referring to the original creator of jq, but there have been other official maintainers, and of course at least one of them (thank you @wtlangford!) is participating in this thread.

pkoppstein avatar May 01 '21 17:05 pkoppstein

Regarding builtin.jq vs extended.jq vs misc.jq - it takes quite a lot of joint discussion and time before anything new makes its way into builtin.jq, and whether an extended.jq will ever make it into the official distribution has not yet even been discussed to my knowledge, so it seems to me that one or perhaps two new pages on the wiki would be helpful for experimentation and discussion, as well as perhaps being quite useful.

We have actually discussed it some, but we're not sure how we want to handle it- anything like that would be a breaking change for a lot of existing scripts, and that's something we'd like to avoid. The main reason jq-1.6 is so much slower than 1.5 is due to the sheer number of builtins we added to it and the cost that incurs at load-time. Splitting less-commonly needed builtins out into builtin modules would go a long way towards helping (as we wouldn't load those modules unless you ask for them).

But, as I said- that's going to be breaking behavior and I'm hesitant to commit to it. Beyond that, we had a great contribution back in 2019 (yes, I know our release schedule is slow) that significantly improved startup times back to approximately the performance of jq-1.5, so it's a bit less pressing to my mind.

wtlangford avatar May 01 '21 17:05 wtlangford

That maintenance is landing on one person who may or may not actually have the time because they have other obligations such as a day job is precisely the problem. Making a GH organization and seeing to it that we have enough people who can actually do the work would go a very long way in the right direction.

This is a solid point, it does not mean to blame any one individual just a fact about the nature of things in open source, people move on, lose interest, life happens and have (real) morning jobs. An organization with multiple entities makes much sense for project like jq to evolve. Lets face it, it is simply not one individual's job to maintain this huge popular project at this point.

kasperk81 avatar Jul 24 '21 21:07 kasperk81

Eventually all great projects outgrow their original maintainers (hello, Linux). I definitely would encourage whomever still owns this to delegate and allow the community to grow.

I could see a whole community with several branches springing up. I, for one, would love to see a whole repo dedicated to add-on functions that can be installed.

Please consider growing the community and releasing soon

chb0github avatar Jul 27 '21 15:07 chb0github

Can I second those who ask for a new release from the new maintainers? jq has had optional else clause in if statement since 4f6045a in Feb 2020. Since then it doesn't appear in any release. It's pretty strange that such a useful feature is locked away in the master branch where the people who install from package repository can't use it.

psacawa avatar Jul 30 '21 22:07 psacawa

To the owner of this repo: If you simply don't have the time to even delegate, then donate it to something like the apache foundation or the eclipse foundation, that has a great record of running open source projects

Is the owner even still alive? @stedolan - he hasn't made a single comment on this thread

chb0github avatar Jul 30 '21 22:07 chb0github

@wtlangford Any updates on doing a release?

cheister avatar Aug 29 '21 21:08 cheister

He's dead. We need a fork for someone who can maintain it

chb0github avatar Aug 30 '21 14:08 chb0github

This comment is a rant; accept my apologies and skip it.

@tst2005 @chb0github

Fork it then. This was a complicated project before the portability concerns and the massive adoption. It's a programming language that most of its users don't know is a programming language. It's a functional shell-oriented streaming DSL used by people who write AWS docs and people who think Python is bloat. Its maintenance requirements are unique. Anyone who's capable of wrangling libjq is also capable of making a quarter million a year bumping the version control on some embedded firmware.

I'm on record begging for a new release but if you look at the project history the schedule isn't weird and the build isn't expensive. Emailing everyone subscribed to this repo the same entitled comments over and over does not make anything happen faster. There are some tantalizing features in development but I, for one, would rather see the scope protected than the growth rate explode.

@wtlangford Sorry for contributing to the trash fire

vintnes avatar Aug 30 '21 15:08 vintnes

I depart. Clearly nothing productive here.

chb0github avatar Aug 30 '21 15:08 chb0github

For a more productive comment...

@wtlangford I supposed you are little busy and do what you can with the free time you have (like most of us!)

1. the release process

Can you consider to make Release candidate ? jq 1.7rc1, 1.7rc2, 1.7rc3 ... before the final jq 1.7 release ? It could be a way to get more feed back about feature, benchmark, etc. If you don't have time, you should maybe delegate the release candidate to others peoples. and keep the final release for your own. You probably be the one to be able to make a clean official release, but we can try to make some release candidate (or "beta" ?) to help you to move to the next release and test what it should be included or not.

2. multiple version support

I'm using jq over the debian package distribution currently I'm using jq 1.5 I'm loading some interesting jq 1.6 built-in function when I need it. I'm not sure but I read somebody told jq 1.6 is less performant than jq 1.5 If it's true, how to deal with this ? Can we consider to maintain multiple branches ? and make backports release, include recent features in an older version My personnal need should only be a jq 1.5 with the jq 1.6 built-in, that can be named jq 1.5.1 or jq 1.5.0+bpo1 ... I just launch the idea. I'm don't know if it is a really good way to do.

Regards,

tst2005 avatar Aug 31 '21 09:08 tst2005

I really liked the old title and intent of this issue, since it was speaking to what most subscribers of this issue are interested in. For various reasons, jq is a unique and useful tool in this space available across many platforms, which is why I think it deserves dedicated maintainers (preferably under a GitHub org rather than individual user). For sure, we can talk about releases and versioning, once maintainership story is settled down (that is a separate issue).

kasperk81 avatar Sep 01 '21 05:09 kasperk81

@tst2005 jq 1.6 is drastically less performant. See #2069. A fix is in master for a long time #1817.

1.7rc.1 is a great idea!

diafour avatar Oct 07 '21 08:10 diafour

Any update?

eitsupi avatar Jan 21 '22 10:01 eitsupi

Hello?

Paszymaja avatar Mar 23 '22 09:03 Paszymaja

Maybe in 1 month for the anniversary date of the issue ? :D

tst2005 avatar Mar 24 '22 15:03 tst2005

happy issue birthday ! https://github.com/jqmaintainers/jq updated, I consider again seriously to fork jq...

tst2005 avatar Apr 26 '22 10:04 tst2005

yes, lets do that: https://github.com/jqmaintainers/jq/issues/1

kasperk81 avatar Apr 26 '22 10:04 kasperk81

yes please - this is becoming embarrassing would it be possible to include the fork in Homebrew / DEB / RPM indexes?

ceresdarkmatter avatar Apr 26 '22 11:04 ceresdarkmatter

yes on fork... This is too good of a project to be abandoned like this. But if you're seriously considering a fork, please make the https://github.com/jqmaintainers members public, I don't think we want another one-man-show as a fork, and visibility into who manages things is important for getting approval/adoption. Also consider spreading the responsibility so at least 2-3 people are owning that org.

reegnz avatar Apr 28 '22 09:04 reegnz

@ceresdarkmatter I think it's possible to replace jq with the fork and include it in homebrew/ubuntu/fedora/arch/etc., but first you need a convincing argument that this is not a hostile fork, but a necessary one (eg. original got abandoned). This github issue is definitely a good case for the abandonment argument. Also there has been talk about breaking changes: I think that would be unacceptable for any of those indexes.

reegnz avatar Apr 28 '22 10:04 reegnz

I created the https://github.com/jqmaintainers (the 30 april 2021) the goal was to break the "one-man project" to move it to many.

I drop the jqmaintainers idea quickly because I read https://github.com/stedolan/jq/issues/2305#issuecomment-830660167 at this moment jq seemed to have 2 maintainers. I had good hope for a new release!

Like many of us, I make lot of things and don't have so many time to maintain jq. if @wtlangford and @nicowilliams don't have enough time to maintan jq I will not blame them!

I'm also a busy man, I will don't have lot of time to maintain jq, but I think i will be able to do more than what is done since the last year : nothing ?. After 1 year of wait, I think it is time to find a better solution.

@reegnz I'm totally agree with you. It is definitively not a hostile fork : I'm trying to find a solution.

@reegnz the current members are @pkoppstein and @wader . I invited 7 peoples in 2021 (chose from people that make answer to this issue) 2 of them join the organisation. i did not realized that it is not public: it seems a github per-people choice. I did not find the way to put them public. I only change my own setting.

tst2005 avatar Apr 28 '22 10:04 tst2005

Maybe, it would be better to add more collaborators than just @wtlangford and @nicowilliams? For instance, @itchyny has several open PRs, some of them fixing major bugs, like this one: https://github.com/stedolan/jq/pull/2133. He seems to be pretty active with his gojq and has a pretty expressive self-description in his profile :-)

vmgolovin avatar May 09 '22 20:05 vmgolovin

@vmgolovin I'm agree without. I already try to group all "motivated" peoples: 3 joined, 5 miss the invitaton. I just relaunched all expired invitation for :

  • @itchyny
  • @wtlangford
  • @carlsmedstad
  • @nicowilliams
  • @leonid-s-usov

Feel free to join ;)

tst2005 avatar May 10 '22 08:05 tst2005

I think @itchyny has shown lots of motivation and knowledge, so he would get my vote if he would agree to lead. I'm also happy to help out with various things.

wader avatar May 10 '22 12:05 wader

I also think that @itchyny would be a great leader for jq. He has uncovered a number of bugs in my jq reimplementation, jaq, and I'm sad to see that his pull requests to jq that fixed serious bugs were never integrated.

01mf02 avatar Jul 15 '22 14:07 01mf02

I'm new here, so please forgive the question.

What needs to happen now for this community to successfully take over maintaining jq? I see some potential for resolution, so I'm not sure what this community is waiting for.

Are things happening, but slowly, because of holidays and busy times? or are things stalled because the next steps aren't clear?

Thank you.

jbrains avatar Aug 30 '22 15:08 jbrains

you are assisting to the defintion of "open source". you believe it is descentralized, but in reality it is not. sounds like another bell for me

So far I have 1 reaction of frustration. Is there more?

jbrains avatar Aug 31 '22 13:08 jbrains