How to handle commit to "core applications"

[RiccardoRossi]

we need to decide a policy for commits to core applications.

let's suppose for example that we need to create a new element, which we need for research purposes. this element may not be of sufficient quality to be exposed to the general public, nevertheless it may well be needed during a long period of time as part of the thesis of someone.

creating a branch would not be the way to go, since this is designed to be long-living. i really would like to avoid forks.

what should be the guideline here? to create a derived application and to work on that as we did until now? problem here is that the (eventual) merging to the core application is very manual.

cheers Riccardo

[pooyan-dadvand]

Good question! I think that it should go to a new repository called KratosLab which would be for such an applications. Now the important detail would be how we work there. I can imagine two options:

• Having a separate App based on the core one like what we have
• Creating a fork of the core app there in the new repo and keep synchronising the Lab one with the changes in the core.

@KratosMultiphysics/technical-committee any comment?

[maceligueta]

If the second bullet point of Pooyan's comment improves the merging process (not so 'manual', as stated by Riccardo) I would go for this option 100%. It's just that I am not aware if it is really possible.

[josep-m-carbonell]

Hello everybody, I think that a list of the core applications would be useful to know what we are talking about. After thinking a little bit about the most suitable workflow for these applications, the second option proposed by Pooyan seems quite good. If it is possible, as pointed out by Miquel Angel.

Git is quite complex compared with svn. Could you explain me why we must avoid forks ?

[RiccardoRossi]

well,

i see the advantages of having long lived "branches" (forks). however i believe that this mechanism allows too much drifting apart, and this is something that we should not push, particularly not within our students.

also, i am not clear of how a fork would it be. Are we sure that only an application can be forked? what happens to the other applications? and to the core?

Riccardo

On Wed, Feb 15, 2017 at 1:06 AM, Josep Maria notifications@github.com wrote:

Hello everybody, I think that a list of the core applications would be useful to know what we are talking about. After thinking a little bit about the most suitable workflow for these applications, the second option proposed by Pooyan seems quite good. If it is possible, as pointed out by Miquel Angel.

Git is quite complex compared with svn. Could you explain me why we must avoid forks ?

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/KratosMultiphysics/Kratos/issues/13#issuecomment-279876913, or mute the thread https://github.com/notifications/unsubscribe-auth/AHr7EV3ZlElAz4c_U9hjTBMtq1OZLYuwks5rckFqgaJpZM4MAS0U .

--

Riccardo Rossi

PhD, Civil Engineer

member of the Kratos Team: www.cimne.com/kratos

Tenure Track Lecturer at Universitat Politècnica de Catalunya, BarcelonaTech (UPC)

Full Research Professor at International Center for Numerical Methods in Engineering (CIMNE)

C/ Gran Capità, s/n, Campus Nord UPC, Ed. B0, Despatx 102

(please deliver post to the porters of building C1)

08034 – Barcelona – Spain – www.cimne.com -

T.(+34) 93 401 56 96 skype: rougered4

http://www.cimne.com/

https://www.facebook.com/cimne http://blog.cimne.com/ http://vimeo.com/cimne http://www.youtube.com/user/CIMNEvideos http://www.linkedin.com/company/cimne https://twitter.com/cimne

Les dades personals contingudes en aquest missatge són tractades amb la finalitat de mantenir el contacte professional entre CIMNE i voste. Podra exercir els drets d'accés, rectificació, cancel·lació i oposició, dirigint-se a cimne@cimne.upc.edu. La utilització de la seva adreça de correu electronic per part de CIMNE queda subjecte a les disposicions de la Llei 34/2002, de Serveis de la Societat de la Informació i el Comerç Electronic.

Imprimiu aquest missatge, només si és estrictament necessari. http://www.cimne.com/

[loumalouomega]

@KratosMultiphysics/technical-committee I think we have to many issues, and people is not closing them, and the number is increasing everyday. If the decision is taken them add it to the wiki and close this issue.

I don't want to look cranky, is just for the best for the community.

[jcotela]

@loumalouomega This one is an important practical issue and will be very relevant going forward. I would keep it open as long as it takes to reach a consensus.

On topic: I think long-term development should go to specific applications in the Labs. Now, regarding the issue of forking versus creating new developments on new applications, then moving them to the core one when they are ready, I can see advantages and problems to both points of view.

Forking will make it easy to merge back the changes once the new developments are done but, in my opinion, it also makes it easy for the forked application and the original one to drift apart.

Making a new application (possibly dependent on the core one?) is probably a better fit to the proposed Labs, but I'm not sure if it will be so easy to move back developments to the core applications. I suspect it will be a manual procedure... Also, do we know for sure if we can preserve the history of the new file when doing this kind of move?

