This was merged, and the RPM is in the snapshots repository. Therefore, you do not need to add the tested-master repo as I mentioned in the original thread. (See https://gerrit.ovirt.org/#/c/72352/ for more info on that, if you're interested.)
Please don't hesitate to contact me if you see anything strange with the UI. Thanks, Greg On Tue, Feb 14, 2017 at 1:59 PM, Greg Sheremeta <gsher...@redhat.com> wrote: > Does anyone have any other input or objections about anything *other than* > which repos we're using? > > Best wishes, > Greg > > > On Tue, Feb 14, 2017 at 7:11 AM, Sandro Bonazzola <sbona...@redhat.com> > wrote: > >> >> >> On Tue, Feb 14, 2017 at 10:14 AM, Martin Perina <mper...@redhat.com> >> wrote: >> >>> >>> >>> On Tue, Feb 14, 2017 at 9:54 AM, Barak Korren <bkor...@redhat.com> >>> wrote: >>> >>>> On 14 February 2017 at 09:53, Martin Perina <mper...@redhat.com> wrote: >>>> > >>>> > >>>> > On Mon, Feb 13, 2017 at 9:59 PM, Greg Sheremeta <gsher...@redhat.com> >>>> wrote: >>>> >> >>>> >> On Mon, Feb 13, 2017 at 3:55 PM, Eyal Edri <ee...@redhat.com> wrote: >>>> >>> >>>> >>> >>>> >>> >>>> >>> On Mon, Feb 13, 2017 at 10:34 PM, Martin Perina <mper...@redhat.com >>>> > >>>> >>> wrote: >>>> >>>> >>>> >>>> Hi, >>>> >>>> >>>> >>>> why is this package not contained also in ovirt-master-snapshot >>>> >>>> repository [6]? Most of developers are using >>>> ovirt-master-snapshot, because >>>> >>>> this is the official repository for oVirt depelopers as mentioned >>>> in [7] and >>>> >>>> [8]. AFAIK there was not yet any official announcement that every >>>> developer >>>> >>>> should switch from ovirt-master-snapshot to ovirt-tested-master ... >>>> >>> >>>> >>> >>>> >>> I think we should make it official then for master, we've hit too >>>> many >>>> >>> issues in the past weeks due to this repository, that I don't want >>>> to see >>>> >>> new projects added to it. >>>> > >>>> > >>>> > You've run into issues, because >>>> > >>>> > migration to the "new" system is not well prepared. I'm still a bit >>>> angry >>>> > that you have forced me to migrate all ovirt-engine-extensions* >>>> projects >>>> > into standard CI (which took me more than 2 days) by breaking >>>> existing build >>>> > jobs which worked fine until recent changes. And I had to do fast that >>>> > otherwise I won't be able to provide new build for upstream 4.1.0 >>>> async and >>>> > 4.1.1 builds ... >>>> >>>> I think there is some miss-communication here. The old '-snapshot' >>>> repo is causing issues because of the way it is built. We want people >>>> to move away from it. However, we did not intend to force anyone to >>>> move. It is still there, and the nightly jobs still update it with all >>>> the packages that have been in it so far. >>>> >>>> http://jenkins.ovirt.org/job/ovirt_master_publish-rpms_nightly/ >>>> >>>> I really don't see how any of the recent changes forced you to change >>>> your project's own jobs, but it is a good thing if you did. >>>> >>> >>> Well, build jobs just started to fail and I discussed with either you >>> or Gil and you just told me that why it's failing and the only solution is >>> to move std CI. >>> But let's leave this behind us, >>> >>> ovirt-engine-extensions* move to std-CI and build jobs are working now >>> correctly ... >>> >>> >>>> > So I don't have an issue to move from ovirt-master-snapshot repos to >>>> > ovirt-tested-master repos, but please do that properly: >>>> > >>>> > 1. Announce on mailing lists that every developer should switch at >>>> least a >>>> > week before the change >>>> >>>> We were planning, since all repos currently exist side-by-side we saw >>>> no rush to do that. >>>> >>>> > 2. Update all developer related documentation about this change >>>> >>>> Well, I'm not sure where such things are documented currently, but >>>> that is a reasonable request. >>>> >>>> > 2. Maintain both repos for a week and only after that turn off >>>> > ovirt-master-snapshots repos >>>> >>>> We did not turn it off yet. It is still there. The only thing that >>>> happened is that the new JS projects, that were never in that repo to >>>> begin with, chose to forgo publishing to it. >>>> >>> >>> Sure, that's why I asked to put this ovirt-js-dependencies package into >>> ovirt-master-snapshot repo, which all developers are using ... >>> >>> >>> >>>> >>>> > Exported artifacts is not enough, please provide >>>> ovirt-release-tested-master >>>> > RPM which will include all necessary repositories same way as we >>>> currenlty >>>> > have in ovirt-release-master >>>> >>>> There is some subtle distinction here that needs to be well understood. >>>> Some repos are build to emulate an oVirt release, and all or most of >>>> the packages are collected in them. The 'tested' repo is an example of >>>> such a repo. For such repos it makes sense to create a >>>> '*-release-*.rpm'. >>>> >>> >>> So ovirt-release-master RPM will add repositories with needed packages >>> to develop engine/VDSM. For engine development it means you have following >>> packages: >>> >>> ovirt-master-snapshot: >>> otopi >>> ovirt-host-deploy >>> ovirt-setup-lib >>> ovirt-vmconsole >>> >>> ovirt-master-snapshot-static >>> ovirt-engine-wildfly >>> ovirt-engine-wildfly-overlay >>> >>> ovirt-master-patternfly1-noarch-epel >>> patternfly1 >>> >>> There are other packages, but those are needed only when developing >>> relevant parts of engine (for example "unboundid-ldapsdk" needed for >>> ovirt-engine-extension-aaa-ldap). >>> >>> So in my opinion if you want to switch to ovirt-latest-tested repo, we >>> need to have available also those dependencies, that's why I think it's >>> required to have ovirt-release-latest-tested RPM which will install all >>> repos to develop and even install/run master oVirt from RPM. >>> >>> >> Make sense to me. Current effort anyway it to reach a point where nothing >> need to be changes, just the content of ovirt-master-snapshot will be >> genertared from latest-tested instead of from jenkins master nightly >> publisher job. >> >> >> >>> >>>> The 'exported-artifacts' repos are meant to allow "upstream" or >>>> "build-dependency" projects to have their own release stream that is >>>> independent of oVirt's release stream. For such repos it makes little >>>> sense to keep a '*-release-*.rpm'. >>>> >>>> All projects that have a 'build-articats job now have an >>>> 'exported-artifacts' repo and their packages are submitted to OST so >>>> eventually also end up in the 'tested' repo. It is left to the >>>> consuming projects to pick which repo to use depending on how tightly >>>> are they coupled with consumed packages. >>>> >>>> >>>> -- >>>> Barak Korren >>>> bkor...@redhat.com >>>> RHCE, RHCi, RHV-DevOps Team >>>> https://ifireball.wordpress.com/ >>>> >>> >>> >>> _______________________________________________ >>> Devel mailing list >>> Devel@ovirt.org >>> http://lists.ovirt.org/mailman/listinfo/devel >>> >> >> >> >> -- >> Sandro Bonazzola >> Better technology. Faster innovation. Powered by community collaboration. >> See how it works at redhat.com >> >> _______________________________________________ >> Devel mailing list >> Devel@ovirt.org >> http://lists.ovirt.org/mailman/listinfo/devel >> > > > > -- > Greg Sheremeta, MBA > Red Hat, Inc. > Sr. Software Engineer > gsher...@redhat.com > -- Greg Sheremeta, MBA Red Hat, Inc. Sr. Software Engineer gsher...@redhat.com
_______________________________________________ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
