I gave commit rights to someone I didn't know(jakewins.com)
jakewins.com
I gave commit rights to someone I didn't know
http://jakewins.com/p/clickbait
83 comments
Ha, Same thing happened to me with the SAME contributor!! Benjamin Bach is an awesome dude. He helped me maintain django-dbbackup for quite some time then we found a third contributor, Anthony Monthe, who is also very interested in the project and I would say owns it now. It's been maintained by those two for quite some time now. I wish there was a way for me to buy them both a bunch of rounds of beer. :D
He's a personal friend, i can buy him a beer on your behalf ;). I think he makes it work because he works part time and uses the rest of his time on open source projects. He could easily be earning far more if he worked full time, but this is what he prioritises.
Benjamin Bach seems to be awesome, however there are few people like him. Chances are your contributor won't be a Benjamin Bach. If the majority were like him, I'm sure we would have much less abandoned open source projects, but the majority isn't like him. Expect the worst and slight possibility of turning out like what the author described.
Haha, I'm so glad you shared that, that makes the story even better! I don't know Benjamin beyond our short interaction dealing with moving the repo around, but yeah he seems like an awesome dude.
Use Bitcoin or Venmo. Sounds like they've been great stewards.
I tried Google Wallet before, but it wouldn't let me send money out of the country or something like that.
Because only drug dealers would want to do that
You can do this with bitcoin, but only drug dealers use that
Wait...
You can do this with bitcoin, but only drug dealers use that
Wait...
Stop using Venmo
http://gizmodo.com/stop-using-venmo-1759867212
http://gizmodo.com/stop-using-venmo-1759867212
If that guy was paid in liquor by everyone who benefited from his contributions, he'd develop cirrhosis.
Convince both of them to join you at a Django conference.
I did the same thing..... and then the contributor took contributions from others that added security holes, removed cross platform support, and had what I consider to be low code quality. I've now disowned that project.
Therefore, I'm extremely hesitant to hand out "commit bit"s again. To make up for it I try and review PRs the day of submission; even then I don't get a lot of contributions.
There seems to be a inherent trade off between security+quality and how welcoming you are to new contributors.
On the other hand, I have taken over maintainership for some projects; but it was after months of steady contributions.
Therefore, I'm extremely hesitant to hand out "commit bit"s again. To make up for it I try and review PRs the day of submission; even then I don't get a lot of contributions.
There seems to be a inherent trade off between security+quality and how welcoming you are to new contributors.
On the other hand, I have taken over maintainership for some projects; but it was after months of steady contributions.
Wouldn't it have made sense to revert the first subpar commit, pulled aside the contributors and explained to them what is acceptable?
Disowning the project seems like a lose/lose situation.
Disowning the project seems like a lose/lose situation.
I'm not the parent, but I've been burned in the same way. In an ideal world, yes - that would be the right way to handle the situation. In a company you'd want to do that, and probably give the programmer a mentor who can do code reviews and whatnot.
Unfortunately thats:
- Thats a complicated conversation to have at the best of times. With volunteers over the internet its much harder to organise 1-on-1s.
- A huge time sink. Usually I could make the changes themselves in less time than it would take me to explain the changes to a junior developer. Its especially hard to justify for projects I have in maintenance mode, where I don't want to spend time working on project features at all. Long term hopefully the time investment will pay off, but they'll probably disappear long before then.
- Honestly, its also not that much fun. I contribute to opensource projects because I like making things. Managing people doesn't rub that itch.
I'm not saying I have a better solution. But faced with a stream of mediocre PRs from an enthusiastic new contributor that you don't have time to review, what do you do? Abandoning the project to the new contributor sounds pretty reasonable to me.
Unfortunately thats:
- Thats a complicated conversation to have at the best of times. With volunteers over the internet its much harder to organise 1-on-1s.
- A huge time sink. Usually I could make the changes themselves in less time than it would take me to explain the changes to a junior developer. Its especially hard to justify for projects I have in maintenance mode, where I don't want to spend time working on project features at all. Long term hopefully the time investment will pay off, but they'll probably disappear long before then.
- Honestly, its also not that much fun. I contribute to opensource projects because I like making things. Managing people doesn't rub that itch.
I'm not saying I have a better solution. But faced with a stream of mediocre PRs from an enthusiastic new contributor that you don't have time to review, what do you do? Abandoning the project to the new contributor sounds pretty reasonable to me.
It was a project that I didn't give a lot of love, and hence just gave them commit rights. It was about a year later before I looked again, by which time they had done far too much work on top of their non-cross-platform bits for me to revert.
I still didn't use the project myself; and didn't care enough to fix it, so I just removed myself.
I still didn't use the project myself; and didn't care enough to fix it, so I just removed myself.
Yeah, that's one of the dangers. Did you start a conversation with them about it, or just move on silently?
I'm trying to think of a good way to start such a conversation... but it sounds tricky. Probably would depend on the personality of the person. ;)
I'm trying to think of a good way to start such a conversation... but it sounds tricky. Probably would depend on the personality of the person. ;)
Why not just let them fork the project if they want to take it in a different direction?
It's always a delicate balance, as there are obviously a fair number of people who don't know what they're doing (yet, if they're learning), as well as some malicious people.
There are ways to deal with that, e.g. force small patches that solve well-identified problems; use CI to test; involve projects' users in testing; and above all, to have other maintainers in the project who can catch such behavior and help you fix it. By yourself, you're rather vulnerable.
Ideally you have a core of 2-4 people you trust from previous projects, and then you can bring unknown people in little by little.
There is no tradeoff as such, but you do need to be more sophisticated than "here are full commit rights."
There are ways to deal with that, e.g. force small patches that solve well-identified problems; use CI to test; involve projects' users in testing; and above all, to have other maintainers in the project who can catch such behavior and help you fix it. By yourself, you're rather vulnerable.
Ideally you have a core of 2-4 people you trust from previous projects, and then you can bring unknown people in little by little.
There is no tradeoff as such, but you do need to be more sophisticated than "here are full commit rights."
Same thing happened to me: I wrote the module that does Microsoft Office files in Python. At the time, the solutions for doing it in Python were 'talk to some Java library' or 'talk to some .net library'. I read the openxml spec and made something which did basic creation, extracting text, modifying docs.
I totally didn't have time to maintain it, then Scanny took over. It's now hugely popular, the code handles non-Word OpenXML docs, and most of the code has been added or refactored under Scanny.
https://python-docx.readthedocs.io/en/latest/
I totally didn't have time to maintain it, then Scanny took over. It's now hugely popular, the code handles non-Word OpenXML docs, and most of the code has been added or refactored under Scanny.
https://python-docx.readthedocs.io/en/latest/
I seriously just used this a couple weeks ago. Was thinking about implementing some more features as I had to drop down to manually editing the XML.
Mad props to you for creating that and Scanny for taking over! It's helped me automate some really nasty boring stuff that had to be done in Word.
> I don’t recall the author now, but the gist of the argument made was that we’re too protective of our code - if you give someone responsibility, show that you trust them, more often than not, your intuition about people abusing their freedom is way off.
Maybe it was some of Pieter Hintjens writing and/or the C4 process:
* https://rfc.zeromq.org/spec:42/C4/
* http://hintjens.com/blog:112
* http://hintjens.com/blog:106
Edit: oh, as the author mentions a blog post from 2012, it probably isn't any of the above posts (which are newer) but maybe something related to C4.
Maybe it was some of Pieter Hintjens writing and/or the C4 process:
* https://rfc.zeromq.org/spec:42/C4/
* http://hintjens.com/blog:112
* http://hintjens.com/blog:106
Edit: oh, as the author mentions a blog post from 2012, it probably isn't any of the above posts (which are newer) but maybe something related to C4.
Hentjens' "Social Architecture" book goes into the same topic in more detail, and is freely available here: https://hintjens.gitbooks.io/social-architecture/content/
I'd guess it was this:
http://felixge.de/2013/03/11/the-pull-request-hack.html
https://news.ycombinator.com/item?id=5357417
http://felixge.de/2013/03/11/the-pull-request-hack.html
https://news.ycombinator.com/item?id=5357417
Felix and I met some time before he wrote that blog post, and I explained our C4 process to him. His pull request hack, which I merged into C4 not long after, is neat though github doesn't provide the tools to do it easily.
Yeah that was my first guess. My second guess would be the articles around the demise of nanomsg. http://sealedabstract.com/rants/nanomsg-postmortem-and-other...
Was going to suggest the same thing :) I haven't had the sort of success that the OP did, but that PR Hack post def inspired my way of operating! Yay Felix
I'm gonna say you're probably right. I read the same thing years ago, and it was the first thing that popped into my head reading this.
I did something similar with a project I lost interest in several years ago (https://github.com/dbfit/dbfit - table-oriented database unit testing). Just gave over commit rights, and there's a whole bunch of people writing code for it and maintaining it now, still going strong. I occasionally look at the github repo, and always end up amazed how much it's moved on.
We use DbFit every day at our shop. It's really changed how we work (as DB developers). Was funny that I thought of this project right after reading this article, and how I should probably try and contribute, then I see this in the comments. :)
Thanks!
Thanks!
nice :) I built DbFit at a time when I was getting a lot of work helping companies with a huge investment in oracle pl-sql, but my interests moved on, and for a while it just felt I was holding the project back.
People wanted to implement new things, support new databases, I felt overprotective of the design, but didn't have enough time to bring new contributors onboard. So I just kind of gave up, and that allowed me to think about it from a completely different perspective. If I just deleted it, then I wouldn't care too much about it any more. Giving away the keys was kind of the same, but without preventing others from contributing. And it worked out great.
People wanted to implement new things, support new databases, I felt overprotective of the design, but didn't have enough time to bring new contributors onboard. So I just kind of gave up, and that allowed me to think about it from a completely different perspective. If I just deleted it, then I wouldn't care too much about it any more. Giving away the keys was kind of the same, but without preventing others from contributing. And it worked out great.
Similar story - I wrote KDocker (https://git.girish.in/projects/kdocker). It was stuck to Qt3 and I had no motivation to move it to Qt4 since it was a lot of work. Out of blue, John comes along and does a full Qt4 port. I decided to take a chance and transferred ownership of the project to him. I trusted him only because he had already written a lot of code to improve the project. It turned out to be a great decision (or luck). I just checked how it's doing today and he is still keeping it alive after all these years! (https://github.com/user-none/KDocker). Thanks John!
I was introduced to open source software in 1996 and have been a huge advocate since. About five years ago, I decided to quit my job and, shortly thereafter, went out in search of a project I could contribute to in my spare time (which was now much more abundant).
I quickly discovered that a particular piece of software I used daily wasn't really being maintained all that well, despite the fact that there were several contributors listed on its home page. A few dozen bugs reports (some even including patches!) had come in, yet only a few had even been acknowledged.
This seemed like exactly the type of project I was looking for -- something that I used every day and could help improve. I sent an e-mail to the developers stating that I was going to be devoting some time to the project, sending patches in for the bugs, etc., and asking if there was "anything I should know" before jumping in. I spent a lot of time reviewing the previous discussions on the mailing lists, examining their previous commits to see how they did things, and so on.
One of the developers finally replied -- about a week later -- and asked for my SSH key. I sent it to him and he quickly gave me commit access, thanked me for the assistance, yadda yadda.
I closed out umpteen bugs, responded to previously unanswered messages on the mailing lists, and sent patches to the developers list asking for feedback before I committed anything. Having received no responses, eventually I committed all the changes and pushed them into the master branch. Questions that I had to the other developers went unanswered, just like all the previous bug reports and user-submitted patches had.
After a while, I just quit spending any time on it. Perhaps a month after my latest fix, I look at my e-mail one day to see a flood of notification e-mails about commits. The lead developer had reverted every single commit I had made. I was looking for -- expecting -- some explanation but never received one, even after I finally directly asked, "WTF did I do wrong!?".
Nothing. No response, to this day. I eventually said "fuck it", deleted my private key, unsubscribed from the lists, and moved on. I just looked and there are still bugs open today that were open back then.
The sad part is that this piece of software is fairly widespread and a part of all of the major Linux distributions, installed by default on many of them. I think there's been one, maybe two, "releases" in the last five years.
I quickly discovered that a particular piece of software I used daily wasn't really being maintained all that well, despite the fact that there were several contributors listed on its home page. A few dozen bugs reports (some even including patches!) had come in, yet only a few had even been acknowledged.
This seemed like exactly the type of project I was looking for -- something that I used every day and could help improve. I sent an e-mail to the developers stating that I was going to be devoting some time to the project, sending patches in for the bugs, etc., and asking if there was "anything I should know" before jumping in. I spent a lot of time reviewing the previous discussions on the mailing lists, examining their previous commits to see how they did things, and so on.
One of the developers finally replied -- about a week later -- and asked for my SSH key. I sent it to him and he quickly gave me commit access, thanked me for the assistance, yadda yadda.
I closed out umpteen bugs, responded to previously unanswered messages on the mailing lists, and sent patches to the developers list asking for feedback before I committed anything. Having received no responses, eventually I committed all the changes and pushed them into the master branch. Questions that I had to the other developers went unanswered, just like all the previous bug reports and user-submitted patches had.
After a while, I just quit spending any time on it. Perhaps a month after my latest fix, I look at my e-mail one day to see a flood of notification e-mails about commits. The lead developer had reverted every single commit I had made. I was looking for -- expecting -- some explanation but never received one, even after I finally directly asked, "WTF did I do wrong!?".
Nothing. No response, to this day. I eventually said "fuck it", deleted my private key, unsubscribed from the lists, and moved on. I just looked and there are still bugs open today that were open back then.
The sad part is that this piece of software is fairly widespread and a part of all of the major Linux distributions, installed by default on many of them. I think there's been one, maybe two, "releases" in the last five years.
Ugh, that kind of dev behaviour is extremely lousy, and not at all the norm for Open Source projects.
Hopefully you've found places/projects more receptive to your time/effort since then. :)
Hopefully you've found places/projects more receptive to your time/effort since then. :)
Out of curiosity, why didn't you make a fork?
Wow, talk about some passive-aggressive behavior on the devs' part! I think there are hazards on projects where nothing seems to be happening, like you described, and others that are fairly active. At least with the active projects, you can usually get a feel for how you might be received by reading the mailing lists. I hope it didn't put you off looking for another project to help.
You really should tell us what the software is so we can know to avoid it or perhaps find your changes, fork the project and reapply them then push to have distorts switch to this new version.
Worked well for a number of projects where developers are jerks and don't allow other talented and dedicated contributors to participate.
Worked well for a number of projects where developers are jerks and don't allow other talented and dedicated contributors to participate.
Agree. This is an open source project and I'd like to know the name of it. Not for public shaming but so I can know what to avoid.
logcheck?
https://anonscm.debian.org/cgit/logcheck/logcheck.git/log/?o...
august, september 2011
Damn, what a dick move. Who is this Hannes von Haugwitz?
I have found 8 commits (https://anonscm.debian.org/cgit/logcheck/logcheck.git/log/?q...). Seven of those change 1-2 lines, the other updates the copyright file.
As far as I can see:
- 6a4bf69 has not been reverted
- d4a97c5 has been reverted in 8050b2d
- 5f7da05 has been reverted in ccc183d (webmin)
- cf5e9d3 has been reverted in 792a996 (webmin)
- c6634da has not been reverted, he is still listed in debian/copyright.
- 82f8600 has not been reverted (was extended in f24650f)
- 7f8efa8 has not been reverted
- e4f4889 has not been reverted
So, out of 8 commits, 3 have been reverted. The 2 webmin reverts were followed by deletion of the whole webmin file the same day (5785901).
I don't see how three reverts are "a flood of notification e-mails" or that "The lead developer had reverted every single commit I had made."
But I agree that the commit messages of those reverts should have contained a reason.
Obviously something went wrong. But I don't have enough information to call it a dick move.
As far as I can see:
- 6a4bf69 has not been reverted
- d4a97c5 has been reverted in 8050b2d
- 5f7da05 has been reverted in ccc183d (webmin)
- cf5e9d3 has been reverted in 792a996 (webmin)
- c6634da has not been reverted, he is still listed in debian/copyright.
- 82f8600 has not been reverted (was extended in f24650f)
- 7f8efa8 has not been reverted
- e4f4889 has not been reverted
So, out of 8 commits, 3 have been reverted. The 2 webmin reverts were followed by deletion of the whole webmin file the same day (5785901).
I don't see how three reverts are "a flood of notification e-mails" or that "The lead developer had reverted every single commit I had made."
But I agree that the commit messages of those reverts should have contained a reason.
Obviously something went wrong. But I don't have enough information to call it a dick move.
It's a dick move to revert and not tell the person why it was done even after they ask.
+1 mentioning the project
Want to know it too. Maybe someone of us know the Dev, and could ask why?
Or even simply have the Option, someone to fork and maintain it well.
/Sorry for Bad engl., written at Phone. Be patience :-)
This concept awesome and already have a name. It's called Open Open Source: http://openopensource.org
It's especially essential when managing a high volume of open source projects on GitHub.
It's especially essential when managing a high volume of open source projects on GitHub.
Yes! Rod Vagg (technical chair of Node.js) is one of the pioneers of this way of developing software. He was recently on the podcast "Request For Commits" discussing this very topic!
Liberal Contribution and Governance Models https://changelog.com/rfc-7/
Liberal Contribution and Governance Models https://changelog.com/rfc-7/
DB Browser for SQLite (previously known as SQLite Browser) has a similar history:
http://sqlitebrowser.org
It was unmaintained on SourceForge for years. Some guys put the code on GitHub and started fixing its problems. I became involved after them (to help on the OSX side initially), then contacted the original author. He was happy to see some people continuing it's development, so he gave us admin on the SourceForge project. That let us cleanly redirect people to the new GitHub project, and it's been growing decently from there (~4,600 stars on GitHub, 3.5Mill+ downloads, etc).
http://sqlitebrowser.org
It was unmaintained on SourceForge for years. Some guys put the code on GitHub and started fixing its problems. I became involved after them (to help on the OSX side initially), then contacted the original author. He was happy to see some people continuing it's development, so he gave us admin on the SourceForge project. That let us cleanly redirect people to the new GitHub project, and it's been growing decently from there (~4,600 stars on GitHub, 3.5Mill+ downloads, etc).
What a small world, I worked with Greg at CashStar where he started the fork of django-money. I still remember the conversation we had in a meeting if we should fork the project or push our PR upstream to fix the issues we found. I'm glad our upstream PR started a trend to keep the library going. This is why I like open source, when you no longer need something you can hand it off to someone else who can take over, and let the code live on.
I did this for a (not very popular) Eclipse IDE autocomplete set for a certain Lua-based game engine.
I updated to 0.9.2d and forgot about it (stopped using the engine), and someone came in with a PR for 0.10.0. I made a couple of notes on the PR, and gave the guy commit access.
He cleaned it up, and has been rebuilding occasionally when new minor versions of the API definitions come in.
The vast majority of people are pretty nice. They aren't assholes. They're just people who have the same issues you had to build the project in the first place, and want to help.
I updated to 0.9.2d and forgot about it (stopped using the engine), and someone came in with a PR for 0.10.0. I made a couple of notes on the PR, and gave the guy commit access.
He cleaned it up, and has been rebuilding occasionally when new minor versions of the API definitions come in.
The vast majority of people are pretty nice. They aren't assholes. They're just people who have the same issues you had to build the project in the first place, and want to help.
Yep, something similar happened to me - I released what is now https://github.com/punker76/gong-wpf-dragdrop on google code in 2009 (I think) then pretty much lost interest. Forward on a few years and @punker76 had uploaded it to github, and continued working on it. It was a strange feeling when I first became aware of the fork - like seeing an inanimate object come to life.
Great story. My similar experience was in the mid 1990s. I had written a tool call PicWeb Viewer that would recursively walk directories and subdirectories containing photos, create thumbnail images, and generate simple HTML to navigate everything. My code was so simple but worked fine. I released the source code and over the next few years several people contributed modifications that made my simple bit of code awesome.
I've been using the Ratpoison window manager for more than ten years now, and I love it a lot.
Back in like 2003, I wanted to check out the CVS repository, probably because of some new feature, but the read-only CVS server at Savannah or whatever was down... so I asked in #ratpoison if someone could send me a tarball.
Instead, one of the authors and maintainers just gave me an account on the commit server, mostly out of laziness I think.
But it felt nice to be trusted. Loyal user ever since.
Back in like 2003, I wanted to check out the CVS repository, probably because of some new feature, but the read-only CVS server at Savannah or whatever was down... so I asked in #ratpoison if someone could send me a tarball.
Instead, one of the authors and maintainers just gave me an account on the commit server, mostly out of laziness I think.
But it felt nice to be trusted. Loyal user ever since.
I offered to take over a library that provides a Pythonic interface for Redis a little while ago. The original author accepted, and I've really enjoyed bringing the project back to life.
I'll probably do something like that again - it would be great if there were a good list of projects that are looking for maintainers.
I'll probably do something like that again - it would be great if there were a good list of projects that are looking for maintainers.
The Jazzband is a Python-focused group based around similar ideas: People can transfer their projects to the group, and anyone in the group can commit stuff and make releases.
https://jazzband.co/
https://jazzband.co/
I had submitted several PRs to a Zip streaming library. The author gave me direct commit access after this. I've helped maintain it ever since. I think it can really work out in some cases.
I shared mod privileges with somebody on reddit and my subreddit was closed for excessive spam within days -- I learned my lesson!
Amazing story! I maintain a network library on iOS where we have automated this process: a merged pull request earns the author an automatic invitation to join the project. The code is at https://github.com/Moya/Aeryn if anyone is interested.
This is awesome!
seeing something stay alive live this and grow due to people liking it
seeing something stay alive live this and grow due to people liking it
I have an EMF+ library I started the barebones of in LibreOffice. [1]
Largely due to my depression and desperate need to get a job, I never got much past an initial read of the EMF+ files, but I'd love to see someone take my branch on git, split it into its own library and then work with someone to integrate it into the Drawing Layer. [2]
1. https://cgit.freedesktop.org/libreoffice/core/commit/?h=priv...
2. https://people.freedesktop.org/~thorsten/talks/fosdem_2014_s...
Largely due to my depression and desperate need to get a job, I never got much past an initial read of the EMF+ files, but I'd love to see someone take my branch on git, split it into its own library and then work with someone to integrate it into the Drawing Layer. [2]
1. https://cgit.freedesktop.org/libreoffice/core/commit/?h=priv...
2. https://people.freedesktop.org/~thorsten/talks/fosdem_2014_s...
Oh, and to be honest it shouldn't be that hard to work on.
It basically works via a Command pattern. That's because an EMF is a binary file that consists of a bunch of sequential records. The way it works is that you get an EMF+ file, and you read it from start to finish. Each record you read has a consistent header, and each different type of record does something - or stores an object (such as a pen or font).
My big idea is to use a base EmfAction class that has a function Read() that you use to read each type of record. You use EmfAction::ReadEmfAction() to read the next record from an ifstream, and it moves the file pointer to the start of the next record, and you just loop through the file like this:
https://cgit.freedesktop.org/libreoffice/core/diff/vcl/sourc...
The only snag was how to set state on the DeviceContext - I want the commands to read and store the state, and the DeviceContext should be passed into the command object and be manipulated by it via an Execute(DeviceContext&). But at the time I concentrated on how to read the objects.
Of course, EMF+ has a way of saving a DC's state, allows the DC be modified by subsequent records, and then the DC can be restored, so a stack of DCs needs to be established, but how to do this I'm not rightly sure yet.
I'm pretty certain though that I'm going to need to change the EmfRecord derived command records to start using a constructor where the DeviceContext object is passed in as a pointer.
The header file can be found here:
https://cgit.freedesktop.org/libreoffice/core/tree/include/v...
The record commands are implemented here:
https://cgit.freedesktop.org/libreoffice/core/tree/vcl/sourc...
As it is an initial implementation. The Read() calls are defined in the class declaration. Obviously that will need to be corrected.
The code also probably needs to be rebased, but in all honestly it is such a small change I don't think it would be too hard...
It basically works via a Command pattern. That's because an EMF is a binary file that consists of a bunch of sequential records. The way it works is that you get an EMF+ file, and you read it from start to finish. Each record you read has a consistent header, and each different type of record does something - or stores an object (such as a pen or font).
My big idea is to use a base EmfAction class that has a function Read() that you use to read each type of record. You use EmfAction::ReadEmfAction() to read the next record from an ifstream, and it moves the file pointer to the start of the next record, and you just loop through the file like this:
https://cgit.freedesktop.org/libreoffice/core/diff/vcl/sourc...
The only snag was how to set state on the DeviceContext - I want the commands to read and store the state, and the DeviceContext should be passed into the command object and be manipulated by it via an Execute(DeviceContext&). But at the time I concentrated on how to read the objects.
Of course, EMF+ has a way of saving a DC's state, allows the DC be modified by subsequent records, and then the DC can be restored, so a stack of DCs needs to be established, but how to do this I'm not rightly sure yet.
I'm pretty certain though that I'm going to need to change the EmfRecord derived command records to start using a constructor where the DeviceContext object is passed in as a pointer.
The header file can be found here:
https://cgit.freedesktop.org/libreoffice/core/tree/include/v...
The record commands are implemented here:
https://cgit.freedesktop.org/libreoffice/core/tree/vcl/sourc...
As it is an initial implementation. The Read() calls are defined in the class declaration. Obviously that will need to be corrected.
The code also probably needs to be rebased, but in all honestly it is such a small change I don't think it would be too hard...
To offer a different perspective: I did this with a library that's mostly used for short lived hacks, so while there are contributions from time to time, no one sticks with it for long enough to become a real maintainer. So I'm still the one pressing the merge button on new PRs.
A long time ago I wrote PyMouse, which someone added keyboard support to, which became PyUserInput. But then I ended up being the maintainer of the new combined project. So lately I've just been giving contributors commit access. So far the results are OK, but it's not like anyone took over the maintenance.
A long time ago I wrote PyMouse, which someone added keyboard support to, which became PyUserInput. But then I ended up being the maintainer of the new combined project. So lately I've just been giving contributors commit access. So far the results are OK, but it's not like anyone took over the maintenance.
Thats not how it works though. It's just called luck.
If 90 out of 100 people will do correct commits and not fuck things up in various ways (from inserting a backdoor to just breaking code), then you've 90% chance that 1 person you give commit access to will not do anything wrong.
Are you willing to bet your 10% bad luck on this though? What if its not 10%? How much chance, when 1 become 1 000?
Now that is more like it.
Are you willing to bet your 10% bad luck on this though? What if its not 10%? How much chance, when 1 become 1 000?
Now that is more like it.
Whilst this is an interesting story and shows how open source software can work it leaves me wondering how large corp's handle their increasing use of open source software.
Traditional corporate development is very controlled with everyone getting background checks on hiring and code reviews and change control and a load of other stuff around managing what software runs their business.
Into that mix corps are adding loads of software that's developed by people who they have no control over and no knowledge of their motivations, affiliations or skill level. Even if they did a one-time check of all the developers who had contributed to libriaries they use (which would be a huge task) there's nothing to stop any of the maintainers from handing over to someone else the next day.
It's even a change from using things like RHEL where there's at least a contract with another company that you could point at if things go wrong...
It seems a very odd match up....
Traditional corporate development is very controlled with everyone getting background checks on hiring and code reviews and change control and a load of other stuff around managing what software runs their business.
Into that mix corps are adding loads of software that's developed by people who they have no control over and no knowledge of their motivations, affiliations or skill level. Even if they did a one-time check of all the developers who had contributed to libriaries they use (which would be a huge task) there's nothing to stop any of the maintainers from handing over to someone else the next day.
It's even a change from using things like RHEL where there's at least a contract with another company that you could point at if things go wrong...
It seems a very odd match up....
it's crazy how many millions/billions of dollars free software
has saved people.
even crazier is how many millions of dollars people have made creating free software!
I've been involved in the Plone community for a number of years. All you need to do to get commit rights is to sign the copyright assignment and ask. We currently have 400 people with rights, I suspect we lost a few when we migrated from self-hosted SVN to GitHub.
In over ten years of this policy, we've only had one committer act in bad faith.
In over ten years of this policy, we've only had one committer act in bad faith.
I like how clickbait is actually in the url. Epic. In case it changes, as of the time of the comment it was
jakewins.com/p/clickbait[deleted]
such an awesome story!
Thank you for sharing this is awesome!
judiso(3)
[deleted]