Re: Crediting sponsors in release notes? - Mailing list pgsql-advocacy

Hi!

On Fri, May 13, 2011 at 11:44 AM, Greg Smith <greg@2ndquadrant.com> wrote:
> Selena Deckelmann wrote:
>>
>> I don't think anyone is arguing against the need for visibility. I
>> agree with Bruce that the billboard format isn't a good thing to add
>> to our release notes.
>>
>
> The only person who suggested the release notes as a possible destination
> for this information was Jim when he started the thread.  I argued against
> it too.  I read Bruce's comments to say he didn't like the format I
> suggested no matter where the info went though.

Ah, I see. :)

I found a format I liked yesterday for the Linux kernel, but now I
can't find the link again. :(

But it basically had features with a subheading that was something
along the lines of "contributor" listed under the lead developer or
committer's name.

It was like:

 * Add the pg_describe_object() function (Commits: 1, 2, 3)
 Developer: Alvaro Herrera
 Contributor: Enova Financial

 Returns a description of a database object specified by catalog OID,
object OID and a
 (possibly zero) sub-object ID. This is useful to determine the
identity of an object as
 stored in the pg_depend catalog

(And the commits were linked.)

The key information I'd like is basically what you outlined, Greg.

If we can collect that, we can reformat it later, yeah?

Basically:

Feature
* Commits (list of hashes)
* Developers (with company affiliation, if desired)
* Reviewers (if any)
* Sponsors [optional]
* Detailed description of feature [optional]

People also brought up crediting bug reporters, which we can handle separately.

>> http://wiki.postgresql.org/wiki/Sponsorship/Release_9.1_Docs
>> The formatting isn't perfect, but I only spent about 10 minutes
>> getting it into there.
>
> My experience with pages on the wiki is that they work better if you
> construct from a small page.  Things that start as a big page that needs to
> be distilled down are harder to deal with.  Some of that is perception--that
> it's easier to chew on a little work than face a big document.  There's some
> technical reasons too though, like how locking on the wiki works when two
> people try to do big edits at once.

Sure. :)

> If there's any agreement that the specific format I suggested is a
> reasonable one, the easiest way to do this on the Wiki is to create a
> "Feature Sponsor" template and plug the data into there.  Then we can tweak
> the format later without necessarily even having to touch the data, and once
> the release ships just lock the page down.  I can follow through getting
> that done on the www list, and then we just need to throw out a "call to
> sponsored developers" to add themselves there.  I just don't want to go
> through it all if there are still people who have issues with the whole
> idea.

I don't think people have issues with the whole idea. See above for
information to gather to argue over. :)

Bruce can speak for himself, but my impression was that he didn't like
having something like what you outlined in the Release Notes.

The ultimate format of what you offered is up for question, but I
think the data you'd like to collect is about right.

Let's not start painting the format bikeshed until we have some data
to sort through!

-selena

--
http://chesnok.com