[loumalouomega]

@jcotela I know this is an important issue, but the last comment was from 2 weeks ago, maybe we need something to keep long term discussions, like the project.

The thing is that if the number of issues is to high, people is going to avoid to take a look in any of them , it is called paradox of choice, where the people is not able to concentrate and take a decision when higher is the number of parameters to consider

[jcotela]

We (@RiccardoRossi, @pooyan-dadvand and me) have been discussing this issue and we have convinced ourselves that having forks of core applications in the Labs would not be ideal. It seems that maintaining the two forks (and porting changes from one to the other) would be rather impractical. Another potential problem is related to what would happen if two different students want to develop for the same application: can we (and shoud we?) maintain two separate forks of the application?

We are currently under the impression that the best way to host long-term development of new capabilities would be to place them on a separate application in the Labs. If/when they are finished and robust enough to be considered for inclusion in one of the core applications, the relevant files will be moved from the lab to the core application.

We also identified a separate scenario: core features that require a long development time (think important modifications of the ModelPart or variable containers). These would not go the Labs, because we would prefer not to replicate the entire core in a fork, but we are considering to allow forks or long-lived branches to develop such features.

[maceligueta]

Looks reasonable, no objections! @loumalouomega : about the number of open issues, there is a lot of work to do, and most of us are not dedicating full time to solve them. We have our own applications, projects, etc... So I would not be surprised if the number of issues grows much more. Just think of the list in Producteev for a second, which we didn't migrate to Github yet. Maybe we should assing each issue to a person, who takes care of it for as long as he/she can, the assignee can be changed when the issue evolves. Then, the number of issues per person would not be that big.

[ddemidov]

I don't think there is much difference between branches and forks in git from the technical standpoint. A fork is just a collection of branches that has separate access control. After all, each one of your clones is a complete and independent copy of the main repository, so it may be considered a 'fork' as well. A big advantage of using forks is that you don't have to give a student write access to the main repo, so that their contributions have to go through pull requests and code review.

Merging changes in git is easy, and would be even easier if students fetch changes from the main repo often and rebase their topic branch on the main development branch regularly. So that when they finally make a pull request, it results in a conflict-free fast-forward merge.

Even if they do rebase regularly, a single huge pull-request at the end of the year could be difficult to review, so it could be easier if the work could be split into smaller chunks, each of those merged individually through a separate pull request.

Having a separate KratosLab repository could result in the same problem: it can eventually diverge too much from the main repo.

[msandre]

In terms of manageability it appears to me like trying to maintain forked repos so they don't drift apart could in the end be more work than simply having derived experimental apps and gradually migrating selected features in smaller pieces into stable apps. I think a few guidelines for deriving experimental apps from core apps could greatly ease future migration. I also think it would be good practice to make working tests a prerequisite for any migration to core apps. Once the feature is flagged for migration, a branch could be started. In order for the pull request from branch to core to be approved, the migrated tests must pass.

In the case of developments in the core, what would be the advantage of long-lived forks compared to incremental updates through short-term branches?

[jcotela]

The issue with long-lived branches/forks comes because a few of the planned improvements to the core have longer development times, might have wide-ranging effects to the code or require collaboration between multiple developers. We need some kind of mechanism to ensure that they are tested and reasonably bug-free before they are pushed to the master branch, and forks sounded like one of the possibilities.

[pooyan-dadvand]

@ddemidov Thanks for your comment and clarifying the technical details I needed.

In my opinion the new applications (with a new objectives) are the obvious case to start in KratosLab and added to the Kratos when they pass some quality issue.

As @jcotela mentioned the problem is the experimental new things in core apps (like testing a new fluid formulation) Then we have following approaches:

• Working on a long life branch as @RiccardoRossi proposed (Am I right?)
• Creating a "derived" application in KratosLab as suggested by @msandre

• Making a fork as suggested by Denis. Here my question is what would be the guideline here: To create a fork in our personal accounts? or having them in KratosMultiphysics by different names? What is the common practice here? @ddemidov would you please give us your opinion on this?

  I should add that I mostly agree with the Denis' solution.

[ddemidov]

To create a fork in our personal accounts? or having them in KratosMultiphysics by different names?

I think it would be clearer and easier to control access permissions if the forks were in personal accounts. Also, when you fork into the same account as the original repo, you have a naming problem.

[pooyan-dadvand]

Discussing it in technical committee the changes to the core and core applications will be applied directly to the main repository. Now the question would be if to move the application_labs to a separate repository or only to a separate directory inside.

[RiccardoRossi]

closing as stale. We'll reopen when relevant again