On 08/02/17 16:43, Stefan Seefeld via Boost wrote:
On 02.08.2017 04:41, Andrey Semashev via Boost wrote:
On 08/02/17 04:17, Stefan Seefeld via Boost wrote:
You are right, of course. And I did indeed propose a solution in private conversation, a few months ago. It goes somewhat like this:
1) Write a template "index.html" to be used as the "landing page" for all (individual) projects, containing all the essential information, from pointers to docs, issue tracker, github repo, wiki, etc. 2) "Instantiate this template (by filling in some placeholders such as library name, etc., from the respective "meta/libraries.json" file) and add it to the "gh-pages" branches of all repos that don't yet have an "index.html" file. 3) Change the html in the "website" repo to refer to those URLs (served as "http://boostorg.github.io/<project>", rather than "http://boost.org") after validating that all the referenced end-points exist 4) Allow project maintainers to replace (customize) their "index.html" to refer to documentation (etc.) they manage "locally", i.e. generate on "http://boostorg.github.io/<project>" 5) At the same time, remove the corresponding (now obsoleted) content from boost.org
1. How would release-specific release notes be maintained in this setup? E.g. when you need to update release notes after a shipped release.
That's up to the project maintainers. (This and similar problems has been solved so many times that I don't think we need to consider it here, in particular when the focus is on de-centralization.)
I don't see how that can be up to the project maintainers if the website refers to a fixed url in the library space.
2. How would the users see the summary release notes for a Boost release on one page? Having a list of links to library-specific release notes is not good enough.
I don't agree with your "not good enough" assessment.
That is what a user expects to see when he upgrades to a new Boost release. Asking him to follow a dozen links instead is IMO unreasonable.
While it's of course possible to tie individual release notes back into the main website, this would increase coupling, and thus would augment the complexity and maintenance burden.
Right. But you see, this is what the current setup offers. IMO, any replacement has to offer similar services to both users and Boost developers, and probably some benefits on top of that to warrant the need to do anything in the first place. The argument that the new setup would somehow benefit modularization doesn't work because (a) it doesn't benefit users, who are ultimately the ones for whom the modularization is being done; (b) whether it benefits developers is questionable (at least, your proposed approach doesn't look appealing to me); and (c) the current setup doesn't seem to be problematic (not to me, anyway).