Re: [xz-devel] [PATCH] String to filter and filter to string

[Jigar Kumar]

>> The next alpha release should be coming this year so I
>> don't think it will be as long as you think until it is in a stable
>> release.

> Patches spend years on this mailing list. 5.2.0 release was 7 years ago. 
> There is no reason to think anything is coming soon.

Over 1 month and no closer to being merged. Not a suprise.

Re: [xz-devel] [PATCH] String to filter and filter to string

[Jigar Kumar]

Hi

Is there any progress on this? Jia I see you have recent commits. Why can't you 
commit this yourself?

Jigar

Re: [xz-devel] XZ for Java

[Jigar Kumar]

Progress will not happen until there is new maintainer. XZ for C has sparse 
commit log too. Dennis you are better off waiting until new maintainer happens 
or fork yourself. Submitting patches here has no purpose these days. The 
current maintainer lost interest or doesn't care to maintain anymore. It is sad 
to see for a repo like this.

Re: [xz-devel] XZ for Java

[Jigar Kumar]

> Anyway, I assure you that I know far too well about the problem that
> not much progress has been made. The thought of finding new maintainers
> has existed for a long time too as the current situation is obviously
> bad and sad for the project.
>
> A new XZ Utils stable branch should get released this year with
> threaded decoder etc. and a few alpha/beta releases before that.
> Perhaps the moment after the 5.4.0 release would be a convenient moment
> to make changes in the list of project maintainer(s).

With your current rate, I very doubt to see 5.4.0 release this year. The only 
progress since april has been small changes to test code. You ignore the many 
patches bit rotting away on this mailing list. Right now you choke your repo. 
Why wait until 5.4.0 to change maintainer? Why delay what your repo needs?

Re: [xz-devel] [PATCH] String to filter and filter to string

[Jigar Kumar]

> I chose "+" since it was the most intuitive delimiter that wasn't a
> special character on most shells. If we used ";" or "|" they would
> either have to be escaped or require the command to be in quotation
> marks, which are both annoying to use as a command line argument. If
> you can think of a better character I would be interested to hear, but
> I don't think those are better.

I see. "+" is ok.

> I appreciate the feedback. This will certainly lead to improvements of
> the format. The next alpha release should be coming this year so I
> don't think it will be as long as you think until it is in a stable
> release. The contributors to this project are hobbyists so we can't
> dedicate 40+ hours a week for fast releases of high quality. Thank you
> for your understanding and if you want to help work on anything you
> can always submit a patch :)

Patches spend years on this mailing list. 5.2.0 release was 7 years ago. There 
is no reason to think anything is coming soon.

Re: [xz-devel] [PATCH] String to filter and filter to string

[Jigar Kumar]

Hi

> These patches add lzma_str_to_filters and lzma_filters_to_str to
> liblzma and add a new "-s, --filters" option to xz.

The existing way to add filter chain is confusing so this change will be good. 
I do not think the -s short op is good. --filters as the long op is good no 
need for -s.

> The "=" delimits a filter name from a comma separated list of option
> value pairs. The "=" is optional and only needed if you want to
> override default options. For lzma1 and 2, a short hand for a preset
> can be used: lzma2={preset number}.
>
> The ":" delimits option name from option value.
>
> The "," delimits option value pairs from each other.
>
> The "+" delimits filters from each other.

The "+" is not the best character. What about using ";" or "|"?

> Right now, lzma_filters_to_str will only specify option names and
> values if they are different from the default. This can be changed to
> always display option names and values for all options if this is
> better.

It should show all option names and values. It matches the current output with 
-vv option.

> If anyone has any suggestions for improvements on the
> string format, I am interested to hear them. I consider this patch a
> draft and subject to change from community suggestions. Let me know
> how this can be improved!

I did not test your codes, but if they work then I think the format only needs 
minor adjustments I suggest. Your efforts are good but based on the slow 
release schedule it will unfortunatly be years until the community actually 
gets this quality of life feature.

Jigar