2022.03.09 20:04 "Re: [Tiff] Libtiff developers are volunteers!", by Bob Friesenhahn

Agree with your statement, and there might be a way to handle at least the "when is a new release" question.

In the past I worked on a project that had every 2 months a new release. There was no guarantee what was in it, what would be solved etc, but if some patch or functionality appeared in the master-branch, it would be part of the next release.

Depending on what was solved the X.Y.Z number was increased.

If Libtiff could setup a similar workflow and have an (semi) automatic release e.g. every 2,3,4,6,12 months, the "release date" questions would always have a clear answer. The only reason to skip a new release would be that nothing is merged into master.

This is a great idea! Currently there is a lot of manual work to prepare a libtiff release. Much of the manual work is with preparing the release documentation such as adding/updating HTML files. Up until now, the libtiff release tarball has contained source code, documentation, and summary history data so that libtiff history does not need to directly depend on a live source repository. This has been a good plan since it has withstood the test of time.

It has been suggested to replace the hand-edited primitive HTML with ReStructuredText using Spinx (similar to what the Python project uses) with a nice style-sheet. After this, the libtiff documentation would be a lot more attractive.

There is also a need to be able to maintain the libtiff documentation from a single source. For example, we currently have files in nroff "man" format which are used to produce HTML files and nothing does this automatically. It is not clear what the best solution for master formats and document generation is but we know that we want both installable manual pages and html files. If the document generation is able to output other formats, that would be a plus.

One would not need discussions about when the next release is, or what is in it as the above way of working solves both questions in a pragmatic way. (I know in reality it will be more complicated )

thoughts?

The above sounds great to me. This is something that a fresh volunteer (volunteers?) can help with because it is very demanding of time and has only a little to do with the development/maintenance of libtiff source code.

The strategy would be to develop a proposed solution (incrementally), and then rinse-and-repeat until it works flawlessly.

If the release process is fool-proof and as close to pushing a button as possible, then releases will surely be produced more often. In fact, the "button" could be essentially mostly pushed with each code/documentation submission, with a human perodically deciding that all is well and taking the last step to apply a tag, emit source archives, sign the releases, and upload them to distribution servers.

Bob

Bob Friesenhahn
bfriesen@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer, http://www.GraphicsMagick.org/
Public Key, http://www.simplesystems.org/users/bfriesen/public-key.txt