ERP5: pin neoppod git repository

It was not pinned on 1.0 branch

software/erp5/software.cfg

@@ -5,6 +5,8 @@ extends =
 
 # Test Suite: ERP5-MASTER ran at 2018/03/20 11:19:53.416440 UTC
 #             2 failures, 1 errors, 5815 total, status: FAIL
+# .... and then missing pin for neoppod was added, so the actual status of test
+# is not known, but it I (Jérome) think test status was still FAIL.
 
 [erp5]
 revision = 7d44289405f72336f50a44e545439c6648014688
@@ -13,3 +15,9 @@ revision = 7d44289405f72336f50a44e545439c6648014688
 [cloudooo-repository]
 revision = 0ff799ebcfea1013342f5450e88ff5c3b8536e89
 branch = master
+
+
+[neoppod-repository]
+# 1.9
+revision = 1b57a7ae0566dffc2e37f8b7d1d49e654254d701
+

[Julien Muchembled]

Wrong place because it's possible to request a standalone NEO instance. To be moved to software/neoppod/software-common.cfg

And rather than only tracking releases, I'd prefer if the 1.0 branch specifies the last commit of the master branch. It's enough if the hash is updated at each release of SlapOS.

/cc @jerome @rafael @alain.takoudjou

[Jérome Perrin]

Thanks for the feedback @jm . For the records, this was part of !315 (merged) that was a kind of "emergency" to repair ERP5 tests suite on 1.0 failing again and again.

I was asking myself the same question about where to put the revision. Should the version pin be in the "final" software ( allowing to have standalone NEO and ERP5 use different revision - if it makes sense ) or in the shared part, where the component is actually defined. I added it here because this seemed to be the conventions, cloudoo was also here.

We have a doc about SlapOS Conventions. I believe we should extend it with some conventions for 1.0 branch (unless we have another doc describing the 1.0 process ?)

/cc @rafael @alain.takoudjou

[Rafael Monnerat]

@jerome I think I write the conventions somewhere, but I don't know where they are.

@jm I didn't understood the: "And rather than only tracking releases, I'd prefer if the 1.0 branch specifies the last commit of the master branch. It's enough if the hash is updated at each release of SlapOS." or you didn't understood the purpose of 1.0 branch (release candidate).

[Rafael Monnerat]

@jerome: Here you can learn what we do for release and 1.0 branch: https://www.erp5.com/P-ERP5.Slapos.Repository.Maintainer.Workflows

[Julien Muchembled]

I didn't understood the: "And rather than only tracking releases, I'd prefer if the 1.0 branch specifies the last commit of the master branch. It's enough if the hash is updated at each release of SlapOS." or you didn't understood the purpose of 1.0 branch (release candidate).

I mean that at the time this commit was authored, 3efbbfe3c8684342be23760fd856ef964545252d was the last revision of the NEO master branch and it should have been chosen (rather than the hash pointing to the last NEO release). I didn't know about TestResultModule_getReleaseCandidateRevision: what it returns is exactly what I want so everything's fine.

https://www.erp5.com/P-ERP5.Slapos.Repository.Maintainer.Workflows

Can it be made public ?

[Jérome Perrin]

Now that I know the release procedure, I also agree that I should not have used tag here.

I guess we can wit for next release candidate to correct this.