Re: Release note trimming: another modest proposal
On Mon, Aug 6, 2018, 05:57 Tom Lane wrote: > We've been around on this before, I know, but I got annoyed about it > again while waiting around for test builds of the back-branch > documentation. I think that we need some policy about maintaining > back-branch release notes that's not "keep everything, forever". > The release notes are becoming an ever-larger fraction of the docs, > and that's not good for documentation maintenance or for download > bandwidth. As an example, looking at the US-letter PDF version of > the v10 docs, as things stand today: > > Total page count: 3550 > Pages in release notes for 10.x: 41 (1%) > Pages in release notes for older branches: 898 (25%) > Pages in release notes for pre-9.2 branches: 546 (15%) > > I've not measured directly, but it's a reasonable assumption that if > we dropped all the back-branch release notes the documentation build > time would drop about 25%, whichever format you were building. > > I also live in fear of overrunning TeX's hard-wired limits, in the > back branches that depend on a TeX-based PDF toolchain. We've hit > those before and been able to work around them, but I wouldn't count > on doing so again, and I sure don't want to discover that we have a > problem of that sort the day before a release deadline. Trimming the > release notes would definitely give us enough slack to not worry > about that before all those branches are EOL. > > We've discussed trimming the release notes before, and people have > objected on the grounds that they like being able to access ancient > notes from time to time. I'm not unsympathetic to that issue, but > does that access point need to be our daily working documentation? > > Anyway, I'd like to propose a compromise position that I don't think > has been discussed before: let's drop release notes for branches > that were already EOL when a given branch was released. So for > example, 9.3 and before would go away from v12, due out next year. > Working backwards, we'd drop 9.1 and before from v10, giving the 15% > savings in page count that I showed above. A quick measurement says > that would also trim the size of the v10 tarball by about 4%, which > is not a lot maybe but it's noticeable across a lot of downloads. > > It seems to me that this would still provide enough historical > info for just about any ordinary interest. We could discuss ways > of making a complete release-note archive available somewhere, > if "go dig in the git repo" doesn't seem like an adequate answer > for that. > Works for me. Especially with a release note archive available somewhere. > > Thoughts? > > regards, tom lane > >
Re: I'm surprised to see the word master here
On Wed, Oct 2, 2019 at 12:57 PM Erikjan Rijkers wrote: > On 2019-10-02 12:46, Peter Eisentraut wrote: > > On 2019-10-02 10:21, Magnus Hagander wrote: > >> Exactly. Both might be accurate, but one comes with a lot less > >> baggage. > >> > >> I support a search and replace. > >> > >> I think it'll take a bit more than just a simple "sed script to > >> replace", if that's what you mean. But probably not all that much -- > >> but > >> there can certainly be cases where nearby langaugae also has to be > >> changed to make it work properly. But I have a hard time seeing it as > >> being a *huge* undertaking. > > > > I find this proposal to be dubious and unsubstantiated. Do we need to > > get rid of "multimaster", "postmaster"? > > > > IMHO, hat would seem a bad idea. Let's not take the politicising too > far. > > I would say leave it at abolishing 'slave' (as we have already done). > But that raises an important point, which is that if we remove master entirely from the replication lexicon, then I don't see how multi-master makes sense. If consistency is a goal, postmaster still works but there is no alternative to multi-master in common usage. Can I make a suggestion here to help ease that problem: We standardize on "primary" and "replica" but on the first usage of "primary" we have a parenthetical note that "primary" is sometimes called "master" so that terms like multi-master continue to be intuitively intelligible. > > > thanks, > > Erik Rijkers > > > > -- Best Wishes, Chris Travers Efficito: Hosted Accounting and ERP. Robust and Flexible. No vendor lock-in. http://www.efficito.com/learn_more
Re: I'm surprised to see the word master here
On Mon, Oct 7, 2019, 21:51 Bruce Momjian wrote: > On Mon, Oct 7, 2019 at 10:49:54AM +1300, Mike Taves wrote: > > On Sat, 5 Oct 2019 at 10:57, Bruce Momjian wrote: > > > With master/standby-replica-slave, it is clear what multi-master is, > and > > > what master/replica is. If you start using active-active, is it > > > active/replica? The full choices are: ... > > > > There are more choices. Coming from a different corner of computing, > > we have changed these computing resource names to other > > anthropomorphic titles found around office environments: "manager" and > > either "worker" or "agent". With these names, some derived terms are > > "multi-manager" and "standby-replica-worker". > > I think the problem is that "worker" doesn't have the idea that it is a > copy of the primary, which replica and standby kind of do. On the other > hand, worker and slave seem almost identical, and you are right they > don't have the concept of being a copy either. :-( I guess I was > hoping to move to a term that had _copy_ built into the term. > Also some might find the use of the word "worker" to be Capitalist anti-labor propaganda and thus offensive. This road leads to the circular firing squad. Let is try to be reasonably neutral politically. > > -- > Bruce Momjian http://momjian.us > EnterpriseDB http://enterprisedb.com > > + As you are, so once was I. As I am, so you will be. + > + Ancient Roman grave inscription + > > >
