Thread: Crediting sponsors in release notes?
We did a read-through of the 9.1 beta release notes in the AustinPUG meeting last night, and it struck me that a number
ofthose items were actually sponsored by Enova. I thought I'd asked about this before, but I'm not finding it in the
archives.What do people think about mentioning sponsors along with patch contributors, something like "(Tom Lane,
sponsoredby Red Hat)" where now it just says "(Tom Lane)"? (Not saying Tom/RH are looking for this, he's just a
convenientexample).
I think there's a couple benefits to mentioning sponsorship:
- It provides added legitimacy to the project *in the eyes of businesses* when they see development being funded by
otherbusinesses
- It raises awareness that businesses *can* fund development of features/fixes
- It recognizes those who have contributed to development
I can think of a few cons as well...
- Corporate sponsorship could worry some people about the project being controlled by companies
I don't think this would be much of an issue unless prolific contributors (ie: Tom) started crediting their
employers.I suspect that most major contributors don't really care about this since nothing's been said before now, but
maybeI'm wrong.
- It does add some clutter to the release notes, though I don't think it would really be that bad
What do others think?
Disclosure: I work for Enova, and we would benefit from our sponsorship appearing in the release notes.
--
Jim "Decibel!" Nasby jnasby@EnovaFinancial.com
Primary: 512-579-9024 Backup: 512-569-9461
On 05/12/2011 01:25 PM, Nasby, Jim wrote: > We did a read-through of the 9.1 beta release notes in the AustinPUG meeting last night, and it struck me that a numberof those items were actually sponsored by Enova. I thought I'd asked about this before, but I'm not finding it in thearchives. What do people think about mentioning sponsors along with patch contributors, something like "(Tom Lane, sponsoredby Red Hat)" where now it just says "(Tom Lane)"? (Not saying Tom/RH are looking for this, he's just a convenientexample). > > I think there's a couple benefits to mentioning sponsorship: > > - It provides added legitimacy to the project *in the eyes of businesses* when they see development being funded by otherbusinesses > - It raises awareness that businesses *can* fund development of features/fixes > - It recognizes those who have contributed to development > > I can think of a few cons as well... > > - Corporate sponsorship could worry some people about the project being controlled by companies > I don't think this would be much of an issue unless prolific contributors (ie: Tom) started crediting their employers.I suspect that most major contributors don't really care about this since nothing's been said before now, but maybeI'm wrong. > > - It does add some clutter to the release notes, though I don't think it would really be that bad > > What do others think? > > Disclosure: I work for Enova, and we would benefit from our sponsorship appearing in the release notes. > -- > Jim "Decibel!" Nasby jnasby@EnovaFinancial.com > Primary: 512-579-9024 Backup: 512-569-9461 > I think it might be difficult to implement effectively. I am not against the idea but, do we say: Alvaro Herrera, Command Prompt, paid for by Enova Financial ? Sincerely, Joshua D. Drake -- Command Prompt, Inc. - http://www.commandprompt.com/ PostgreSQL Support, Training, Professional Services and Development The PostgreSQL Conference - http://www.postgresqlconference.org/ @cmdpromptinc - @postgresconf - 509-416-6579
On Thu, May 12, 2011 at 9:25 PM, Nasby, Jim <JNasby@enovafinancial.com> wrote: > What do others think? I think it would be good to see who pays and who doesn't. Most of our contributions would read "Paid for by 2ndQuadrant", not all though. I'd have no problem mentioning the sponsors and I think they would like it also. In one case, we are actually contractually obliged to explain the sponsorship, though we have no easy means of doing so. The usual route for this is the sponsors page, which needs to be updated to reflect events in last 3 years. -- Simon Riggs http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services
Hi! On Thu, May 12, 2011 at 1:25 PM, Nasby, Jim <JNasby@enovafinancial.com> wrote: > We did a read-through of the 9.1 beta release notes in the AustinPUG meeting last night, and it struck me that a numberof those items were actually sponsored by Enova. I thought I'd asked about this before, but I'm not finding it in thearchives. What do people think about mentioning sponsors along with patch contributors, something like "(Tom Lane, sponsoredby Red Hat)" where now it just says "(Tom Lane)"? (Not saying Tom/RH are looking for this, he's just a convenientexample). > > I think there's a couple benefits to mentioning sponsorship: > > - It provides added legitimacy to the project *in the eyes of businesses* when they see development being funded by otherbusinesses > - It raises awareness that businesses *can* fund development of features/fixes > - It recognizes those who have contributed to development > > I can think of a few cons as well... > > - Corporate sponsorship could worry some people about the project being controlled by companies > I don't think this would be much of an issue unless prolific contributors (ie: Tom) started crediting their employers.I suspect that most major contributors don't really care about this since nothing's been said before now, but maybeI'm wrong. > > - It does add some clutter to the release notes, though I don't think it would really be that bad > > What do others think? The overhead of tracking who sponsored what on a feature-by-feature basis in release notes seems beyond what volunteers can be expected to keep track of. I also wouldn't want to have developer time spent on resolving conflicts in release notes about who sponsored what. Individuals and companies are free to publicize this on their own, and I would love to see companies taking release notes, and writing their own press releases that detail the features that their company paid for. What we could do at a project level is publish a press release that details the companies that sponsored features in the last release. If we could get cooperation and help collecting the information from the companies involved, I think this would be a very nice addition to the press packets that are created for major releases. I'd say at least 10 companies need to document this for it to be worth the effort involved in collecting and distributing the information. -selena -- http://chesnok.com
On May 12, 2011, at 4:23 PM, Selena Deckelmann wrote: > The overhead of tracking who sponsored what on a feature-by-feature > basis in release notes seems beyond what volunteers can be expected to > keep track of. I also wouldn't want to have developer time spent on > resolving conflicts in release notes about who sponsored what. I don't think the tracking would be that burdensome as long as people are using good submit messages. For example, searchingthe commit log for "Enova" would show you everything we sponsored through Command Prompt, because I know Alvarois good about putting that information in there. > What we could do at a project level is publish a press release that > details the companies that sponsored features in the last release. If > we could get cooperation and help collecting the information from the > companies involved, I think this would be a very nice addition to the > press packets that are created for major releases. Also a good idea! If we see how many companies show up in the release notes, then we'd know if it'd be worth the effort.:) -- Jim "Decibel!" Nasby jnasby@EnovaFinancial.com Primary: 512-579-9024 Backup: 512-569-9461
Jim, All: I don't think the release notes are the right place for this. However, the Press Kit would be perfect. However, as someone who puts together the information, most of the time I don't *know* who sponsored anything. So I don't know how I would find this out without a huge time commitment. -- Josh Berkus PostgreSQL Experts Inc. http://pgexperts.com
Hi! On Thu, May 12, 2011 at 2:30 PM, Nasby, Jim <JNasby@enovafinancial.com> wrote: > On May 12, 2011, at 4:23 PM, Selena Deckelmann wrote: >> The overhead of tracking who sponsored what on a feature-by-feature >> basis in release notes seems beyond what volunteers can be expected to >> keep track of. I also wouldn't want to have developer time spent on >> resolving conflicts in release notes about who sponsored what. > > I don't think the tracking would be that burdensome as long as people are using good submit messages. For example, searchingthe commit log for "Enova" would show you everything we sponsored through Command Prompt, because I know Alvarois good about putting that information in there. Bruce and Tom are typically who produce the release notes. So they're in the best position to respond to how much time this would take to collect. I've spent some time collecting information about contributors based on names that are mentioned in commit messages. It is *not* trivial. >> What we could do at a project level is publish a press release that >> details the companies that sponsored features in the last release. If >> we could get cooperation and help collecting the information from the >> companies involved, I think this would be a very nice addition to the >> press packets that are created for major releases. > > Also a good idea! If we see how many companies show up in the release notes, then we'd know if it'd be worth the effort.:) I haven't really looked for company names in the commit log in the past, to be honest. And I am not convinced that the release notes are the right place for this information. For the moment, it seems like administrative overhead that developers don't need. Companies that are interested need to take the release notes, annotate them somehow (links to commits would probably be the best way), and then we can add information about it to the press kit. I think it's a great idea to credit the companies that are supporting the project. I just don't want to introduce another task in the commit or the release process before we have a good reason to. Would you be willing to spend some time collecting information about it? -selena -- http://chesnok.com
On May 12, 2011, at 4:48 PM, Selena Deckelmann wrote: > And I am not convinced that the release notes are > the right place for this information. Before we start worrying about time and effort, let's figure out the answer to that first. Related to that, the thought also occurred to me that it would be nice to also credit bug reporters in the release notes(again, assuming that this doesn't produce too much extra clutter). -- Jim "Decibel!" Nasby jnasby@EnovaFinancial.com Primary: 512-579-9024 Backup: 512-569-9461
> Related to that, the thought also occurred to me that it would be nice to also credit bug reporters in the release notes(again, assuming that this doesn't produce too much extra clutter). And reviewers. That, however, can be a list at the bottom of the release notes. -- Josh Berkus PostgreSQL Experts Inc. http://pgexperts.com
IMHO: >>> The overhead of tracking who sponsored what on a feature-by-feature >>> basis in release notes seems beyond what volunteers can be expected to >>> keep track of. I also wouldn't want to have developer time spent on >>> resolving conflicts in release notes about who sponsored what. > I think it's a great idea to credit the companies that are supporting > the project. I just don't want to introduce another task in the commit > or the release process before we have a good reason to. > > Would you be willing to spend some time collecting information about it? Actually, to me (And i guess it's pretty obvious), decide now to collect this information (Assuming that what's going to be taken into account are the commit messages), besides being a huge task, adds the need to check the logs periodically to update such list (So for the next release there's a starting point to re-update). To me this means, as stated in previous messages "Spend developer/reviewer time to check who did what" and the respective discussions. And also, there are companies/persons who contribute with some other things than code (Docs, proofreading, Translations?).. are those to be left out of the scope? It would be great for companies, to have their names oficially included in a release note. but including most, doesn't mean including them all. Probably some of those not included, will call for attention, leading to possible misunderstandings -- Atentamente Santiago Zarate Consultoria de Software +(58) 416 911 3678 santiago@zarate.net.ve «Dar un nuevo paso, articular una nueva palabra, es lo que la gente mas teme.» - Fyodor Mikhaylovich Dostoyevsky
On 12/05/2011 23:06, Simon Riggs wrote: > On Thu, May 12, 2011 at 9:25 PM, Nasby, Jim<JNasby@enovafinancial.com> wrote: > >> What do others think? > > I think it would be good to see who pays and who doesn't. > > Most of our contributions would read "Paid for by 2ndQuadrant", not > all though. I'd have no problem mentioning the sponsors and I think > they would like it also. In one case, we are actually contractually > obliged to explain the sponsorship, though we have no easy means of > doing so. > > The usual route for this is the sponsors page, which needs to be > updated to reflect events in last 3 years. +1
Hi! On Thu, May 12, 2011 at 2:56 PM, Nasby, Jim <JNasby@enovafinancial.com> wrote: > Related to that, the thought also occurred to me that it would be nice to also credit bug reporters in the release notes(again, assuming that this doesn't produce too much extra clutter). Tom tends to mention the bug numbers and a name in the commit message. I imagine others do as well. I don't think that every bugfix is reported in the release notes, but I could be wrong about that. Someone could try to pull them out of the commit messages and report back how easy/hard that was. Tom/Robert wrote a script to parse git messages in a reasonable way (grouping the same commit message across different major versions). -selena -- http://chesnok.com
Joshua D. Drake wrote: > I think it might be difficult to implement effectively. I am not > against the idea but, do we say: > Alvaro Herrera, Command Prompt, paid for by Enova Financial Some of our features have the same sort of issue. Three things to consider here: 1) How does the data get collected 2) What does the output from this process look like 3) Where does it go Collection: the idea of having someone troll the commit logs for this stuff seems forever impractical to me. Is there anyone involved who wants credit for sponsoring a feature who *isn't* willing to do that manually? This could easily be a manual process, where the developers of the feature push the data to, say, the wiki or via e-mail. Committers have enough to do; if a feature with your name on it goes in, and your sponsor wants to be credited, it should be your job to e-mail/post the link to the commit. It should be a relatively quick pass through per release to collect the data if you require the submitter to get it right, and anybody who can finish a feature can do that. As Simon already mentioned, I think many people who develop sponsored features are doing all this tracking anyway--I know I can tell you exactly where the commits for everything sponsored I've ever done are at, 'cause I wrote them all down as part of notifying the sponsor. More on this below. Output: here's three from 9.1 I think I know the history of to demonstrate what format this might appear in. Bits in [] would be hyperlinks: Sponsor - Feature [commit] - Developer * Enova Financial: Add the pg_describe_object() function [http://archives.postgresql.org/pgsql-committers/2010-11/msg00177.php] (Alvaro Herrera, Command Prompt) * 2ndQuadrant Ltd, NTT Open Source Japan: Efficient transaction-controlled synchronous replication [http://archives.postgresql.org/pgsql-committers/2011-03/msg00056.php] (Simon Riggs, 2ndQuadrant Ltd; Fujii Masao, NTT Open Source Japan) * EnterpriseDB: Support unlogged tables. [http://archives.postgresql.org/pgsql-committers/2010-12/msg00235.php] (Robert Haas, EnterpriseDB) Apologies to Robert if he actually did this all on his time and I'm mis-representing who paid for it. That actually highlights the difference between the data that shows up in the commit logs from what would go onto a sponsor credit page though. The only authoritative source for "who sponsored this feature" is the developer who submitted it. You have this push this work toward them, they're the only ones who have the info anyway. And they're the most likely people to do it--again, they're probably already keeping track of it for business reasons if they care enough to want to go on the page. (The reviewer data might go onto here, too, but I think that's probably not appropriate though. The sponsor and the reviewer may have nothing to do with one another and not want to be associated) Publication: once you see the format it really needs to go in, this is too heavy for the release notes. Don't distract the poor DBA who is trying to read through them to see what's been fixed with this release, they don't care about any of this. That's a technical document. Make a sponsored feature page on the web site somewhere, publish updates in something like the above format before the release goes out, and make sure it's highlighted in the PR around the release. I don't see this as a replacement for the main sponsors page, which includes sponsorship for a lot more than just features. -- Greg Smith 2ndQuadrant US greg@2ndQuadrant.com Baltimore, MD PostgreSQL Training, Services, and 24x7 Support www.2ndQuadrant.us
Em 12-05-2011 20:53, Greg Smith escreveu: > The only authoritative > source for "who sponsored this feature" is the developer who submitted > it. > +1. IMHO the appropriate place to put such information is CF. Someone could argue that not all patches go through the process but, in these cases, they are not generally sponsored ones. It is easy to query the database and list feature, developer, and sponsor. So once a year, someone could get the list and update the website. -- Euler Taveira de Oliveira - Timbira http://www.timbira.com.br/ PostgreSQL: Consultoria, Desenvolvimento, Suporte 24x7 e Treinamento
Selena Deckelmann wrote: > Hi! > > On Thu, May 12, 2011 at 2:30 PM, Nasby, Jim <JNasby@enovafinancial.com> wrote: > > On May 12, 2011, at 4:23 PM, Selena Deckelmann wrote: > >> The overhead of tracking who sponsored what on a feature-by-feature > >> basis in release notes seems beyond what volunteers can be expected to > >> keep track of. I also wouldn't want to have developer time spent on > >> resolving conflicts in release notes about who sponsored what. > > > > I don't think the tracking would be that burdensome as long as people are using good submit messages. For example, searchingthe commit log for "Enova" would show you everything we sponsored through Command Prompt, because I know Alvarois good about putting that information in there. > > Bruce and Tom are typically who produce the release notes. So they're > in the best position to respond to how much time this would take to > collect. I am sure I could collect the information. The big question for me is whether we _want_ such information in the release notes. The release notes, for me, is for people to read about the release changes, and give a small amount of credit to the author, and indicate who is mostly responsible for the features, in case it has problems. I think adding sponsors to the release notes is going to make the release notes look like a billboard, and I am not in favor of this. Obviously we don't even care to update the web site about sponsorships, so why put in everyone's face in the release notes when we don't even do the minimal of updating our own web site with this information. I agree press releases are the natural place for this and I support more activity in that area. -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. +
Greg Smith wrote: > Output: here's three from 9.1 I think I know the history of to > demonstrate what format this might appear in. Bits in [] would be > hyperlinks: > > Sponsor - Feature [commit] - Developer > * Enova Financial: Add the pg_describe_object() function > [http://archives.postgresql.org/pgsql-committers/2010-11/msg00177.php] > (Alvaro Herrera, Command Prompt) > * 2ndQuadrant Ltd, NTT Open Source Japan: Efficient > transaction-controlled synchronous replication > [http://archives.postgresql.org/pgsql-committers/2011-03/msg00056.php] > (Simon Riggs, 2ndQuadrant Ltd; Fujii Masao, NTT Open Source Japan) > * EnterpriseDB: Support unlogged tables. > [http://archives.postgresql.org/pgsql-committers/2010-12/msg00235.php] > (Robert Haas, EnterpriseDB) The above sure looks like a billboard to me, as I stated in an earlier email. :-( It feels like we are naming sports stadiums after companies, but instead it is PG features. It also feels like a non-profit building where everything donated has a little brass plack nailed on it. :-( -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. +
bruce wrote:
> I am sure I could collect the information. The big question for me is
> whether we _want_ such information in the release notes. The release
> notes, for me, is for people to read about the release changes, and give
> a small amount of credit to the author, and indicate who is mostly
> responsible for the features, in case it has problems.
>
> I think adding sponsors to the release notes is going to make the
> release notes look like a billboard, and I am not in favor of this.
>
> Obviously we don't even care to update the web site about sponsorships,
> so why put in everyone's face in the release notes when we don't even do
> the minimal of updating our own web site with this information.
>
> I agree press releases are the natural place for this and I support more
> activity in that area.
Let me add that I often mention the company sponsoring a features when I
do a press interview or talk about a feature at a conference, if I know
who the sponsor is. It would be good to at least have a wiki page where
we could list the sponsors so people who publicize features would know.
I know I mentioned NEC as the sponsor of our SE-Linux integration during
my InformationWeek interview with Josh Berkus. The article mentions
KaiGai Kohei, but not NEC:
http://www.informationweek.com/news/development/database/229402894?pgno=2
--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ It's impossible for everything to be true. +
On Fri, May 13, 2011 at 05:29, Bruce Momjian <bruce@momjian.us> wrote: > Selena Deckelmann wrote: >> Hi! >> >> On Thu, May 12, 2011 at 2:30 PM, Nasby, Jim <JNasby@enovafinancial.com> wrote: >> > On May 12, 2011, at 4:23 PM, Selena Deckelmann wrote: >> >> The overhead of tracking who sponsored what on a feature-by-feature >> >> basis in release notes seems beyond what volunteers can be expected to >> >> keep track of. I also wouldn't want to have developer time spent on >> >> resolving conflicts in release notes about who sponsored what. >> > >> > I don't think the tracking would be that burdensome as long as people are using good submit messages. For example, searchingthe commit log for "Enova" would show you everything we sponsored through Command Prompt, because I know Alvarois good about putting that information in there. >> >> Bruce and Tom are typically who produce the release notes. So they're >> in the best position to respond to how much time this would take to >> collect. > > I am sure I could collect the information. The big question for me is > whether we _want_ such information in the release notes. The release > notes, for me, is for people to read about the release changes, and give > a small amount of credit to the author, and indicate who is mostly > responsible for the features, in case it has problems. > > I think adding sponsors to the release notes is going to make the > release notes look like a billboard, and I am not in favor of this. +1. Littering the release notes with this will make them *less* useful for their primary use-case, which is to find out what changed. I'd be more in favor of adding a complete separate section with "sponsors for this release". (yeah, it can go as a subchapter to release notes, but not interspaced with the rest of the info) > Obviously we don't even care to update the web site about sponsorships, > so why put in everyone's face in the release notes when we don't even do > the minimal of updating our own web site with this information. Keeping the actual sponsor page on the website properly up to date would be a good start. Maybe if we did that, the complaints wouldn't show up... -- Magnus Hagander Me: http://www.hagander.net/ Work: http://www.redpill-linpro.com/
Magnus Hagander wrote: > On Fri, May 13, 2011 at 05:29, Bruce Momjian <bruce@momjian.us> wrote: > > Selena Deckelmann wrote: > >> Hi! > >> > >> On Thu, May 12, 2011 at 2:30 PM, Nasby, Jim <JNasby@enovafinancial.com> wrote: > >> > On May 12, 2011, at 4:23 PM, Selena Deckelmann wrote: > >> >> The overhead of tracking who sponsored what on a feature-by-feature > >> >> basis in release notes seems beyond what volunteers can be expected to > >> >> keep track of. I also wouldn't want to have developer time spent on > >> >> resolving conflicts in release notes about who sponsored what. > >> > > >> > I don't think the tracking would be that burdensome as long as people are using good submit messages. For example,searching the commit log for "Enova" would show you everything we sponsored through Command Prompt, because I knowAlvaro is good about putting that information in there. > >> > >> Bruce and Tom are typically who produce the release notes. So they're > >> in the best position to respond to how much time this would take to > >> collect. > > > > I am sure I could collect the information. ?The big question for me is > > whether we _want_ such information in the release notes. ?The release > > notes, for me, is for people to read about the release changes, and give > > a small amount of credit to the author, and indicate who is mostly > > responsible for the features, in case it has problems. > > > > I think adding sponsors to the release notes is going to make the > > release notes look like a billboard, and I am not in favor of this. > > +1. > > Littering the release notes with this will make them *less* useful for > their primary use-case, which is to find out what changed. > > I'd be more in favor of adding a complete separate section with > "sponsors for this release". (yeah, it can go as a subchapter to > release notes, but not interspaced with the rest of the info) What we could do is to link to a wiki page that has the sponsors and their features. A more complex use would be to have a Google-type spreadsheet that lists all features by section, subsection, author, and sponsor. Full-time sponsored developers would have quite a number of items, and you could then sort the list by sponsor. As an idea, we could add the sponsors to the SGML file as comments which could then be pulled into a spreadsheet. -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. +
Bruce Momjian wrote: > The above sure looks like a billboard to me, as I stated in an earlier > email. > It's supposed to be. Jim's original message here pointed out that past sponsorship is not really visible to potential sponsors, when they are looking for evidence that it is possible to fund a PostgreSQL feature. I was aiming for a format that addressed that. If you feel that's tacky, fine, but I'd like to hear an alternative suggestion then. The problem he identified is very real, and a limiting factor for PostgreSQL feature expansion. I have someone ask me whether it's viable to sponsor a feature every few months. Being able to point toward a billboard showing past sponsorship successes, from many companies, is exactly what this community needs to have available for those business people, so that more features get funding in the future. -- Greg Smith 2ndQuadrant US greg@2ndQuadrant.com Baltimore, MD PostgreSQL Training, Services, and 24x7 Support www.2ndQuadrant.us
Magnus, > Keeping the actual sponsor page on the website properly up to date > would be a good start. Maybe if we did that, the complaints wouldn't > show up... So, when are we moving to Django so that we can turn the sponsors page into an application? Anyway, I'm willing to have a list of sponsors and the features they sponsored as part of the Press Kit. I think it wouldadd value there. *However*, I need someone to volunteer to do the work of collecting all the sponsor names and relatedfeatures. -- Josh Berkus PostgreSQL Experts Inc. http://pgexperts.com San Francisco
Hi! On Fri, May 13, 2011 at 9:13 AM, Greg Smith <greg@2ndquadrant.com> wrote: > Being able to point toward a billboard showing past > sponsorship successes, from many companies, is exactly what this community > needs to have available for those business people, so that more features get > funding in the future. 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. Let's start with a wiki page that highlights which companies are sponsoring which features. 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. Once we have figured out which companies are involved and interested, then let's revisit the conversation about how best to highlight it. I'm up for making the press release thing happen, if we get enough companies documenting this. -selena -- http://chesnok.com
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. > 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. 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. -- Greg Smith 2ndQuadrant US greg@2ndQuadrant.com Baltimore, MD PostgreSQL Training, Services, and 24x7 Support www.2ndQuadrant.us
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
Hi Jim, On Thu, May 12, 2011 at 1:25 PM, Nasby, Jim <JNasby@enovafinancial.com> wrote: > I think there's a couple benefits to mentioning sponsorship: > > - It provides added legitimacy to the project *in the eyes of businesses* when they see development being funded by otherbusinesses > - It raises awareness that businesses *can* fund development of features/fixes > - It recognizes those who have contributed to development Can you explain how Enova would use the recognition? I thought of a few things - like: easier to recruit other developers (maybe specifically Postgres devs) who are interested in open source, raise the profile of the company among investors who like to see that a company isn't dependent on proprietary software at their core. I couldn't think of any others though. -selena -- http://chesnok.com
Greg Smith 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. Oh, I thought that was for the release notes and when the company name came before the actual feature, it looked like Company XXX Park baseball stadium naming. Sure, that format is fine in a sponsorship-themed document. I apologize for not reading far enough down to see that the proposed format was _not_ for the release notes: - Publication: once you see the format it really needs to go in, this is - too heavy for the release notes. Don't distract the poor DBA who is - trying to read through them to see what's been fixed with this release, - they don't care about any of this. That's a technical document. Make a - sponsored feature page on the web site somewhere, publish updates in - something like the above format before the release goes out, and make - sure it's highlighted in the PR around the release. I obviously freaked out too quickly. :-( And I have no problem linkking _to_ the sponsorship Wiki page from the release notes. I also liked the spreadsheet or SQL file idea where we could actually do analysis of the companies and sponsored items. Yeah, why not use SQL for this. -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. +
Selena Deckelmann wrote: > 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. Yes, that was my reaction, and I now realize it was never suggested by Greg. -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. +
On Fri, May 13, 2011 at 23:08, Bruce Momjian <bruce@momjian.us> wrote: > I obviously freaked out too quickly. :-( > > And I have no problem linkking _to_ the sponsorship Wiki page from the > release notes. I may not be web-2.0-savvy enough.. But as a sponsor, I'd much rather see something like that as an appendix in the docs (even if it's well hidden), or as a page on the "actual" website. That gives it a much stronger "confidence level" than just a page on a wiki, that anybody can edit. (now, we know that we are fairly good at "policing" the content on our wiki, but an outsider does not know that) > I also liked the spreadsheet or SQL file idea where we could actually do > analysis of the companies and sponsored items. Yeah, why not use SQL > for this. SQL? I thought everything was supposed to be noSQL now?! Don't we just store it as a json file in the filesystem? That's so much more webscale! -- Magnus Hagander Me: http://www.hagander.net/ Work: http://www.redpill-linpro.com/
Magnus Hagander wrote: > On Fri, May 13, 2011 at 23:08, Bruce Momjian <bruce@momjian.us> wrote: > > I obviously freaked out too quickly. ?:-( > > > > And I have no problem linkking _to_ the sponsorship Wiki page from the > > release notes. > > I may not be web-2.0-savvy enough.. But as a sponsor, I'd much rather > see something like that as an appendix in the docs (even if it's well > hidden), or as a page on the "actual" website. That gives it a much > stronger "confidence level" than just a page on a wiki, that anybody > can edit. (now, we know that we are fairly good at "policing" the > content on our wiki, but an outsider does not know that) I was thinking of a wiki so it could be popuplated by the developers. We don't seem to be good at updating the main web site with content that requires coordination. > > I also liked the spreadsheet or SQL file idea where we could actually do > > analysis of the companies and sponsored items. ?Yeah, why not use SQL > > for this. > > SQL? I thought everything was supposed to be noSQL now?! Don't we just > store it as a json file in the filesystem? That's so much more > webscale! Well, I imagine this could get pretty complex. For example, I assume Tom's commits would show Red Hat, and 2nd Quadrants show 2nd Quadrant, and there are some features that have multiple people associated with the feature. In fact, this is not going to fit in a single SQL table but will need to join for multiple companies/contributors. -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. +
All, > > hidden), or as a page on the "actual" website. That gives it a much > > stronger "confidence level" than just a page on a wiki, that anybody > > can edit. (now, we know that we are fairly good at "policing" the > > content on our wiki, but an outsider does not know that) Did nobody read my suggestion that this should go in the Press Kit? That seems like the perfect location; it gives our sponsorsexposure somewhere official, while not turning the release notes (or even other parts of the docs) into a fundraisingbillboard. The Press Kit is all about PR, and this is PR. In fact, it makes sense to do it in 2 stages: (1) assemble a wiki page, starting now, and (2) when we complete the 9.1 Press Kit, copy the wiki page to a page of the press kit. But, here's the important question: who is going to take responsibility for this? If we don't have a volunteer who is goingto be in charge of making a sincere effort to list all feature sponsors, then any further discussion is pointless. > Well, I imagine this could get pretty complex. For example, I assume > Tom's commits would show Red Hat, and 2nd Quadrants show 2nd Quadrant, > and there are some features that have multiple people associated with > the feature. Let's please not turn this into a white elephant[1]. We have enough elephants around as it is. -- Josh Berkus PostgreSQL Experts Inc. http://pgexperts.com San Francisco ([1] for non-English: http://en.wikipedia.org/wiki/White_elephant)
On May 14, 2011 11:47 AM, "Joshua Berkus" <josh@agliodbs.com> wrote:
>
> All,
>
> > > hidden), or as a page on the "actual" website. That gives it a much
> > > stronger "confidence level" than just a page on a wiki, that anybody
> > > can edit. (now, we know that we are fairly good at "policing" the
> > > content on our wiki, but an outsider does not know that)
>
> Did nobody read my suggestion that this should go in the Press Kit?
You may not have read that I made the same suggestion about the press kit (well, press release... but still!) in my earlier posts in the thread. ;)
Greg said he would collect some information if we agreed on data to collect.
I think we are substantially agreed, and Greg can go ahead and collect info. Once we have it, we can talk more about format and placement.
-selena
On Sat, May 14, 2011 at 7:47 PM, Joshua Berkus <josh@agliodbs.com> wrote: > But, here's the important question: who is going to take responsibility for this? If we don't have a volunteer who isgoing to be in charge of making a sincere effort to list all feature sponsors, then any further discussion is pointless. Agreed. I think it's likely to be a tedious job, but I think it will help gain sponsors if we do this. Since I'll be one source of info on this, I volunteer as collator. Now the discussion can continue as to where to put this info and what format it should be in. -- Simon Riggs http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services
Selena Deckelmann wrote: > Feature > * Commits (list of hashes) > * Developers (with company affiliation, if desired) > * Reviewers (if any) > * Sponsors [optional] > * Detailed description of feature [optional] > I think burdening the initial implementation here with aiming at detailed descriptions will result in two problems. It makes it less likely the whole thing will get built, as that's the most painful part to edit down usefully And it's going to make the resulting page an unreadable giant. The reason I liked making the feature name a URL pointing to the commit is so people could click through to see that when desired. The idea of starting with SQL is similarly more complicated than I think this idea will support until proven to work. I'd absolutely like to have a comprehensive feature/commit/version matrix for PostgreSQL in SQL so I can manipulate it for a lot of reasons; it's a great concept. But if someone has to build one in order to make a prototype of this, the concept will probably have bloated itself into being impractical for this release. No idea where the manpower to do that is going to come from. Expecting to account for every commit or feature like this is I'd consider a good long-term goal, but not something that's going to happen for 9.1. Someone is welcome to correct me by doing it. I'm going to continue aiming for the simplest things that is useful, and hope that's a small enough target to accomplish. -- Greg Smith 2ndQuadrant US greg@2ndQuadrant.com Baltimore, MD PostgreSQL Training, Services, and 24x7 Support www.2ndQuadrant.us
Joshua Berkus wrote: > In fact, it makes sense to do it in 2 stages: > > (1) assemble a wiki page, starting now, and > (2) when we complete the 9.1 Press Kit, copy the wiki page to a page of the press kit. > Right. We've had some success at using the Wiki to prototype speculative things that ultimately end up in some more complicated form. (The CommitFest application is the most successful of such projects) If this doesn't go anywhere, it's the least disruptive way to prove the data won't get collected anyway. And if it does, nothing to say it can't be converted into something else. The output from the wiki format I'm expecting to use can be trivially turned into HTML tables or a spreadsheet, so it's not like it won't export. I'm not going to have time to work on seriously populating this beast. I was just suggesting I can work on the wiki plumbing and put some initial examples in to copy from. I think we should take the rest of the the discussion about implementation details to pgsql-www at this point though. That part is moving a bit off the advocacy list's charter, is boring many here I suspect, and I'd like to some of the people I believe are only on -www to bounce ideas off of. -- Greg Smith 2ndQuadrant US greg@2ndQuadrant.com Baltimore, MD PostgreSQL Training, Services, and 24x7 Support www.2ndQuadrant.us
On May 13, 2011, at 2:26 PM, Selena Deckelmann wrote: > On Thu, May 12, 2011 at 1:25 PM, Nasby, Jim <JNasby@enovafinancial.com> wrote: >> I think there's a couple benefits to mentioning sponsorship: >> >> - It provides added legitimacy to the project *in the eyes of businesses* when they see development being funded by otherbusinesses >> - It raises awareness that businesses *can* fund development of features/fixes >> - It recognizes those who have contributed to development > > Can you explain how Enova would use the recognition? > > I thought of a few things - like: easier to recruit other developers > (maybe specifically Postgres devs) who are interested in open source, > raise the profile of the company among investors who like to see that > a company isn't dependent on proprietary software at their core. I > couldn't think of any others though. For Enova Financial, the main benefit is it helps make the community aware that we're actively supporting the community,and might be a cool place to work. It's also nice to see recognition when you're spending money on community development. Personally, I want *other* companies to follow our example. If they start by sponsoring smaller things and nitpicks, notonly does it improve Postgres but it hopefully also paves the road for them to make more major contributions in the future.How much of Hot Standby was funded by financial contributions? BTW, I'm fine with getting this ball rolling by collecting info in the wiki and putting it in the press kit. We can see howthat works and go from there. As for collecting current information, hopefully it wouldn't be too onerous to grep the9.1 commit log for "sponsor", as well as try to make all the consulting companies aware that we'd like to note featuresthat were sponsored. -- Jim "Decibel!" Nasby jnasby@EnovaFinancial.com Primary: 512-579-9024 Backup: 512-569-9461