Libelektra: plugins: remove experimental

[markus2330]

There are some candidates for which we could remove the experimental flag om the next release (0.8.21). The candidates are:

• [x] yamlcpp
• [x] camel
• [x] mini
• [x] crypto (@petermax2 any preferences? now or on January?)
• [x] xerces (@e1528532 What do you think?)
• [ ] dini
• [x] directoryvalue

dini/directoryvalue are actually the first time included. Usually we should mark them experimental but this time I am also okay to not have them tagged experimental, in particular considering that we want them to be part of the default storage in the release after the next one (0.8.22).

What do you think?

[e1528532]

Basically the xerces plugin should be fine, although there are some open issues which however do not directly relate to it (e.g. renaming to avoid invalid xml element names -> rename plugin #1400 and the issue with multiple root elements #1451).

I am not sure how much it got used already, i think @tom-wa mentioned some probleme with some xml file he tried in the last meeting, so it would be good if he opens a bug report for it so this can be checked out. Apart from that there is this ini issue #1686.

So the last two things should be checked out before marking it as non-experimental, the things mentioned in the first paragraph do not matter i think they are not directly in the scope of the xerces plugin.

[markus2330]

Thank you for your input! I would suggest to rather keep it experimental if @tom-wa found a new bug (it might be severe).

We should always make at least a quick placeholder issue so that we do not forget to report issues (I did it for example in #1717). I added this as topic for the next meeting.

[petermax2]

The crypto plugin should be fine. We can remove the experimental flag. What about the memleak flag? The leaks are actually caused by the libraries we link to, as far as I can remember.

[markus2330]

The crypto plugin should be fine.

Perfect! Do you have time to fix (redo without german texts) the asciinema for the release notes?

What about the memleak flag? The leaks are actually caused by the libraries we link to, as far as I can remember.

I am afraid we have to keep the memleak flag. A user wants to know if a used plugin has a memleak and not which code causes the memleak.

Do all 3 libs have a memleak? (As reported by valgrind)

[petermax2]

Perfect! Do you have time to fix (redo without german texts) the asciinema for the release notes?

Yes, I will re-do the cast on the weekend.

Do all 3 libs have a memleak? (As reported by valgrind)

If valgrind is correct, then yes, all 3 variants have mem-leaks.

[sanssecours]

Directory Value

I think we should remove the experimental tag, since otherwise the MSR tests for YAJL – which requires directoryvalue – might fail.

Other Plugins

I think the description of the tag experimental:

{"experimental",  -500}, ; not much tested, plugin is in early stage

does not apply to

• camel,
• crypto
• mini,
• xerces, or
• yamlcpp,

. In my opinion we can remove the tag from these plugins.

[markus2330]

Yes, I agree! Let us remove them all. ( @sanssecours can you do this please? Please also check with scripts/update-infos-status if the other status flags of the plugins are consistent and sorted.)

Thank you all for your fast response!

[markus2330]

Above plugins (except of dini) are not experimental anymore. Information about them in the release notes, however, is still missing. Fixing release notes after release is okay, though.