public inbox for [email protected]
help / color / mirror / Atom feedFrom: Jonathan S. Katz <[email protected]>
To: Magnus Hagander <[email protected]>
To: Alvaro Herrera <[email protected]>
Cc: Tom Lane <[email protected]>
Cc: Erik Rijkers <[email protected]>
Cc: PostgreSQL Developers <[email protected]>
Cc: Pg Docs <[email protected]>
Cc: w^3 <[email protected]>
Subject: Re: tickling the lesser contributor's withering ego
Date: Thu, 27 Dec 2018 08:38:24 -0600
Message-ID: <[email protected]> (raw)
In-Reply-To: <CABUevEypQt3DgRE4GvCTHu-bq=L1FLDymJ-foouFj7=i1ZqHLQ@mail.gmail.com>
References: <[email protected]>
<[email protected]>
<CABUevEypQt3DgRE4GvCTHu-bq=L1FLDymJ-foouFj7=i1ZqHLQ@mail.gmail.com>
On 12/27/18 4:53 AM, Magnus Hagander wrote:
>
>
> On Fri, Dec 21, 2018 at 4:17 PM Alvaro Herrera <[email protected]
> <mailto:[email protected]>> wrote:
>
> On 2018-Dec-21, Tom Lane wrote:
>
> > Alvaro Herrera <[email protected]
> <mailto:[email protected]>> writes:
> > > I propose the following patch, which will make those links stable --
> > > then we can add the following links to the contributors page:
> > >
> https://www.postgresql/org/docs/10/release-10.html#RELEASE-10-ACKNOWLEDGEMENTS
> > >
> https://www.postgresql/org/docs/11/release-11.html#RELEASE-11-ACKNOWLEDGEMENTS
> >
> > Seems reasonable, but note the lag time --- unless somebody does
> > something out of the ordinary, those pages won't actually have
> > such tags till after the February minor releases.
>
> Good point. That seems acceptable to me.
>
>
> Good. While it *can* be worked around, it's a PITA and it risks getting
> overwritten by other things, since the normal docs loads are based off
> release tarballs. We can make them off a snapshot tarball, but it's a
> pain :)
>
> Oh, and +1 for stable links like that in general. That would be one good
> step.
Agreed on above points.
>
> Not having considered what to do with, but it could also be interesting
> to teach the loader to read the structured data out of the XML file and
> store it in one of these weird things called a "database". That could be
> used for things like matching on the contributors list and add a little
> per-version badge to which versions they are known to contribute etc.
> That would require us to be quite consistent in the naming of people,
> and also not to have duplicates though, but maybe it can be valuable?
Not to hijack this, but there are some similar(-ish; we can debate
semantics, but it's a similar idea) things mentioned here[1] in
conjunction to the release note trimming. If we are going to go on the
"store stuff in the database" route around additional information the
docs, I'd suggest we tackle the release note trimming as well (and I
volunteer myself for that) as that should have significant impact across
the project (esp. full build time!).
I'm all for highlighting contributors and their work - so perhaps we can
combine both efforts since there might be a common solution to both? :)
(and RE dupes: I also hear that these database things are good tools for
helping to eliminate such things ;-)
Thanks,
Jonathan
[1]
https://www.postgresql.org/message-id/flat/19252.1533509841%40sss.pgh.pa.us
Attachments:
[application/pgp-signature] signature.asc (833B, 2-signature.asc)
download
view thread (8+ messages) latest in thread
reply
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: [email protected]
Cc: [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected]
Subject: Re: tickling the lesser contributor's withering ego
In-Reply-To: <[email protected]>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox