[Some Support]

I'd like to setup a repository which allows pushes for those smaller changes, because I agree some of them should be in. Not quite the pure refactoring but those who are small bugs which don't have any bigger impact (meaning there is not in depth review needed). It shouldn't take long to approve this and yes I don't think the time of those who contribute should be wasted. I'll check if it works with SF or otherwise setup a github once I get around to it.

[Tuxman]

While "pull requests" are - at least compared to SourceForge - damn easy on Github, I personally dislike git. Why not Bitbucket so we can use Mercurial? It even has better branching.

But, of course, SourceForge would also work.

[fox88]

About two weeks ago Ergol finished one month long run of my (debug) build with overlapped sockets on.
There were no crashes, and not even a single assert.
Which means, probably it is stable enough (it was less than an hour for the build #16 to crash).

Once again I think that was an issue with virtual destructors. To eliminate such possibility, every class with virtual methods got a virtual destructor.
Here goes the list.

Friend.h protected virtual ~CFriendConnectionListener
KadClientSearcher.h virtual ~CKadClientSearcher
ListCtrlItemWalk.h protected virtual ~CListCtrlItemWalk
MemDC.h virtual ~CMemoryDC
ShaHashSet.h virtual ~CAICHHashAlgo
ThrottlerSocket.h protected virtual ~ThrottledControlSocket

This post has been edited by fox88: 26 March 2016 - 08:58 PM

[pier4r]

tHeWiZaRdOfDoS, on 26 March 2016 - 03:00 PM, said:

What I meant is that some of the stuff is only cosmetics, some devs like it, some don't... and other stuff needs to be revisited before applying the changes as it may have additional impact.

Ok about code refactoring, it is style. But for small fixes, it is not bad to (in my pov):
- implement a fix (very small change)
- release it as beta
- if no one raises problems in 14-20 days: release it as stable (this is also "marketing", for the user it seems that the dev team is active)
- implement the next fix
- rinse and repeat.

If problems happen: revert the change, fix it.

I guess this is not the difficult part, the difficult part is to track and collect the suggested small fixes against the actual code. Even just considering this board, discarding the rest of the internet. (Because considering only this thread would be better than nothing, but rather small i think)

Some Support, on 26 March 2016 - 08:24 PM, said:

I'd like to setup a repository which allows pushes for those smaller changes, because I agree some of them should be in. Not quite the pure refactoring but those who are small bugs which don't have any bigger impact (meaning there is not in depth review needed). It shouldn't take long to approve this and yes I don't think the time of those who contribute should be wasted. I'll check if it works with SF or otherwise setup a github once I get around to it.

Glad to hear that . Even jut having the actual code with small patches is an improvement towards maturity of the application.

This post has been edited by pier4r: 27 March 2016 - 12:04 PM

[Some Support]

Some Support, on 26 March 2016 - 08:24 PM, said:

I'd like to setup a repository which allows pushes for those smaller changes, because I agree some of them should be in. Not quite the pure refactoring but those who are small bugs which don't have any bigger impact (meaning there is not in depth review needed). It shouldn't take long to approve this and yes I don't think the time of those who contribute should be wasted. I'll check if it works with SF or otherwise setup a github once I get around to it.

I took a few minutes to figure out how to go. I haven't used a collaborative repository (with open/anonymous access) for a long time, so I'm not aware what the best solution is at this time. Sourceforge supports all major repository clients, including svn, mercurial (which we use right now) and git. However only developers can commit and users will have to create patch files and send/post them some other way. This would already work right now, but it's quite inconvenient - so while I do prefer staying on the same platform for the project, I'm not sure if that's perfect (if I missed something regarding SF, do tell).
What I want is users/anonymous clients being able to apply patches and have them queued up for the developers to hit the "approve" or "f*** this, it stays how it is" button. I haven't used Github before, but I do suppose it how it works out? Any other option to consider?

[fox88]

Funny article comparing Git and Mercurial.

[Tuxman]

What about Bitbucket? Which is, basically, the Mercurial version of Github, and, unlike Github, they're not spoiled with SJW politics yet. While I'm also on Github for a variety of reasons, I exclusively switched to Bitbucket for new projects a while ago and I find it lovely.
(You could as well set up your own Mercurial or git server on emule-project.net, by the way; is there a reason not to do that?)

Also, this only affects the project repository. No one said that the whole emule-project will have to leave Sourceforge just because you move the source repository.

And: How about keeping two repositories, the closed one on Sourceforge and a public one on Bitbucket (or wherever) where you can pick commits as you wish?

This post has been edited by Tuxman: 31 March 2016 - 03:52 PM

[Some Support]

Tuxman, on 31 March 2016 - 04:51 PM, said:

(You could as well set up your own Mercurial or git server on emule-project.net, by the way; is there a reason not to do that?)

We had our private repository on our own servers before, but there is no advantage to do so for a public one. It's one less issue to manage/admin and SF isn't missing any functionality in that regard.

Quote

Also, this only affects the project repository. No one said that the whole emule-project will have to leave Sourceforge just because you move the source repository.

And: How about keeping two repositories, the closed one on Sourceforge and a public one on Bitbucket (or wherever) where you can pick commits as you wish?

We won't move from SF and yes two different ones would be how it would work out, but it is somewhat confusing after all to those who aren't aware of it.

Quote

Funny article comparing Git and Mercurial.

Interesting. But then again, it's not really a question off the CVS it is based on (where git and mercurial seems pretty similar anyway according to the article) but on how it is implemented. It should be easy to commit patches via a website and client, have them nicely presented to developers (and maybe other users to comment on) and so on. As far as I am aware SF doesn't has this functionalty but again, I might be missing something I haven't browsed through all their tools for a long time. So right now Bitbucket and Github were suggested.

[Tuxman]

Some Support, on 31 März 2016 - 07:30 , said:

It should be easy to commit patches via a website and client, have them nicely presented to developers (and maybe other users to comment on) and so on.

Bitbucket: Web interface (screenshot).
Github: Web interface (annotated screenshot).
SourceForge: Requires you to type commands.

However, the command-line commands to merge and view patches are the same for all services (depending, of course, on your choice between hg and git); so SourceForge probably has the most pragmatic approach here.

[pier4r]

just my 5 cents (2 are too little) avoid bike shedding . Emule wouldn't have been released at any time if one would have use the approach "we should forecast everything!", it is an iterative method. Just use SF (or the fastest solution that brings the result) and when it does not work it gets moved, the matter is not the source versioning system, but rather enabling others to contribute not only through forum messages.

Otherwise one could engage you about the definition of 'perfect' (1), 'best', etc... and nothing will ever change, apart the confusion.

(1) how could one talk about perfect solution if [a] perfection is not defined, [b] perfection is not reached yet, so whatever comment about it falls short since cannot be perfect and [c] is not proved that the wanted perfection is really reachable or it is just a dream.

[fox88]

Some Support, on 31 March 2016 - 09:30 PM, said:

So right now Bitbucket and Github were suggested.

As the two most well known sites implementing those CVSes.
Here is a bunch of data to get generalized perspective.

This post has been edited by fox88: 01 April 2016 - 10:38 AM

[Xeus32]

Some Support, on 31 March 2016 - 06:30 PM, said:

So right now Bitbucket and Github were suggested.

I'm using both services from long time (2/3 year) and, from my point of view, Github has move functions and it's more common.
Bitbucket is more oriented to the business with private repositories and a lot of function for the company.
Personally I don't have any reason to not suggest Bitbucket (more or less, both services offer the same features for open source projects), but from my personal point of view, VS 2013/5 Comunity has already a extension for Github, so we don't have to install extra package, from the other side, if we want use Github the project must switch on a different SCMS.

[Some Support]

Xeus32, on 01 April 2016 - 02:00 PM, said:

VS 2013/5 Comunity has already a extension for Github, so we don't have to install extra package

I actually wasn't aware of this. This makes a good point for Github. I'll look into setting up a repository there.

[Tuxman]

No, please don't support the misandric and disgusting politics of Github's current owners. There is no reason to do so.

Don't assume that you can't connect Visual Studio to Bitbucket just because someone said you can connect it to Github.

[pier4r]

Tuxman, on 05 April 2016 - 06:16 PM, said:

No, please don't support the misandric and disgusting politics of Github's current owners. There is no reason to do so.

Don't assume that you can't connect Visual Studio to Bitbucket just because someone said you can connect it to Github.

Tuxman you may be right but that attitude of yours is very blocking.

We can do X only if: "Z billions of conditions".
Just do it and maybe drop it later. For how many more years the efforts have to stay on the forum due to your voice and your voice alone?

For the same logic i should drop using your beba immediately due to the quoted post. "No i do not want to encourage the attitude of the dev X". Or as well you should drop emule/p2p because it may be abused to exchange under age porn. One uses the tools, if there are nasty side effects one will change them.

This post has been edited by pier4r: 05 April 2016 - 07:47 PM

[Tuxman]

Feel free to use a different eMule mod if you don't agree with my point of view. The problem is that most eMule mods are worse than beba while the only difference between Github and Bitbucket is that Github is actively enforcing inhuman, anti-male policies.

This post has been edited by Tuxman: 05 April 2016 - 08:07 PM

[xilolee]

Tuxman, on 05 April 2016 - 09:05 PM, said:

anti-male policies.

[pier4r]

Tuxman, on 05 April 2016 - 10:05 PM, said:

Feel free to use a different eMule mod if you don't agree with my point of view. The problem is that most eMule mods are worse than beba while the only difference between Github and Bitbucket is that Github is actively enforcing inhuman, anti-male policies.

you missed the point, maybe due to my bad grammar. Whatever, my message was also directed to others.

PS: i do not know why, but for the way that you argue, maybe it is just my wrong interpretation, i have the perception that you could vote for afd.

This post has been edited by pier4r: 06 April 2016 - 06:24 AM

[Tuxman]

Could you please refrain from arguing ad hominem just because you disagree?

[pier4r]

Tuxman, on 06 April 2016 - 08:30 PM, said:

Could you please refrain from arguing ad hominem just because you disagree?

Hmm that was exposing a perception not an ad hominem. I do not think that perceptions are arguments.
I have no problem to disagree or to agree that we disagree, but that was not the case.