Archives
Contributors
Re: OCA and security notices
Hi, Xavier,
The delay depends on 2 factors:
- The technical work to be done, which is the installed core modules to be covered by OpenUpgrade + the OCA modules to be migrated. This can be complemented with use cases test suite to be checked.
- The customer alignment for the best moment to migrate, depending on their activity.
FYI, we are migrating our customers to v13 now, having 4 of them on 13.0 already, and the rest coming in the following months.
Regards.
El mié, 6 ene 2021 a las 19:07, Xavier Brochard (<xavier@alternatif.org>) escribió:
Hi Pedro I've found your post very interesting. However can you elaborate a bit on the delay before migration ? Obviously you can't migrate before the newest version is stabilized enough, but you can't also migrate before OpenUpgrade is available (or do you migrate "by hand" ?). So, are you curently running Odoo 13 and planning migrations around june ? Best regards Xavier / zeroheure --- Librement, Xavier Brochard xavier@alternatif.org La liberté est à l'homme ce que les ailes sont à l'oiseau (Jean-Pierre Rosnay) Le 05.01.2021 09:27, Pedro M. Baeza (Tecnativa) a écrit : > Hi, Tom, > > Each version can have some bugs, but it's better to handle them > between more people than let SaaS users or the same partners to > notify/fix them. You think it's "safer" to be on a previous version > for avoiding such bugs, but the facts are: > > - Such a bug is because of your use cases, and it will be found on the > version you are using, no matter if outdated or not. Nobody till then > may notify it. > - Odoo is fixing bugs very quickly and without effort by your part on > the latest version (or the previous one), as they are committed to > "stabilize" that version, but not on very old versions. A note about > this: notifying properly a bug is the key for having it solved. You > can't expect to have the work done not doing a minimum effort on your > part. > > - Bugs can happen even on unsupported versions, so the maintenance > cost starts to rise if you need to fix them by yourself and you are > introducing regression risks. > - There are even occasions where the bug is fixed or doesn't apply on > higher versions, but you don't have it in an outdated one. See the > recent CVE cases and the effort needed by Stefan and Nils. > - Odoo continues to improve its test suite, and each version has more > and more stability/quality. > > Other facts about using outdated versions: > > - You need to "backport" features that are on higher versions or lack > them. > - Framework evolves, and using an outdated framework makes your > development team to require more time to complete the same tasks, or > to not have available some tools. Programming in 2020 with the old API > or the v8/v9 hybrid for me is horrible. > - Collaboration possibilities are reduced working on an outdated > version, as there are less contributors on them. You can see the same > examples on your 7.0 PRs, or even on the 10.0 PRs, that is more > recent, but the same unattended. > - As a complement to the previous one, new contributors push newer > versions, not old ones. > - Underlying libraries and dependencies are outdated as well, with the > problems this supposes. > > So at Tecnativa we deal with this not having middle positions: all our > customers go to latest versions (the supported ones), and we reject > those that don't want this approach. That way, we focus on dealing > with a reduced set of Odoo versions, we migrate them regularly (not > forcing a yearly migration, but more and more customers demand to go > to each version and they don't want to keep the same version 2/3 > years), and we report bugs to Odoo constantly that makes the versions > stable enough. > > Migrating OCA modules is not a problem while you are on the wheel. The > keys are: > > - Having a team used to OCA guidelines. All our developments follow > strict guidelines. This makes the team to take the habit and don't > require more time to be "OCA". Anyway, 95% of our developments are > directly OCA. OCA first approach is also very important for us. > > - Having good test coverage. This is vital for easing the migrations. > Doing good tests is not easy, but the time spent on that will be for > sure gained later. This includes also JS tour/Qunit tests if needed. > - Reviewing PRs between colleagues as part of your development cycle. > This raises a lot your team skills and don't stuck PRs. People > complain about their PRs not being reviewed, but they don't review > others in exchange or don't push colleagues to review them. > > We also take a proactive position for handling some "polemical" > decisions taken on the versions, creating OCA modules that fill the > gaps. This is better IMO than staying on an older version and > complaining that "Odoo has removed this or changed that". In general > you win more than you lose on newer versions. > > And finally, customers receive a refresh training on each version > change. Being proactive as well on the changes they have makes people > to not reject the new version and embrace the new features from the > beginning. > > Do I convince you, hehe? > > Regards. > > _______________________________________________ > Mailing-List: https://odoo-community.org/groups/contributors-15 > Post to: mailto:contributors@odoo-community.org > Unsubscribe: https://odoo-community.org/groups?unsubscribe_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe
by Pedro M. Baeza - 12:36 - 7 Jan 2021
Reference
-
OCA and security notices
Hi community,
Yesterday a security notices has been published.
Stefan has begun to bring one security fix to OCB with this PR
It raises what seems to be an important point about the handling of the security fixes for the unsupported Odoo version on OCB. Will this should be taken in charge by OCA, as OCB is under OCA umbrella or it'll remain on the goodwill of the community's members ? I don't have any problem with one of the possible responses.
My point is how do we takle the minimum about this topic. I mean how do we organize the contribution members on this topics ?
My first idea will be to open an issue on OCB for each security notice and organize the work as it done for modules migration. What do you think ? Creating a PSC team security could be another idea.
Finding the security issues seems to be easy but at this point we don't have a tracking on the ones that are brought back on the unsupported version on OCB.
Here at Coop IT Easy we'll probably focus on the versions affecting our customers it means 9.0 as 11.0 and later are still supported.
Regards,
Housine
by Houssine BAKKALI - 11:46 - 23 Dec 2020-
Re: OCA and security notices
Hi, Xavier,The delay depends on 2 factors:- The technical work to be done, which is the installed core modules to be covered by OpenUpgrade + the OCA modules to be migrated. This can be complemented with use cases test suite to be checked.- The customer alignment for the best moment to migrate, depending on their activity.FYI, we are migrating our customers to v13 now, having 4 of them on 13.0 already, and the rest coming in the following months.Regards.El mié, 6 ene 2021 a las 19:07, Xavier Brochard (<xavier@alternatif.org>) escribió:
Hi Pedro I've found your post very interesting. However can you elaborate a bit on the delay before migration ? Obviously you can't migrate before the newest version is stabilized enough, but you can't also migrate before OpenUpgrade is available (or do you migrate "by hand" ?). So, are you curently running Odoo 13 and planning migrations around june ? Best regards Xavier / zeroheure --- Librement, Xavier Brochard xavier@alternatif.org La liberté est à l'homme ce que les ailes sont à l'oiseau (Jean-Pierre Rosnay) Le 05.01.2021 09:27, Pedro M. Baeza (Tecnativa) a écrit : > Hi, Tom, > > Each version can have some bugs, but it's better to handle them > between more people than let SaaS users or the same partners to > notify/fix them. You think it's "safer" to be on a previous version > for avoiding such bugs, but the facts are: > > - Such a bug is because of your use cases, and it will be found on the > version you are using, no matter if outdated or not. Nobody till then > may notify it. > - Odoo is fixing bugs very quickly and without effort by your part on > the latest version (or the previous one), as they are committed to > "stabilize" that version, but not on very old versions. A note about > this: notifying properly a bug is the key for having it solved. You > can't expect to have the work done not doing a minimum effort on your > part. > > - Bugs can happen even on unsupported versions, so the maintenance > cost starts to rise if you need to fix them by yourself and you are > introducing regression risks. > - There are even occasions where the bug is fixed or doesn't apply on > higher versions, but you don't have it in an outdated one. See the > recent CVE cases and the effort needed by Stefan and Nils. > - Odoo continues to improve its test suite, and each version has more > and more stability/quality. > > Other facts about using outdated versions: > > - You need to "backport" features that are on higher versions or lack > them. > - Framework evolves, and using an outdated framework makes your > development team to require more time to complete the same tasks, or > to not have available some tools. Programming in 2020 with the old API > or the v8/v9 hybrid for me is horrible. > - Collaboration possibilities are reduced working on an outdated > version, as there are less contributors on them. You can see the same > examples on your 7.0 PRs, or even on the 10.0 PRs, that is more > recent, but the same unattended. > - As a complement to the previous one, new contributors push newer > versions, not old ones. > - Underlying libraries and dependencies are outdated as well, with the > problems this supposes. > > So at Tecnativa we deal with this not having middle positions: all our > customers go to latest versions (the supported ones), and we reject > those that don't want this approach. That way, we focus on dealing > with a reduced set of Odoo versions, we migrate them regularly (not > forcing a yearly migration, but more and more customers demand to go > to each version and they don't want to keep the same version 2/3 > years), and we report bugs to Odoo constantly that makes the versions > stable enough. > > Migrating OCA modules is not a problem while you are on the wheel. The > keys are: > > - Having a team used to OCA guidelines. All our developments follow > strict guidelines. This makes the team to take the habit and don't > require more time to be "OCA". Anyway, 95% of our developments are > directly OCA. OCA first approach is also very important for us. > > - Having good test coverage. This is vital for easing the migrations. > Doing good tests is not easy, but the time spent on that will be for > sure gained later. This includes also JS tour/Qunit tests if needed. > - Reviewing PRs between colleagues as part of your development cycle. > This raises a lot your team skills and don't stuck PRs. People > complain about their PRs not being reviewed, but they don't review > others in exchange or don't push colleagues to review them. > > We also take a proactive position for handling some "polemical" > decisions taken on the versions, creating OCA modules that fill the > gaps. This is better IMO than staying on an older version and > complaining that "Odoo has removed this or changed that". In general > you win more than you lose on newer versions. > > And finally, customers receive a refresh training on each version > change. Being proactive as well on the changes they have makes people > to not reject the new version and embrace the new features from the > beginning. > > Do I convince you, hehe? > > Regards. > > _______________________________________________ > Mailing-List: https://odoo-community.org/groups/contributors-15 > Post to: mailto:contributors@odoo-community.org > Unsubscribe: https://odoo-community.org/groups?unsubscribe
_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe
by Pedro M. Baeza - 12:36 - 7 Jan 2021 -
Re: OCA and security notices
Hi, Tom,Each version can have some bugs, but it's better to handle them between more people than let SaaS users or the same partners to notify/fix them. You think it's "safer" to be on a previous version for avoiding such bugs, but the facts are:- Such a bug is because of your use cases, and it will be found on the version you are using, no matter if outdated or not. Nobody till then may notify it.- Odoo is fixing bugs very quickly and without effort by your part on the latest version (or the previous one), as they are committed to "stabilize" that version, but not on very old versions. A note about this: notifying properly a bug is the key for having it solved. You can't expect to have the work done not doing a minimum effort on your part.- Bugs can happen even on unsupported versions, so the maintenance cost starts to rise if you need to fix them by yourself and you are introducing regression risks.- There are even occasions where the bug is fixed or doesn't apply on higher versions, but you don't have it in an outdated one. See the recent CVE cases and the effort needed by Stefan and Nils.- Odoo continues to improve its test suite, and each version has more and more stability/quality.Other facts about using outdated versions:- You need to "backport" features that are on higher versions or lack them.- Framework evolves, and using an outdated framework makes your development team to require more time to complete the same tasks, or to not have available some tools. Programming in 2020 with the old API or the v8/v9 hybrid for me is horrible.- Collaboration possibilities are reduced working on an outdated version, as there are less contributors on them. You can see the same examples on your 7.0 PRs, or even on the 10.0 PRs, that is more recent, but the same unattended.- As a complement to the previous one, new contributors push newer versions, not old ones.- Underlying libraries and dependencies are outdated as well, with the problems this supposes.So at Tecnativa we deal with this not having middle positions: all our customers go to latest versions (the supported ones), and we reject those that don't want this approach. That way, we focus on dealing with a reduced set of Odoo versions, we migrate them regularly (not forcing a yearly migration, but more and more customers demand to go to each version and they don't want to keep the same version 2/3 years), and we report bugs to Odoo constantly that makes the versions stable enough.Migrating OCA modules is not a problem while you are on the wheel. The keys are:- Having a team used to OCA guidelines. All our developments follow strict guidelines. This makes the team to take the habit and don't require more time to be "OCA". Anyway, 95% of our developments are directly OCA. OCA first approach is also very important for us.- Having good test coverage. This is vital for easing the migrations. Doing good tests is not easy, but the time spent on that will be for sure gained later. This includes also JS tour/Qunit tests if needed.- Reviewing PRs between colleagues as part of your development cycle. This raises a lot your team skills and don't stuck PRs. People complain about their PRs not being reviewed, but they don't review others in exchange or don't push colleagues to review them.We also take a proactive position for handling some "polemical" decisions taken on the versions, creating OCA modules that fill the gaps. This is better IMO than staying on an older version and complaining that "Odoo has removed this or changed that". In general you win more than you lose on newer versions.And finally, customers receive a refresh training on each version change. Being proactive as well on the changes they have makes people to not reject the new version and embrace the new features from the beginning.Do I convince you, hehe?Regards.
by Pedro M. Baeza - 09:21 - 5 Jan 2021
