Wedge

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.

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.

1.	It's not even under the main public account but away in someone else's repos. Security by obscurity, you might say.

Ah well, you certainly know better than me in that area... Eheh! ;) And I guess you're wary of going back to a similar system...Oh, no pressure for me, I think...
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 ;)Yeah...So, I'm looking at the smCore repo and it hasn't had a commit in 2 months, eh... What's up with Norv? I don't know.
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.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..?https://github.com/SimpleMachines/SMF2.1

Don't see why it would be an active repo if it's not the official one..?

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.

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)

@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...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.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...

Holy shit Linus is badass.

I like him more and more.