code merges in ovirt-engine repo
Hi all, we’re moving to 4.4.z development now and we need to keep a closer eye on automation results and making sure the build is not broken. For these reasons we’re considering moving to a similar model as vdsm, having a smaller set of people with merge rights to make sure the patches get in in the right order and they meet our sanity standards (OST, bug’s TM) Any objections/comments? Thanks, michal
On Tue, Jul 14, 2020 at 11:43 AM Michal Skrivanek <michal.skrivanek@redhat.com> wrote:
Hi all, we’re moving to 4.4.z development now and we need to keep a closer eye on automation results and making sure the build is not broken. For these reasons we’re considering moving to a similar model as vdsm, having a smaller set of people with merge rights to make sure the patches get in in the right order and they meet our sanity standards (OST, bug’s TM) Any objections/comments?
Any reason to not simply branch 4.4? And have the branch maintained by the stable branches maintainers? -- Didi
On 14 Jul 2020, at 12:11, Yedidyah Bar David <didi@redhat.com> wrote:
On Tue, Jul 14, 2020 at 11:43 AM Michal Skrivanek <michal.skrivanek@redhat.com> wrote:
Hi all, we’re moving to 4.4.z development now and we need to keep a closer eye on automation results and making sure the build is not broken. For these reasons we’re considering moving to a similar model as vdsm, having a smaller set of people with merge rights to make sure the patches get in in the right order and they meet our sanity standards (OST, bug’s TM) Any objections/comments?
Any reason to not simply branch 4.4? And have the branch maintained by the stable branches maintainers?
just the sheer amount of backports needed (every patch). Doesn’t sound worth the effort of posting and reviewing(even if just formally) everything twice.
-- Didi
On Tue, Jul 14, 2020 at 4:21 PM Michal Skrivanek < michal.skrivanek@redhat.com> wrote:
On 14 Jul 2020, at 12:11, Yedidyah Bar David <didi@redhat.com> wrote:
On Tue, Jul 14, 2020 at 11:43 AM Michal Skrivanek <michal.skrivanek@redhat.com> wrote:
Hi all, we’re moving to 4.4.z development now and we need to keep a closer eye
on automation results and making sure the build is not broken. For these reasons we’re considering moving to a similar model as vdsm, having a smaller set of people with merge rights to make sure the patches get in in the right order and they meet our sanity standards (OST, bug’s TM)
Any objections/comments?
Any reason to not simply branch 4.4? And have the branch maintained by the stable branches maintainers?
just the sheer amount of backports needed (every patch). Doesn’t sound worth the effort of posting and reviewing(even if just formally) everything twice.
If you expect _every_ patch to be backported, just do nothing - let current maintainers do their job, and revert the occasional bad ones when needed. Otherwise, I think branching is a good approach.
-- Didi
-- Didi
On 14 Jul 2020, at 15:33, Yedidyah Bar David <didi@redhat.com> wrote:
On Tue, Jul 14, 2020 at 4:21 PM Michal Skrivanek <michal.skrivanek@redhat.com <mailto:michal.skrivanek@redhat.com>> wrote:
On 14 Jul 2020, at 12:11, Yedidyah Bar David <didi@redhat.com <mailto:didi@redhat.com>> wrote:
On Tue, Jul 14, 2020 at 11:43 AM Michal Skrivanek <michal.skrivanek@redhat.com <mailto:michal.skrivanek@redhat.com>> wrote:
Hi all, we’re moving to 4.4.z development now and we need to keep a closer eye on automation results and making sure the build is not broken. For these reasons we’re considering moving to a similar model as vdsm, having a smaller set of people with merge rights to make sure the patches get in in the right order and they meet our sanity standards (OST, bug’s TM) Any objections/comments?
Any reason to not simply branch 4.4? And have the branch maintained by the stable branches maintainers?
just the sheer amount of backports needed (every patch). Doesn’t sound worth the effort of posting and reviewing(even if just formally) everything twice.
If you expect _every_ patch to be backported
yes
, just do nothing - let current maintainers do their job, and revert the occasional bad ones when needed.
And how would you prevent breaking the relatively frequent updates? The CI OST is not working very well (for a long time now) and while we are improving and stabilizing the infrastrucure it’s not really there yet to consider automated gating. Engine is unique in oVirt set of projects, it’s the largest one by far and use maintainership per team or area (FE, BE, database, API…) and so we have a pretty high number of people merging patches but far less people keeping up to date with the project’s planning.
Otherwise, I think branching is a good approach.
-- Didi
-- Didi
On Tue, Jul 14, 2020 at 4:05 PM Michal Skrivanek < michal.skrivanek@redhat.com> wrote:
On 14 Jul 2020, at 15:33, Yedidyah Bar David <didi@redhat.com> wrote:
On Tue, Jul 14, 2020 at 4:21 PM Michal Skrivanek < michal.skrivanek@redhat.com> wrote:
On 14 Jul 2020, at 12:11, Yedidyah Bar David <didi@redhat.com> wrote:
On Tue, Jul 14, 2020 at 11:43 AM Michal Skrivanek <michal.skrivanek@redhat.com> wrote:
Hi all, we’re moving to 4.4.z development now and we need to keep a closer eye
on automation results and making sure the build is not broken. For these reasons we’re considering moving to a similar model as vdsm, having a smaller set of people with merge rights to make sure the patches get in in the right order and they meet our sanity standards (OST, bug’s TM)
Any objections/comments?
Any reason to not simply branch 4.4? And have the branch maintained by the stable branches maintainers?
just the sheer amount of backports needed (every patch). Doesn’t sound worth the effort of posting and reviewing(even if just formally) everything twice.
If you expect _every_ patch to be backported
We are trying to minimize backports between master and stabilization branches by creating the stabilization branch as late as possible. This means that both branches use 4.4 database script numbering, which should decrease the need for backports. If we would create standard ovirt-engine-4.4 branch, then we would need to introduce 4.5 db scripts numbering on master and this would create huge overload when backporting all patches from master to ovirt-engine-4.4 So current master is meant to be our 4.4.2 release and we have ovirt-engine-4.4.1.z stabilization branch. Later we will create ovirt-engine-4.4.2.z stabilization branch and master will become 4.4.3 release and so on.
yes
, just do nothing - let current maintainers do their job, and revert the occasional bad ones when needed.
And how would you prevent breaking the relatively frequent updates? The CI OST is not working very well (for a long time now) and while we are improving and stabilizing the infrastrucure it’s not really there yet to consider automated gating. Engine is unique in oVirt set of projects, it’s the largest one by far and use maintainership per team or area (FE, BE, database, API…) and so we have a pretty high number of people merging patches but far less people keeping up to date with the project’s planning.
Otherwise, I think branching is a good approach.
-- Didi
-- Didi
_______________________________________________ Devel mailing list -- devel@ovirt.org To unsubscribe send an email to devel-leave@ovirt.org Privacy Statement: https://www.ovirt.org/privacy-policy.html oVirt Code of Conduct: https://www.ovirt.org/community/about/community-guidelines/ List Archives: https://lists.ovirt.org/archives/list/devel@ovirt.org/message/EDI64EBEIJC6KU...
-- Martin Perina Manager, Software Engineering Red Hat Czech s.r.o.
On Wed, Jul 15, 2020 at 10:55 AM Martin Perina <mperina@redhat.com> wrote:
On Tue, Jul 14, 2020 at 4:05 PM Michal Skrivanek <michal.skrivanek@redhat.com> wrote:
On 14 Jul 2020, at 15:33, Yedidyah Bar David <didi@redhat.com> wrote:
On Tue, Jul 14, 2020 at 4:21 PM Michal Skrivanek <michal.skrivanek@redhat.com> wrote:
On 14 Jul 2020, at 12:11, Yedidyah Bar David <didi@redhat.com> wrote:
On Tue, Jul 14, 2020 at 11:43 AM Michal Skrivanek <michal.skrivanek@redhat.com> wrote:
Hi all, we’re moving to 4.4.z development now and we need to keep a closer eye on automation results and making sure the build is not broken. For these reasons we’re considering moving to a similar model as vdsm, having a smaller set of people with merge rights to make sure the patches get in in the right order and they meet our sanity standards (OST, bug’s TM) Any objections/comments?
Any reason to not simply branch 4.4? And have the branch maintained by the stable branches maintainers?
just the sheer amount of backports needed (every patch). Doesn’t sound worth the effort of posting and reviewing(even if just formally) everything twice.
If you expect _every_ patch to be backported
We are trying to minimize backports between master and stabilization branches by creating the stabilization branch as late as possible. This means that both branches use 4.4 database script numbering, which should decrease the need for backports.
It's not clear if you describe what we "want", or what we "do" (now). I agree, anyway.
If we would create standard ovirt-engine-4.4 branch, then we would need to introduce 4.5 db scripts numbering on master
Why? I think you only need to do that once you want to - once you intend to merge to master functionality that needs a dbscript change, that you only want for 4.5.
and this would create huge overload when backporting all patches from master to ovirt-engine-4.4
So current master is meant to be our 4.4.2 release and we have ovirt-engine-4.4.1.z stabilization branch. Later we will create ovirt-engine-4.4.2.z stabilization branch and master will become 4.4.3 release and so on.
Ok, but what happens when you actually want to merge 4.5 stuff? Then you'll be at the same point you are today. If you do not intend to do this soon, I see no problem in branching 4.4 already. If you are just afraid that someone will accidentally try to merge some 4.5 dbscript to master, and want to prevent that for some time, just add some code to check-patch.sh to prevent that.
yes
, just do nothing - let current maintainers do their job, and revert the occasional bad ones when needed.
And how would you prevent breaking the relatively frequent updates? The CI OST is not working very well (for a long time now) and while we are improving and stabilizing the infrastrucure it’s not really there yet to consider automated gating. Engine is unique in oVirt set of projects, it’s the largest one by far and use maintainership per team or area (FE, BE, database, API…) and so we have a pretty high number of people merging patches but far less people keeping up to date with the project’s planning.
Otherwise, I think branching is a good approach.
-- Didi
-- Didi
_______________________________________________ Devel mailing list -- devel@ovirt.org To unsubscribe send an email to devel-leave@ovirt.org Privacy Statement: https://www.ovirt.org/privacy-policy.html oVirt Code of Conduct: https://www.ovirt.org/community/about/community-guidelines/ List Archives: https://lists.ovirt.org/archives/list/devel@ovirt.org/message/EDI64EBEIJC6KU...
-- Martin Perina Manager, Software Engineering Red Hat Czech s.r.o.
-- Didi
participants (3)
-
Martin Perina -
Michal Skrivanek -
Yedidyah Bar David