Change 714643 had a related patch set uploaded (by Eileen; author: Eileen):

[wikimedia/fundraising/crm/civicrm@master] Remember location settings

https://gerrit.wikimedia.org/r/714643

Change 714643 merged by Eileen:

[wikimedia/fundraising/crm/civicrm@master] Remember location settings

https://gerrit.wikimedia.org/r/714643

@jgleeson @Ejegg it occurred to me it might be easier just to check civicrm into our main repo & close down the civi repo - like we did with drupal. It's no longer customised - we only have

1. the patch to cope with the symlink (per this issue)
2. temporary patches when we get ahead of core - we could git log this latter as easily from the main repo with git log civicrm

Since we don't actually follow the structure of the upstream repo in our civicrm repo it is already not 'really' it's own repo

In T289100#7373390, @Eileenmcnaughton wrote:

we don't actually follow the structure of the upstream repo in our civicrm repo it is already not 'really' it's own repo

Hmmm sorry for my ignorance, do you have a few more details on this maybe? Is this an ideal path to staying in sync with upstream as much as possible? Thanks much!!

@Eileenmcnaughton the immediate questions I'd have on that proposal are:

1. Will that make pushing new code we add to upstream harder?
2. Will that make pulling in new code from upstream harder?
3. Would we miss the existing repo history associated with the submodule?

Also one last bonus question, what is the mail repo?

Thanks!!!

@jgleeson @AndyRussG it might help if I explain the processes that I currently do with our existing code

updating the code each release steps

1. delete all content from civicrm directory
2. try to remember to undelete civicrm_location_settings.php - the file that handles the symlink
3. unzip the tarball I've downloaded from upstream into the directory
4. commit the contents of the directory
5. check our last few commits to check if anything has not yet been upstreamed and needs to be re-applied
6. try to remember to check if I've accidentally committed removing the file that handles the symlink because if I have civiproxy will break

(this is pretty much the process I do with buildkit too but it doesn't come in a tarball)

Regarding the questions

pushing code to upstream

• this would not change. I use the dmaster site for this & would recommend others do the same. Our current repo isn't a fork of upstream because we commit the contents of the tarball which is actually the compilation of
• civicrm-core repo
• civicrm-packages repo
• civicrm-drupal repo
• compiled packages (composer, bower_components)

pulling in code from usptream

I don't think this would change much for me - others might firnd if confusing? It's already the case you can't 'pull' from usptream. You can cherry-pick even though th e2 repos don't have a shared history. (you generally have to delete tests in the process because our repo is not the same as the upstream)

It would be similar then to our extensions - ie they are not submodules in our repos but locally I have .git directories in those folders which I use to get stuff from upstream but I check in the outcomes of that syncing. WIth CiviCRM I would still always put a .git directory into the local civicrm directory mapped to upstream - it might be a little messier but very do-able I think

submodule history

There really is none now that we are back on stock civicrm. If we threw out all our submodule history today all we would lose is the story uf us unforking CiviCRM

bonus answer
mail repo = main repo + a typo

Thanks for the explanation @Eileenmcnaughton.

I guess the current process with a CiviCRM submodule gives us little benefit vs checking the code in permanently as you propose, so it makes sense to me.

Change 732086 had a related patch set uploaded (by Jgleeson; author: Jgleeson):

[integration/config@master] Remove zuul clone of civicrm as we're gonna check the code in directly to the parent 'crm' project, no longer needing the existing submodule approach, which refers to the zuul cloned repo.

https://gerrit.wikimedia.org/r/732086

@jgleeson your face is on this from last time - but I'm not sure you are really planning on doing it? I'm just trying to think how we best deal with this.

We need to do two things

• check the civicrm repo into our repo
• have the CI repo updated to stop checking it out.

I guess we need them to understand what we want to do first

Change 732086 abandoned by Jgleeson:

[integration/config@master] Remove zuul clone of civicrm

Reason:

https://gerrit.wikimedia.org/r/732086