[tomislav_maric]

@Dominik: all clear, thanks.

Tomislav

[mbeaudoin]

Hello,

Here's my little 2 cents...

First of all, I think we should applaud Dominik for contributing an initial text for the guidelines. The proposition initially put forward is well articulated and concise, something we can work with.

Then, after reading the posts from this thread, I realized that the main development concept being put forward here is still based on a Centralized Repository concept, a concept I think is no longer suitable for this project.

The Centralized Repository concept was fine for a starter, but I would like the project to evolve toward a fully Decentralized Repository workflow concept like the Integration Manager Workflow illustrated here:
http://git-scm.com/book/en/Distribut...nager-Workflow

Under this development workflow, any contributor is responsible for his own public git repository, using whatever site, platform or tools best suited for his development needs or the needs of his team (gitHub, SourceForge, Jira, Git, Mercurial, etc.).
For example, if I want to contribute code to the main developer, I basically contact him with all the information necessary so he can pull my contribution from my public git repo, so he can test and validate my contribution until he feels confident that my code is safe and worth including into the main repos. I don't need write access to his git repo, nor do I want to. He can pull from mine, and host my code under a branch on his repo.

Yes, the main developer from the main repo becomes an integration bottleneck, but hosting my code under my own repo or hosting my code under a branch on the main developer repo will not change this fact. The idea is to have the main developer do the least possible work necessary to integrate contributions, so prepare your contribution accordingly.

The branching model currently put in place (http://nvie.com/posts/a-successful-git-branching-model/) don't need to change, this is basically a very good branching model, but nothing more. We certainly don't need to stick to the centralized repository concept presented there.

As for the pros and cons of moving to a site offering better software engineering tools like Jira, etc, I think the critical mass of collaborating developers to feed those nice little tools is still not there in my opinion. But I would love to be proven wrong here...

But if your team needs those tools to contribute to the foam-extend source code, please go ahead, have your team hosted over Atlassian or gitHub or where ever you feel comfortable, do whatever software engineering wizardry you need to provide good code, and then contribute your stuff back to the main developer who will do the final integration. The Decentralized Repository workflow is well suited for this. I think good contributions is still way more valuable for this project than the tools you will be using to generate/manage your code.

As for SourceForge.Net, I would like to offer a few complementary points of view.

• SourceForge.Net is hosting over 430,000 projects, with over 3.7 millions registered user, serving over 4,800,000 downloads a day. https://sourceforge.net/about. This is quite significant.

• SourceForge.Net has been serving the OpenSource community for many years, and went through a major restructuration at least once. This site is mature, it is not a flash in the pan.

• SourceForge.Net is free

• SourceForge.Net is offering more than one SCM software, including Git and Mercurial, and yes, Subversion. Lots of freedom here. One particular developer I know prefers Mercurial over GIT. His code is very valuable to the community. So Mercurial is very valuable for the community too. Again, contributions over tools...

• SourceForge.Net is offering lots of storage space for free. We can host a duplicate of all the presentations from all the past OF Workshops, no question asked, and for FREE. Over 34,000 downloads for the past year, only for the OFWs presentations alone. Lots of bandwidth and lots of storage space for FREE.

• SourceForge.Net is offering Web space/services for deploying our own Web application for FREE. The test loop I have developed for foam-extend has a CDash server waiting for you on SourceForge.NET, and it is FREE and open to anyone who wants to use it : http://openfoam-extend.sourceforge.net/CDash/index.php. We can deploy additional Web services if necessary, the LAMP environment is there and ready to use.

• So I don't think it is fair to dismiss SourceForge.Net as a mere Subversion site; it is much more than that.

• But yes, SF.Net is lacking some shiny software engineering/collaborating/professional tools like Jira. But how do the other sites compare on the other aspects?

• I think we should not dismiss SourceForge.Net so quickly until we look at ALL the pros and cons.

But again, switching to a fully Decentralized Repository workflow render this discussion about SF.Net rather moot since the public site hosting the main repository can be quite different from the sites where people will be collaborating and building their contributions; it doesn't and shouldn't matter...

Hope this helps.

Martin

[tomislav_maric]

@mbeaudoin: I agree completely with you with respect to the openness of the development model. Also, I am not on a crusade for github/bitbucket, just to make that clear...

The only question that remains when the development is revolving around sourceforge is if the site supports forks easily and in an advanced way that makes collaborative work easy, like github/bitbucket actually do. The other characteristics of the sites are more/less same (no cost, huge amount of other projects, etc).

I mean, with the Distributed Workflow model that you proposed (Integration Manager Workflow), it is clear that the site needs to support forks since the users will have their own public repos (which is what I have pointed out in my previous posts). From the link you have provided (I've added italics):

Integration-Manager Workflow


.... snipped ...

This is a very common workflow with sites like GitHub, where it’s easy to fork a project and push your changes into your fork for everyone to see. One of the main advantages of this approach is that you can continue to work, and the maintainer of the main repository can pull in your changes at any time.

And there is nothing standing in the way of having multiple integration managers, so the bottleneck could be significantly reduced..

[mbeaudoin]

Hello Tomislav,

> The only question that remains when the development is revolving around sourceforge is if the site supports forks easily

Yes it does. See the little "Fork" button here : http://sourceforge.net/p/openfoam-ex...ci/master/tree

All you need is an account on SourceForge.Net, which is very easy to get.

Once you have forked your project, see the little button "Request Merge" available from the project page of your new project.

And your forked project becomes public as well, so you can share your code as you wish.

> and in an advanced way that makes collaborative work easy

I have no clue here on how "advanced" this is for collaborative work. I am forking my projects the old fashion way using git, and using Email to communicate with project maintainers. Works for me.

Martin

[tomislav_maric]

Hi Martin,

the only difference between sourceforge+email and github/bitbucket AFAIK is then in using emails instead of some web frontend that allows code highlighting and comments.

If sourceforge + emails have worked so far and since sourceforge supports forks, then there's no need to change anything from the technical side.

Tomislav

[dominik_christ]

Hi all,

big thanks to everyone who contributed to the discussion!

I try to summarize the major points:

1) The centralized repository structure should be replaced with a github-like fork-and-merge system. This can be achieved with the existing platform on SourceForge.

2) Regarding the person who is doing the merging of code, various approaches have been proposed: A rather restricted one, where the project head is the only one doing merges (similar to linux kernel development model) and a rather wide one, where an experienced code contributor would perform the merge. Aspects to consider are work load on project head/admins, growing the number of capable people and maintaining good quality of the code.

3) Contributions and merges must be well documented/announced. This would probably require adding or restructuring sub-forums on cfd-online, which may also include changes for topics on a wider scope.

4) In general, various alternative platforms were suggested (e.g. github, Jira). The argument was raised to use existing software platforms as far as they fulfil the needs and only consider a switch if we find we require additional functionality that we cannot get otherwise.

5) We all want a free and open public software development model that is based on a large active user community. The project guidelines should contain a clear commitment to this.

Thanks to Tomislav for putting his ideas into the Project Guidelines Draft on the wiki. I will make some further alterations to accommodate the points above. If you find some points under-represented, please post here and be sure to include concrete additional or alternative text (so please avoid any: "I would like..."/"I don't like how..."/"Someone should...").

The result will constitute the preliminary project guidelines and I'm really exited that we are going further on this way!

Best regards,
Dominik