Hi Cedric, Inline…
From: Cedric OLLIVIER <ollivier.ced...@gmail.com> Date: Monday, September 11, 2017 at 10:31 PM To: "Alec Hothan (ahothan)" <ahot...@cisco.com> Cc: "Beierl, Mark" <mark.bei...@dell.com>, Alexandru Avadanii <alexandru.avada...@enea.com>, opnfv-project-leads <opnfv-project-le...@lists.opnfv.org>, "opnfv-tech-discuss@lists.opnfv.org" <opnfv-tech-discuss@lists.opnfv.org>, Fatih Degirmenci <fatih.degirme...@ericsson.com> Subject: Re: [opnfv-project-leads] [opnfv-tech-discuss] [release][euphrates] stable branch window Alec, My comment simply highlighted a possible issue. You can simply trigger it via Doctor by setting version = 5 in its setup.cfg I precise doctor offers 2015.1.0 as tag. https://git.opnfv.org/doctor/tag/?h=2015.1.0 Then you can simply call python setup.py install or pip install . ValueError: git history requires a target version of pbr.version.SemanticVersion(2015.1.1), but target version is pbr.version.SemanticVersion(5.0.0) As releng/modules version is 5.0, I think the same updated tag (eg 2017.09) would break the rules. [Alec] OK I think I understand what you mean now. I see that the doctor git repo has quite a rocky tagging history, starting with 2015.1.0, then using danube.3.0 notation and now having to change again on possibly a 5.0.0 notation. I also see that setup.cfg currently sets the metadata version to 2017.9.0 I don’t want to pick on doctor project but this really shows the downside of trying to unify an overarching integration project release (in our case OPNFV release) and its constituents versioning. As a side note, I personally prefer to omit the version field in setup.cfg and let pbr derive the version directly from the git tagging - but of course this requires you can tag your versions with “2017.9.0” which indeed would conflict with an hypothetical OPNFV “5.0.0” tag (pbr would not know which one to pick since both are semver syntax compliant). When cleaning the requirements of OPNFV projects, I simply set 5 as default version value (all projects are free to modify that) as euphrates is an incorrect python package version. https://wiki.opnfv.org/display/functest/Requirements+management [Alec] How to manage dependencies across packages is an interesting and challenging problem but I’d like to focus on the OPNFV project versioning first – and hopefully find a good solution that works for everybody. By the way, I think we can hardly compare OPNFV and FD.io as the last one is java based (packaging and distributions are done via mvn). [Alec] Sorry I was merely pointing to the analogy of using a year and month as versioning. But it's fine to compare with OpenStack projects as we are now following quite their package rules. [Alec] I’m not familiar yet on who does what, are you part of the doctor team? Would you agree to a solution that allows projects to tag their repo using their own semver versioning (such as 2017.9.0) and tag OPNFV releases using a prefix such as opnfv-5.0.0 (which will be conveniently ignored by pbr)? That is what I am trying to get to with all these emails ;-) I will also take it that you are not in favor of tagging OPNFV release with “5.0.0”. Thanks Alec Cédric 2017-09-11 23:53 GMT+02:00 Alec Hothan (ahothan) <ahot...@cisco.com<mailto:ahot...@cisco.com>>: Cedric, How to tag is a completely separate discussion and I’m actually very glad that you bring this up along with pbr ;-) But I’m curious why you bring up the “2017.09” example as it is not a semver tag and would not be recognized by pbr? For example, FD.io/VPP uses year/month to tag their releases (e.g. 17.04) OpenStack does not impose any tagging on constituent projects (that would cause a revolt from component owners I can guarantee that) Semver tagging has been so far always reserved to individual component tagging. I am currently feeling pretty uneasy with the looming E release and its tagging implication which could put all of us in a hole. If we don’t do anything, we will see “5.0.0” tags on every repo in OPNFV and that should be a cause for concern for every project owner. I am sorry to repeat myself but I don’t think everyone has grasped yet the implication that has on how projects should version their code and how they can manage their artifacts starting from Euphrates. Let me clarify again, I am not questioning the lock-step versioning that is in effect in Euphrates but a far more damaging decision would be to tie the OPNFV release version to semver tagging and hijack semver tagging for the purpose of OPNFV releases versioning (e.g. slap tags like “5.0.0” on every repo). I would prefer if we could keep an OPNFV prefix for the tags. That was perfect pre E release (dabube-1.0.0…). For Euphrates, if we do not want to see the release name (understandably as it is redundant to the release version) at least keep an opnfv prefix in front of it for the tags (e.g. “opnfv-5.0.0”) so that project owners can version independently of the OPNFV release using semver compatible tags (like virtually every other open source project out there) Regards, Alec From: Cedric OLLIVIER <ollivier.ced...@gmail.com<mailto:ollivier.ced...@gmail.com>> Date: Monday, September 11, 2017 at 1:38 PM To: "Alec Hothan (ahothan)" <ahot...@cisco.com<mailto:ahot...@cisco.com>> Cc: "Beierl, Mark" <mark.bei...@dell.com<mailto:mark.bei...@dell.com>>, Alexandru Avadanii <alexandru.avada...@enea.com<mailto:alexandru.avada...@enea.com>>, opnfv-project-leads <opnfv-project-le...@lists.opnfv.org<mailto:opnfv-project-le...@lists.opnfv.org>>, "opnfv-tech-discuss@lists.opnfv.org<mailto:opnfv-tech-discuss@lists.opnfv.org>" <opnfv-tech-discuss@lists.opnfv.org<mailto:opnfv-tech-discuss@lists.opnfv.org>>, Fatih Degirmenci <fatih.degirme...@ericsson.com<mailto:fatih.degirme...@ericsson.com>> Subject: Re: [opnfv-project-leads] [opnfv-tech-discuss] [release][euphrates] stable branch window I think it could hurt only if you select 2017.09 as tag. I precise pbr compares version (eg 5.0) and tags then it would break the python package. Cédric 2017-09-11 17:20 GMT+02:00 Alec Hothan (ahothan) <ahot...@cisco.com<mailto:ahot...@cisco.com>>: Fatih mentioned that changes in F would be in a different repo after the reorganization of the releng repo – so branching releng would technically not be needed for Euphrates? In any case, it does not hurt to tag (I was surprised tags were not used more often in OPNFV repos to mark internal versions…) Alec From: <opnfv-project-leads-boun...@lists.opnfv.org<mailto:opnfv-project-leads-boun...@lists.opnfv.org>> on behalf of "Beierl, Mark" <mark.bei...@dell.com<mailto:mark.bei...@dell.com>> Date: Monday, September 11, 2017 at 6:31 AM To: Alexandru Avadanii <alexandru.avada...@enea.com<mailto:alexandru.avada...@enea.com>> Cc: opnfv-project-leads <opnfv-project-le...@lists.opnfv.org<mailto:opnfv-project-le...@lists.opnfv.org>>, Cedric OLLIVIER <ollivier.ced...@gmail.com<mailto:ollivier.ced...@gmail.com>>, "opnfv-tech-discuss@lists.opnfv.org<mailto:opnfv-tech-discuss@lists.opnfv.org>" <opnfv-tech-discuss@lists.opnfv.org<mailto:opnfv-tech-discuss@lists.opnfv.org>> Subject: Re: [opnfv-project-leads] [opnfv-tech-discuss] [release][euphrates] stable branch window +1. Would not want changes to the opnfv-docker.sh script for F to impact building of E maintenance releases. Regards, Mark Mark Beierl SW System Sr Principal Engineer Dell EMC | Office of the CTO mobile +1 613 314 8106 mark.bei...@dell.com<mailto:mark.bei...@dell.com> On Sep 11, 2017, at 09:26, Alexandru Avadanii <alexandru.avada...@enea.com<mailto:alexandru.avada...@enea.com>> wrote: Hi, How about tagging releng, without branching it? Alex -----Original Message----- From: opnfv-tech-discuss-boun...@lists.opnfv.org<mailto:opnfv-tech-discuss-boun...@lists.opnfv.org> [mailto:opnfv-tech-discuss- boun...@lists.opnfv.org<mailto:boun...@lists.opnfv.org>] On Behalf Of Cedric OLLIVIER Sent: Monday, September 11, 2017 7:51 AM To: David McBride Cc: opnfv-project-leads; TECH-DISCUSS OPNFV Subject: Re: [opnfv-tech-discuss] [release][euphrates] stable branch window Hello, Could you please confirm that no stable/euphrates branch will be created for releng again? Else we are obliged to select a specific git commit id to build our Functest stable containers which is not the best way. I precise Functest depends on the opnfv python package which is hosted by releng (https://git.opnfv.org/releng/tree/modules). Cédric 2017-09-09 1:24 GMT+02:00 David McBride <dmcbr...@linuxfoundation.org<mailto:dmcbr...@linuxfoundation.org>>: Reminder... The stable branch window closes as of MS7, one week from today, on September 15 at 12 p.m. (PT). PTLs - please contact Aric as soon as you're ready to branch. Aric will branch any projects that have not already been branched on Sept 15. Let me know if you have any questions. David On Tue, Aug 29, 2017 at 3:23 PM, David McBride <dmcbr...@linuxfoundation.org<mailto:dmcbr...@linuxfoundation.org>> wrote: Team, As you know, MS6 was this past Friday, Aug 25. In addition to the requirements associated with MS6, this milestone also marks the opening of the stable branch window, which subsequently ends with MS7 on Sept 15. This means that PTLs may request to branch their project any time before Sept 15. Note that I erroneously told the release meeting this morning that PTLs may create their own branch. That's not the case. Instead, please contact Aric (copied) and request that he create the branch for you. Also, as a reminder, we have changed the version number format as of the Euphrates release. 5.0.0 - Euphrates initial release version 5.1.0 - Euphrates SR1 5.2.0 - Euphrates SR2 Let me know if you have any questions. David -- David McBride Release Manager, OPNFV Mobile: +1.805.276.8018 Email/Google Talk: dmcbr...@linuxfoundation.org<mailto:dmcbr...@linuxfoundation.org> Skype: davidjmcbride1 IRC: dmcbride -- David McBride Release Manager, OPNFV Mobile: +1.805.276.8018 Email/Google Talk: dmcbr...@linuxfoundation.org<mailto:dmcbr...@linuxfoundation.org> Skype: davidjmcbride1 IRC: dmcbride _______________________________________________ opnfv-tech-discuss mailing list opnfv-tech-discuss@lists.opnfv.org<mailto:opnfv-tech-discuss@lists.opnfv.org> https://lists.opnfv.org/mailman/listinfo/opnfv-tech-discuss _______________________________________________ opnfv-tech-discuss mailing list opnfv-tech-discuss@lists.opnfv.org<mailto:opnfv-tech-discuss@lists.opnfv.org> https://lists.opnfv.org/mailman/listinfo/opnfv-tech-discuss _______________________________________________ opnfv-tech-discuss mailing list opnfv-tech-discuss@lists.opnfv.org<mailto:opnfv-tech-discuss@lists.opnfv.org> https://lists.opnfv.org/mailman/listinfo/opnfv-tech-discuss
_______________________________________________ opnfv-tech-discuss mailing list opnfv-tech-discuss@lists.opnfv.org https://lists.opnfv.org/mailman/listinfo/opnfv-tech-discuss
