Well, why wouldn't we be soliciting their help...?
Nao
- Dadman with a boy
-
-
- Posts: 16,082
Arantor
-
-
- As powerful as possible, as complex as necessary.
- Posts: 14,278
Not quite my point.
If you open the doors and appear to accept patches, there is then a pressure on you to accept everything and anything that comes in. There is not the same pressure when the repository is not open.
If you open the doors and appear to accept patches, there is then a pressure on you to accept everything and anything that comes in. There is not the same pressure when the repository is not open.
When we unite against a common enemy that attacks our ethos, it nurtures group solidarity. Trolls are sensational, yes, but we keep everyone honest. | Game Memorial
Nao
- Dadman with a boy
-
-
- Posts: 16,082
Then SMF 2.1 has an edge over us..?
Arantor
-
-
- As powerful as possible, as complex as necessary.
- Posts: 14,278
Yes and no. Being open means you open the doors to a potential flood of submissions. You then have the joy of wading through the submissions in the hopes of finding good things. If you get a collection of great coder submissions, great, but the odds are not in favour of that being the case, given what has been approved as mods in the past.
Seriously, being open is not the magical panacea it's supposed to be. Being open means you get more input. It doesn't mean it's any *better* input. If anything I'd almost say that it will eventually dilute things because there will be pressure to accept patches that aren't up to snuff.
Consider the past of SMF. It was hard enough getting to be a beta tester, let alone a dev badge. Consider the people who earned that badge. Consider also the people who've submitted patches in the past to SMF, and how few of those were historically accepted. It's not merely a lack of time that caused all those things to be the case, it was the overall low quality of submissions.
In fact, going back it was pretty much only the people who were team members who ever got patches approved, and even then you're pretty much talking about the Cust. team people who ever got anything into the core who weren't the dev team. I haven't been through 2.1 but I suspect the people whose patches have been approved are the people who didn't make it into the Cust. team primarily out of politics or not wanting to be involved, but the same people nonetheless who would have been eligible anyway.
In short: I don't think it's really as open as might want to be believed[1] and while I want to believe the best, I'm not sure it's the right path for them to take.
To be brutally honest, I want to be wrong about this. But I want to see SMF take their main repo public and see what happens, I see no reason to think our experience will be substantially different. Everything I'm predicting is almost certain to come true sometime after SMF makes the 2.1 repo public, and I do not want us to fall into the same trap.
Seriously, being open is not the magical panacea it's supposed to be. Being open means you get more input. It doesn't mean it's any *better* input. If anything I'd almost say that it will eventually dilute things because there will be pressure to accept patches that aren't up to snuff.
Consider the past of SMF. It was hard enough getting to be a beta tester, let alone a dev badge. Consider the people who earned that badge. Consider also the people who've submitted patches in the past to SMF, and how few of those were historically accepted. It's not merely a lack of time that caused all those things to be the case, it was the overall low quality of submissions.
In fact, going back it was pretty much only the people who were team members who ever got patches approved, and even then you're pretty much talking about the Cust. team people who ever got anything into the core who weren't the dev team. I haven't been through 2.1 but I suspect the people whose patches have been approved are the people who didn't make it into the Cust. team primarily out of politics or not wanting to be involved, but the same people nonetheless who would have been eligible anyway.
In short: I don't think it's really as open as might want to be believed[1] and while I want to believe the best, I'm not sure it's the right path for them to take.
To be brutally honest, I want to be wrong about this. But I want to see SMF take their main repo public and see what happens, I see no reason to think our experience will be substantially different. Everything I'm predicting is almost certain to come true sometime after SMF makes the 2.1 repo public, and I do not want us to fall into the same trap.
| 1. | It's not even under the main public account but away in someone else's repos. Security by obscurity, you might say. |
CJ Jackson
-
-
- I got myself a new iPad, a different world to the iPhone!
- Posts: 241
Seriously, being open is not the magical panacea it's supposed to be. Being open means you get more input. It doesn't mean it's any *better* input. If anything I'd almost say that it will eventually dilute things because there will be pressure to accept patches that aren't up to snuff.
Nao
- Dadman with a boy
-
-
- Posts: 16,082
Re: Github & stuff
« Reply #35, on July 16th, 2012, 06:21 PM »Last edited on July 17th, 2012, 06:05 PM
Yes and no. Being open means you open the doors to a potential flood of submissions. You then have the joy of wading through the submissions in the hopes of finding good things. If you get a collection of great coder submissions, great, but the odds are not in favour of that being the case, given what has been approved as mods in the past.
Seriously, being open is not the magical panacea it's supposed to be. Being open means you get more input. It doesn't mean it's any *better* input. If anything I'd almost say that it will eventually dilute things because there will be pressure to accept patches that aren't up to snuff.
If it's not up to my standard, I'll just comment on the source code and tell people what's wrong with it. (It's one of the advantages of github -- you can comment on a specific line.)
Then I'll wait for them to adapt their code because later they'll remember to do it without my input.
Well, it's pretty much what John did after I commented his commits to Wedge back in the day ;)
Consider the past of SMF. It was hard enough getting to be a beta tester, let alone a dev badge.
Consider the people who earned that badge. Consider also the people who've submitted patches in the past to SMF, and how few of those were historically accepted. It's not merely a lack of time that caused all those things to be the case, it was the overall low quality of submissions.
In the SMF 2.1 repo, though, there's quite some activity (on par with Wedge I'd say.)
In the end, though, it's mostly about two developers, emanuele and spuds, doing most of the commits.
https://github.com/SimpleMachines/SMF2.1/graphs/contributors
Aside from them, *only* team members (or ex-members) can be found: norv, Thantos, Nas, John, nend (beta tester IIRC -- I suspect he's sicommnend at github), Trekkie, DrDeejay, IchBin.
So, even though the development process is now public, it's pretty much as if SMF had given commit access to all of their teamies. No need to go public indeed. I guess that going public and hoping for developers is either good for limited projects (which are more likely to receive external improvements, maybe the JS and PHP snippets I wrote could be part of that), or for huge projects that a lot of people are into, such as a programming language or OS or whatever.
I could suggest that we open a private git or mercurial or svn repo somewhere with a bug tracker (with a good one I mean... I don't know if RH's is any good?), and then we give commit access to anyone who requests it (basically people in our Friends and Consultants groups).
I know that a couple of years ago I was more protective of the codebase and will probably keep annoying the hell out of people like I did with John (and I'm still sorry about that), but I think it's better to have as many people as possible on the project, than basically just me these last few months. I'm sure there are areas that others would like to modify.
We could use a DCO like SMF 2.1 currently does, if no one wants to write a contributor agreement. The copyright would still be shared between Pete and I. No secrets about that, obviously.
To be brutally honest, I want to be wrong about this. But I want to see SMF take their main repo public and see what happens, I see no reason to think our experience will be substantially different. Everything I'm predicting is almost certain to come true sometime after SMF makes the 2.1 repo public, and I do not want us to fall into the same trap.
Don't see why it would be an active repo if it's not the official one..?
Arantor
-
-
- As powerful as possible, as complex as necessary.
- Posts: 14,278
And I guess you're wary of going back to a similar system...
So, even though the development process is now public, it's pretty much as if SMF had given commit access to all of their teamies. No need to go public indeed.
I could suggest that we open a private git or mercurial or svn repo somewhere with a bug tracker (with a good one I mean... I don't know if RH's is any good?), and then we give commit access to anyone who requests it (basically people in our Friends and Consultants groups).
I'm not sure about this anymore..? I remember SMF 2.1 was at one point hidden away at Spuds' repo, but now it's at SimpleMachines..?
Dragooon
- I can code! Really!
-
-
- polygon.com has to be one of the best sites I've seen recently.
- Posts: 1,841
The problem with giving direct access to commit is that you cannot review their work before including, it, in some ways, can be worse than a pull request. I know declining a pull request can be a slap in the face, but a lot of projects have pulled it off fairly fine. There really are not many good ways of rejecting a fully coded submission. Or we can go even more heavy duty by using something like gerrit.
 | The way it's meant to be |
Nao
- Dadman with a boy
-
-
- Posts: 16,082
I use git-cola interface, very easy to work with and is cross platform.
I'm not sure it's that 'easy' to work with if it requires installing msysgit, *then* Python, then PyQt... Meh! :^^;:
Posted: July 17th, 2012, 06:04 PM
The problem with giving direct access to commit is that you cannot review their work before including, it,
in some ways, can be worse than a pull request.
Posted: July 17th, 2012, 06:08 PM
I'm wary of dragging us into that particular quagmire. I'm hoping that there will be a higher quality of submission of plugins.
Wow, they actually made the repo public, as opposed to the playpen repo. But yes, it is as I suspected.
RH's bug tracker is pretty good, IMO, you should be able to try it out?
Yup it's now the main public repo, didn't realise it had actually been moved (see, I told you I don't check their repo!)
Oh, and BTW, I'm now 'officially' post-unbanned from simplemachines.org. It took some time because the person who originally unbanned me didn't remove the custom additional group I was in that prevented me from modifying my profile (ahem) and posting on most boards as well.
PantsManUK
-
-
- [me=PantsManUK]would dearly love to dump SMF 1.X at this juncture...[/me]
- Posts: 174
Git's workflow is quite different to that of SVN, but Git and Hg have very similar workflows (as someone that uses/has used all three). TBH, once you get your head into the two-step commit/pull way of working, it's not a hassle. Personally, I much prefer Git, but that's cause I've mostly migrated all my development work over to my Mac and that has Tower - The most powerful Git client for Mac (best damn Git client it's been my pleasure to use; I just wish someone would do something this good for PC).
Between GH and BB, I prefer the BB website, but I'm not using the wiki or ticketing systems on either of those two sites. Tower has inbuilt GH integration (you can create a GH repo from within Tower, and some other stuff too, but as I say, I don't really use it so the integration is overkill for me and my workflows)
Between GH and BB, I prefer the BB website, but I'm not using the wiki or ticketing systems on either of those two sites. Tower has inbuilt GH integration (you can create a GH repo from within Tower, and some other stuff too, but as I say, I don't really use it so the integration is overkill for me and my workflows)
« What is this thing you hoomans call "Facebook"? »
CJ Jackson
-
-
- I got myself a new iPad, a different world to the iPhone!
- Posts: 241
Has git-cola got any advantage over the competition...?
I'm not sure it's that 'easy' to work with if it requires installing msysgit, *then* Python, then PyQt... Meh! :^^;:
Nao
- Dadman with a boy
-
-
- Posts: 16,082
@CJ> You're saying it's easier to use. I'm saying it's harder to install. I'm just asking, what tells me it's going to be 'easy' to use once I install it? SmartGit isn't that hard to use, heck even TortoiseGit is okay after the initial learning curve...Quote from PantsManUK on July 18th, 2012, 05:13 PM Apparently, the command-line is the best possible git tool ahah... Says Linus himself. Of course.
Hey I laughed at this quote of his:
"Btw, (...), you're a quality example of why I detest the github
interface. For some reason, github has attracted people who have zero
taste, don't care about commit logs, and can't be bothered."
Source:
https://github.com/torvalds/linux/pull/17#issuecomment-5659970
The thread is a funny read... Although I stopped early on.Quote from PantsManUK on July 18th, 2012, 05:13 PM I cloned a GH repo earlier today (ah, the SHA-1 really doesn't help to keep track...), directly from github with the command line. It was alright. And I don't have to go through this annoying process of forking in my account, and thus encouraging people to look at my awful code... :P
Anyway, I'm still not entirely convinced. I think that for now, repohosting or bitbucket will be fine...
Git's workflow is quite different to that of SVN, but Git and Hg have very similar workflows (as someone that uses/has used all three). TBH, once you get your head into the two-step commit/pull way of working, it's not a hassle. Personally, I much prefer Git, but that's cause I've mostly migrated all my development work over to my Mac and that has Tower - The most powerful Git client for Mac (best damn Git client it's been my pleasure to use; I just wish someone would do something this good for PC).
Hey I laughed at this quote of his:
"Btw, (...), you're a quality example of why I detest the github
interface. For some reason, github has attracted people who have zero
taste, don't care about commit logs, and can't be bothered."
Source:
https://github.com/torvalds/linux/pull/17#issuecomment-5659970
The thread is a funny read... Although I stopped early on.
Between GH and BB, I prefer the BB website, but I'm not using the wiki or ticketing systems on either of those two sites. Tower has inbuilt GH integration (you can create a GH repo from within Tower, and some other stuff too, but as I say, I don't really use it so the integration is overkill for me and my workflows)
Anyway, I'm still not entirely convinced. I think that for now, repohosting or bitbucket will be fine...
CJ Jackson
-
-
- I got myself a new iPad, a different world to the iPhone!
- Posts: 241
@CJ> You're saying it's easier to use. I'm saying it's harder to install. I'm just asking, what tells me it's going to be 'easy' to use once I install it? SmartGit isn't that hard to use, heck even TortoiseGit is okay after the initial learning curve...
Norodo
-
-
- Oh you Baidu, so randumb. (60 sites being indexed at once? Jeez)
- Posts: 469
Holy shit Linus is badass.
I like him more and more.
I like him more and more.
PantsManUK
-
-
- [me=PantsManUK]would dearly love to dump SMF 1.X at this juncture...[/me]
- Posts: 174
Re: Github & stuff
« Reply #44, on July 19th, 2012, 03:25 PM »Last edited on July 19th, 2012, 04:04 PM
Anyway, I'm still not entirely convinced. I think that for now, repohosting or bitbucket will be fine...
Getting a client you like will always be the hardest thing (Tortoise* if you're Windows only is probably the best of them. It's lacking some features in it's UI, but you've always got the command line tool to fall back to), as a repo host is a repo host for the most part, especially if you're not using them for all their webness bells and whistles (like Linus does with GH).