Re: Code of Conduct plan
On Sun, 16 Sep 2018 16:00:31 +1200 Mark Kirkwood wrote: > a SJW agenda. > the angry militant left. Some people just can't stop themselves. Which is a big reason for CoCs. SteveT Steve Litt September 2018 featured book: Quit Joblessness: Start Your Own Business http://www.troubleshooters.com/startbiz
Logical locking beyond pg_advisory
I need a mechanism of "logical locking" more ductile than the
pg_advisory family.
I'm thinking of a table ("lock_table") that would be part of the
database, with columns
* tablename varchar - name of the table "locked"
* rowid integer, - id of the row "locked"
* ownerid varchar, - identifier of the "user" who acquired the lock
* acquired timestamp - to be able to release "abandoned" locks after a
certain time
and a group of functions
1) lock_table (tablename varchar, ownerid varchar) bool - get to lock
over the entire table, setting rowid to zero
2) unlock_table (tablename varchar, ownerid varchar) bool - unlock the
table, if the owner is the recorded one
3) locked_table (tablename varchar, ownerid varchar) bool - ask if the
table is locked by some user other than the ownerid argument
4) lock_row (tablename varchar, rowid integer, ownerid varchar) bool -
similar to pg_try_advisory_lock
5) unlock_row (tablename varchar, rowid integer, ownerid varchar) bool -
similar to pg_advisory_unlock
6) unlock_all (ownerid varchar) bool - unlock all locks owned by ownerid
The timeout (default, maybe 15 minutes) is implicitly applied if the
lock is taken by another user (there will be no notification).
Redundant locks are not queued, they simply return true, may be after an
update of the acquired column.
Successful locks insert a new row, except the rare case of a timeout,
which becomes an update (ownerid and acquired)
Unlock operations deletes the corresponding row
My question is double
a) What is the opinion on the project?
b) What are the consequences of the large number of inserts and deletions
c) Performance. In fact, pg_advisory* implies a network roundtrip, but
(I think) no table operations.
TIA
---
El software de antivirus Avast ha analizado este correo electrónico en busca de
virus.
https://www.avast.com/antivirus
RE: Code of Conduct plan
Dear All, If we allow friendship and fellowship to flourish everyone benefits. That doesn't mean we should drop our standards or quality. It is worth remembering that all human beings are social animals(basic logic) so even the most logical person could get offended and turn off from contributing to overall consultations, we can say everything with moderation and consult with compassion. Say your piece but don't insist on it, we are all busy, repetitive arguments over the same points is a turn off for most people. Especially for a community based projects. Personally I have no problem with a code conduct. After all most people agree that, even a mundane thing like crossing a road needs rules, so something as complex as human interactions also needs rules. That's my two cent worth of contribution. Best Regards Farjad Farid
Re: Code of Conduct plan
On Sat, 15 Sep 2018 16:12:36 -0700 Adrian Klaver wrote: > https://marshmallow.readthedocs.io/en/dev/code_of_conduct.html Personally I don't give a toss about politolosophy, I think idiocy, no matter how well-meaning, is still idiocy and is probably contaguious via "normalization of idiocy". Since "god won't save us from well-meaning people" and "you can't overcome stupid", the only rational option left is not to march with them. -- Dmitri Maziuk
Re: Code of Conduct plan
As long as subscribers to the list or attendants at a conference do not violate explicit or implicit house rules, what business does Postgres have worrying about what they do or say elsewhere? Some version of an 'all-of-life' clause may be appropriate to the Marines or federal judges, but it strikes me as overreach for a technical listserv whose subject is a particular relational database. The overreach is dubious on both practical and theoretical grounds. "Stick to your knitting " or the KISS principle seem good advice in this context. On 9/16/18, 7:08 AM, "Stephen Cook" wrote: On 2018-09-16 00:00, Mark Kirkwood wrote: > On 15/09/18 08:17, Tom Lane wrote: >> Yeah, this. The PG community is mostly nice people, AFAICT. I'll be >> astonished (and worried) if the CoC committee finds much to do. We're >> implementing this mostly to make newcomers to the project feel that >> it's a safe space. > > Agreed. However I think the all-of-life clause gives an open door to > potential less than well intentioned new members joining up to extend a > SJW agenda. So in fact the unintended consequence of this may be a > *less* safe place for some existing members - unless all of their social > media utterances are agreeable to the angry militant left. This is my only concern, there are some very sensitive people out there just looking for scandal / publicity. No reason to give them a larger attack surface. Maybe that sounds paranoid but look around, there are folks that want to spread the US culture war to every front, including open source projects on the internet. This sentence in the CoC should be worded to exclude things that are not directed harassment when outside of the community spaces. For example, some "incorrect opinion" on Twitter should have little bearing if it wasn't meant as an "attack". Maybe for extreme cases there could be a "hey you're making us look bad and scaring people away, chill with the hate speech or leave" clause, but that should only apply if it is someone whose name is publicly associated with Postgres and they are saying really terrible things. I feel there is a big difference between keeping it civil/safe in the lists and conferences, and making people afraid to say anything controversial (in the USA) anywhere ever. Maybe the way the committee is set up, it will handle this fairly. But it's better to be explicit about it IMO, so as not to attract professional complainers. -- Stephen
Code of Conduct plan
On 2018-09-16 00:00, Mark Kirkwood wrote: > On 15/09/18 08:17, Tom Lane wrote: >> Yeah, this. The PG community is mostly nice people, AFAICT. I'll be >> astonished (and worried) if the CoC committee finds much to do. We're >> implementing this mostly to make newcomers to the project feel that >> it's a safe space. > > Agreed. However I think the all-of-life clause gives an open door to > potential less than well intentioned new members joining up to extend a > SJW agenda. So in fact the unintended consequence of this may be a > *less* safe place for some existing members - unless all of their social > media utterances are agreeable to the angry militant left. This is my only concern, there are some very sensitive people out there just looking for scandal / publicity. No reason to give them a larger attack surface. Maybe that sounds paranoid but look around, there are folks that want to spread the US culture war to every front, including open source projects on the internet. This sentence in the CoC should be worded to exclude things that are not directed harassment when outside of the community spaces. For example, some "incorrect opinion" on Twitter should have little bearing if it wasn't meant as an "attack". Maybe for extreme cases there could be a "hey you're making us look bad and scaring people away, chill with the hate speech or leave" clause, but that should only apply if it is someone whose name is publicly associated with Postgres and they are saying really terrible things. I feel there is a big difference between keeping it civil/safe in the lists and conferences, and making people afraid to say anything controversial (in the USA) anywhere ever. Maybe the way the committee is set up, it will handle this fairly. But it's better to be explicit about it IMO, so as not to attract professional complainers. -- Stephen
Re: Code of Conduct plan
On Sat, Sep 15, 2018 at 8:11 PM Tom Lane wrote: > Martin Mueller writes: > > Which makes me say again "Where is the problem that needs solving?" > > We've re-litigated that point in each burst of CoC discussion for the > last two-plus years, I think. But, one more time: > > * So far as the mailing lists alone are concerned, we likely don't really > need a CoC; on-list incidents have been pretty few and far between. > However, there *have* been unfortunate incidents at conferences and in > other real-life contexts. Core has been encouraging conference organizers > to create their own CoCs, but (a) they might want a model to follow; > (b) there needs to be a community-level backstop in case of failure of > a conference to have or enforce a CoC; and (c) conferences aren't the > only point of contact between community members. > As a note, the current CoC wording appears to explicitly exempt enforcement from conferences as long as they have their own CoC (whatever either the terms or the implementation). So point b is not resolved at all and under this there is no community backstop if we take the text at face value. "This Code is meant to cover all interaction between community members, whether or not it takes place within postgresql.org infrastructure, **so long as there is not another Code of Conduct that takes precedence (such as a conference's Code of Conduct).**" [emphasis mine] Hence I think it would be better to suggest a more nuanced line, one where acting on things off list etc is subject to the overall balance of community interest and an inability of other parties to act. If the goal is to give conferences an ability to enforce their own rules, with a community backstop, then one needs a functional, not merely formal line. If the goal is a sort of subsidiarity, then such a functional line is better too. So I would recommend changing that to "This code of conduct may be applied to conduct on or off community resources so long as the conduct is related to the community, other parties are unable to act, and it is in the community's interest to apply the this code of conduct." That more or less explicitly puts the decisions on where and when to apply it in the hands of the committee, which is probably better than promising a large scope and then telling new folks "sorry, that isn't covered" after setting expectations to the contrary. > > * This isn't really directed at people who already participate in our > mailing lists. The reason for setting up a formal CoC is to reassure > potential new contributors that the Postgres project offers a safe > environment for them. As has been pointed out before, a lot of people > now feel that some sort of CoC is a minimum requirement for them to > want to deal with a community. Whether you and I find that a bit too > shrinking-violety isn't relevant; if we want to keep attracting new > participants, we have to get with the program. > > Now, the hazard in that of course is that someone will come in and > try to use the CoC mechanism to force the PG community to adopt that > person's standards of conduct. It'll be up to the CoC committee > (and core, in the case of appeals) to say no, what you're complaining > about is well within this community's normal standards. That's a > reason why a two-line CoC isn't a good idea; it leaves too much to > be read into it. > It's worth noting that in the cases I am concerned about, the CoC committee would have to decline the complaint. I am not worried about them acting badly. What I am worried about are people getting worked up about something outside the community when someone who complains gets told no. > > Anyway, the short answer here is that we've been debating CoC wording > for more than two years already, and it's time to stop debating and > just get it done. We're really not going to entertain "let's rewrite > this completely" suggestions at this point. > Agreed on not rewriting completely. However the particular recent addition I am objecting to is relatively troubling for a reason. Personally, I felt like we were assured when this process started that a code of conduct would regulate on-infrastructure behavior only. Now, for reasons you have said, that scope is too narrow and I understand that. Those reasons and the issues behind them have been discussed from the beginning, and so I don't really object to broadening the scope to things like campaigns of personal harassment including in real life, etc. I recognize that to be totally necessary. However, the addition goes way beyond that and it feels like a full reversal of a promise that was made to the community much earlier to try to keep the code of conduct from something that could be used to apply pressure from outside to get rid of community members for activity that is not related to PostgreSQL (in particular, unrelated political involvement, opinions, and participation). If you aren't open to rewriting even that one sentence, I
