Re: [boost] Reminder: Boost Master branch will close for the 1.65.0 release on Wednesday

Subject: Re: [boost] Reminder: Boost Master branch will close for the 1.65.0 release on Wednesday
From: Stefan Seefeld (stefan_at_[hidden])
Date: 2017-08-02 13:43:54

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/
>", 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/
>"

>> 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.)

>
> 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. 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.

> And personally, I don't like gh-pages approach because it means
> storing auto-generated content in git, even if in a separate branch.

That's a separate discussion, which (surprise !) I'd prefer to have per
project.

    Stefan

-- 
      ...ich hab' noch einen Koffer in Berlin...