Boost logo

Boost :

Subject: Re: [boost] Reminder: Boost Master branch will close for the 1.65.0 release on Wednesday
From: Andrey Semashev (andrey.semashev_at_[hidden])
Date: 2017-08-02 14:41:10

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 ">", rather than
>>> "") 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
>>> ">"
>>> 5) At the same time, remove the corresponding (now obsoleted) content
>>> from
>> 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).

Boost list run by bdawes at, gregod at, cpdaniel at, john at