Re: libbsd development policy clarification needed?
On 06.02.23 20:47, Gedare Bloom wrote: On Mon, Feb 6, 2023 at 8:49 AM Sebastian Huber wrote: On 06.02.23 16:06, Gedare Bloom wrote: Yes, thanks. This looks like a good analysis. I would definitely prefer to get master and 6-freebsd-12 into harmony. Then it is a little simpler to discuss the other problems in libbsd. Vijay had similar kind of success (and problems) as you did with cherry-picking off of 6-freebsd-12. I think he made it a little further. I guess one possible route forward would be to begin working on this effort and share results, pushing to master when some relatively stable milestones are reached. This branch already contains an update to FreeBSD head 2020-02-09 (about 5 months of FreeBSD development): https://github.com/RTEMS/rtems-libbsd/compare/master...sebhub:rtems-libbsd:master-update If you start to cherry-pick things to the current master, this effort from my side is probably wasted. Would it be viable to still cherry-pick on to your updated master? The farther these branches get from each other the more effort will be wasted by everyone. Either we continue to maintain two branches, or we at some point decide how to continue from this master branch. It would be good to know if NFSv4 is indeed fully supported for EPICS users without the changes made by Chris in 6-freebsd-12. The first four patches (up to and including "ntp: Port to RTEMS") are ready to get integrated. The two NFS/VFS patches are not ready. The update to FreeBSD head 2020-02-09 was not arbitrary. The 6-freebsd-12 branch is based on FreeBSD stable/12 2020-02-10. This should make it easier to cherry pick changes from 6-freebsd-12 to master for example for the Xilinx drivers. -- embedded brains GmbH Herr Sebastian HUBER Dornierstr. 4 82178 Puchheim Germany email: sebastian.hu...@embedded-brains.de phone: +49-89-18 94 741 - 16 fax: +49-89-18 94 741 - 08 Registergericht: Amtsgericht München Registernummer: HRB 157899 Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler Unsere Datenschutzerklärung finden Sie hier: https://embedded-brains.de/datenschutzerklaerung/ ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: libbsd development policy clarification needed?
On Mon, Feb 6, 2023 at 8:49 AM Sebastian Huber wrote: > > On 06.02.23 16:06, Gedare Bloom wrote: > > Yes, thanks. This looks like a good analysis. I would definitely > > prefer to get master and 6-freebsd-12 into harmony. Then it is a > > little simpler to discuss the other problems in libbsd. > > > > Vijay had similar kind of success (and problems) as you did with > > cherry-picking off of 6-freebsd-12. I think he made it a little > > further. I guess one possible route forward would be to begin working > > on this effort and share results, pushing to master when some > > relatively stable milestones are reached. > > This branch already contains an update to FreeBSD head 2020-02-09 (about > 5 months of FreeBSD development): > > https://github.com/RTEMS/rtems-libbsd/compare/master...sebhub:rtems-libbsd:master-update > > If you start to cherry-pick things to the current master, this effort > from my side is probably wasted. > Would it be viable to still cherry-pick on to your updated master? The farther these branches get from each other the more effort will be wasted by everyone. Either we continue to maintain two branches, or we at some point decide how to continue from this master branch. It would be good to know if NFSv4 is indeed fully supported for EPICS users without the changes made by Chris in 6-freebsd-12. Gedare ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: libbsd development policy clarification needed?
On 06.02.23 16:06, Gedare Bloom wrote: Yes, thanks. This looks like a good analysis. I would definitely prefer to get master and 6-freebsd-12 into harmony. Then it is a little simpler to discuss the other problems in libbsd. Vijay had similar kind of success (and problems) as you did with cherry-picking off of 6-freebsd-12. I think he made it a little further. I guess one possible route forward would be to begin working on this effort and share results, pushing to master when some relatively stable milestones are reached. This branch already contains an update to FreeBSD head 2020-02-09 (about 5 months of FreeBSD development): https://github.com/RTEMS/rtems-libbsd/compare/master...sebhub:rtems-libbsd:master-update If you start to cherry-pick things to the current master, this effort from my side is probably wasted. -- embedded brains GmbH Herr Sebastian HUBER Dornierstr. 4 82178 Puchheim Germany email: sebastian.hu...@embedded-brains.de phone: +49-89-18 94 741 - 16 fax: +49-89-18 94 741 - 08 Registergericht: Amtsgericht München Registernummer: HRB 157899 Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler Unsere Datenschutzerklärung finden Sie hier: https://embedded-brains.de/datenschutzerklaerung/ ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: libbsd development policy clarification needed?
On 2023-02-06 16:06, Gedare Bloom wrote: On Mon, Feb 6, 2023 at 2:26 AM Christian MAUDERER wrote: On 2023-02-06 10:02, Christian MAUDERER wrote: On 2023-02-05 11:38, Christian Mauderer wrote: Am 04.02.23 um 01:25 schrieb Gedare Bloom: On Fri, Feb 3, 2023 at 3:29 PM Christian Mauderer wrote: Am 3. Februar 2023 22:52:48 MEZ schrieb Gedare Bloom : On Fri, Feb 3, 2023 at 2:39 PM Christian Mauderer wrote: Am 3. Februar 2023 22:12:06 MEZ schrieb Gedare Bloom : On Fri, Feb 3, 2023 at 12:52 PM wrote: Hello Gedare, Am 03.02.23 um 19:51 schrieb Gedare Bloom: On Thu, Feb 2, 2023 at 11:24 PM Christian MAUDERER wrote: Hello Karel, On 2023-02-02 12:43, Karel Gardas wrote: Guys, recently I needed to work with RTEMS/NFS. As this is provided by libbsd I took this and following two sentences below from master branch description provided in README I took as granted that master does have all the features which are currently available and provided by the project: "This branch must be used for libbsd development. Back ports to the 6-freebsd-12 are allowed." I was surprised to be proven wrong then by Fabrizio here: https://devel.rtems.org/ticket/4723 and by later investigation which shows that 6-freebsd-12 branch accumulated NFS work by Chris done in 2021 which is not presented on master. I've investigated just NFS as this was my focus here. So if 6-freebsd-12 became development branch of some sort, then it would be great to have that clarified in the project README file to prevent users confusion? Or if the policy is still the same, then perhaps some branch sync is needed here? That currently is an open issue. Basically there is a pending patch set that should fix that since several months. But there is a disagreement about some of the changes in that patch set (and about the patches checked in to 6-freebsd-12). Therefore, it still hasn't been merged. If you want to know some more about the problematic points, I recommend reading this (long) thread: https://lists.rtems.org/pipermail/devel/2023-January/074164.html The statement that development has to happen on the master branch is still true. The master is intended to track the FreeBSD upstream development. Only changes on that branch are guaranteed to live through an upgrade to a newer base version of FreeBSD. It's very unfortunate, that there are some patches on the 6-freebsd-12 branch only. On the long term, that issue has to be resolved. I have been investigating this problem in the background, and I have some findings and some questions. First, I have found that there is a most-common ancestor between master and 6-freebsd-12 at commit https://git.rtems.org/rtems-libbsd/commit/?h=6-freebsd-12=2ce13cf6dc73855f28bc7edbbc64dc4b482a4976 This is at least promising that the discrepancy between the branches can be resolved. The proposed pending patch set to "fix" the NFS issue does not fix the underlying problem. Instead, it introduces further divergence between the branches. I would instead suggest that we should resolve to fix the underlying problem. I can see two paths forward. 1. Abandon 6-freebsd-12 after releasing 6. This is probably not ideal since what I understand is some users have projects based on 6-freebsd-12 and would like an upgrade path. (I guess there is also the option to abandon master, which also makes little sense.) A variant for this would be to introduce a 6-freebsd-13 that is based on the master branch as soon as we have one. That would allow a longer maintenance because FreeBSD 12 reaches it's EoL December 2023. 2. Pull commits from 6-freebsd-12 into master to make sure master is the development head. in the future, reject patches that only go toward release branches. This has its own problems too. It can realistically only be done in three ways: Please note that Sebastian mentioned that the file descriptors broke the NTP support (at least I think it was NTP; possible that it was another submodule). So picking the current version of the patches into the master without adding fixes makes the master unusable for some cases. Fixing the problems after making the branches the same will be better for the long-term, if we can find a path to do it. 2a: Rebase master and cherry-pick commits from 6-freebsd-12 and master back into master. This rewrites the history of master, and unfortunately will cause the head of 5-freebsd-12 and the tags for rtems-5 to no longer exist on the master branch. They will still exist in the '5' branch. The advantage is in the end there will be a linear history of development on master that reflects the timeline of actual development that spanned both branches. Theoretically, this should make it easier to git-bisect. 2b: Cherry-pick commits from 6-freebsd-12 to master and fix conflicts. This puts all the missing commits from 6-freebsd-12 on to the current head of master. I don't know how messy this would be. It ends up making the history of master convoluted to
Re: libbsd development policy clarification needed?
On Mon, Feb 6, 2023 at 2:26 AM Christian MAUDERER wrote: > > On 2023-02-06 10:02, Christian MAUDERER wrote: > > On 2023-02-05 11:38, Christian Mauderer wrote: > >> > >> > >> Am 04.02.23 um 01:25 schrieb Gedare Bloom: > >>> On Fri, Feb 3, 2023 at 3:29 PM Christian Mauderer > >>> wrote: > > > > Am 3. Februar 2023 22:52:48 MEZ schrieb Gedare Bloom > : > > On Fri, Feb 3, 2023 at 2:39 PM Christian Mauderer > > wrote: > >> > >> > >> > >> Am 3. Februar 2023 22:12:06 MEZ schrieb Gedare Bloom > >> : > >>> On Fri, Feb 3, 2023 at 12:52 PM wrote: > > Hello Gedare, > > Am 03.02.23 um 19:51 schrieb Gedare Bloom: > > On Thu, Feb 2, 2023 at 11:24 PM Christian MAUDERER > > wrote: > >> > >> Hello Karel, > >> > >> On 2023-02-02 12:43, Karel Gardas wrote: > >>> > >>> Guys, > >>> > >>> recently I needed to work with RTEMS/NFS. As this is provided > >>> by libbsd > >>> I took this and following two sentences below from master branch > >>> description provided in README I took as granted that master > >>> does have > >>> all the features which are currently available and provided > >>> by the project: > >>> > >>> "This branch must be used for libbsd development. Back ports > >>> to the > >>> 6-freebsd-12 are allowed." > >>> > >>> I was surprised to be proven wrong then by Fabrizio here: > >>> https://devel.rtems.org/ticket/4723 > >>> > >>> and by later investigation which shows that 6-freebsd-12 branch > >>> accumulated NFS work by Chris done in 2021 which is not > >>> presented on > >>> master. I've investigated just NFS as this was my focus here. > >>> > >>> So if 6-freebsd-12 became development branch of some sort, > >>> then it would > >>> be great to have that clarified in the project README file to > >>> prevent > >>> users confusion? Or if the policy is still the same, then > >>> perhaps some > >>> branch sync is needed here? > >> > >> That currently is an open issue. Basically there is a pending > >> patch set > >> that should fix that since several months. But there is a > >> disagreement > >> about some of the changes in that patch set (and about the > >> patches > >> checked in to 6-freebsd-12). Therefore, it still hasn't been > >> merged. > >> > >> If you want to know some more about the problematic points, I > >> recommend > >> reading this (long) thread: > >> > >> https://lists.rtems.org/pipermail/devel/2023-January/074164.html > >> > >> The statement that development has to happen on the master > >> branch is > >> still true. The master is intended to track the FreeBSD upstream > >> development. Only changes on that branch are guaranteed to > >> live through > >> an upgrade to a newer base version of FreeBSD. It's very > >> unfortunate, > >> that there are some patches on the 6-freebsd-12 branch only. > >> On the long > >> term, that issue has to be resolved. > >> > > > > I have been investigating this problem in the background, and I > > have > > some findings and some questions. First, I have found that > > there is a > > most-common ancestor between master and 6-freebsd-12 at commit > > https://git.rtems.org/rtems-libbsd/commit/?h=6-freebsd-12=2ce13cf6dc73855f28bc7edbbc64dc4b482a4976 > > This is at least promising that the discrepancy between the > > branches > > can be resolved. > > > > The proposed pending patch set to "fix" the NFS issue does not > > fix the > > underlying problem. Instead, it introduces further divergence > > between > > the branches. I would instead suggest that we should resolve to > > fix > > the underlying problem. I can see two paths forward. > > > > 1. Abandon 6-freebsd-12 after releasing 6. This is probably not > > ideal > > since what I understand is some users have projects based on > > 6-freebsd-12 and would like an upgrade path. (I guess there is > > also > > the option to abandon master, which also makes little sense.) > > A variant for this would be to introduce a 6-freebsd-13 that is > based on > the master branch as soon as we have one. That would allow a longer > maintenance because FreeBSD 12 reaches it's EoL December 2023. > > > > > 2. Pull commits from 6-freebsd-12 into master to make sure > > master is
Re: libbsd development policy clarification needed?
On 2023-02-06 10:02, Christian MAUDERER wrote: On 2023-02-05 11:38, Christian Mauderer wrote: Am 04.02.23 um 01:25 schrieb Gedare Bloom: On Fri, Feb 3, 2023 at 3:29 PM Christian Mauderer wrote: Am 3. Februar 2023 22:52:48 MEZ schrieb Gedare Bloom : On Fri, Feb 3, 2023 at 2:39 PM Christian Mauderer wrote: Am 3. Februar 2023 22:12:06 MEZ schrieb Gedare Bloom : On Fri, Feb 3, 2023 at 12:52 PM wrote: Hello Gedare, Am 03.02.23 um 19:51 schrieb Gedare Bloom: On Thu, Feb 2, 2023 at 11:24 PM Christian MAUDERER wrote: Hello Karel, On 2023-02-02 12:43, Karel Gardas wrote: Guys, recently I needed to work with RTEMS/NFS. As this is provided by libbsd I took this and following two sentences below from master branch description provided in README I took as granted that master does have all the features which are currently available and provided by the project: "This branch must be used for libbsd development. Back ports to the 6-freebsd-12 are allowed." I was surprised to be proven wrong then by Fabrizio here: https://devel.rtems.org/ticket/4723 and by later investigation which shows that 6-freebsd-12 branch accumulated NFS work by Chris done in 2021 which is not presented on master. I've investigated just NFS as this was my focus here. So if 6-freebsd-12 became development branch of some sort, then it would be great to have that clarified in the project README file to prevent users confusion? Or if the policy is still the same, then perhaps some branch sync is needed here? That currently is an open issue. Basically there is a pending patch set that should fix that since several months. But there is a disagreement about some of the changes in that patch set (and about the patches checked in to 6-freebsd-12). Therefore, it still hasn't been merged. If you want to know some more about the problematic points, I recommend reading this (long) thread: https://lists.rtems.org/pipermail/devel/2023-January/074164.html The statement that development has to happen on the master branch is still true. The master is intended to track the FreeBSD upstream development. Only changes on that branch are guaranteed to live through an upgrade to a newer base version of FreeBSD. It's very unfortunate, that there are some patches on the 6-freebsd-12 branch only. On the long term, that issue has to be resolved. I have been investigating this problem in the background, and I have some findings and some questions. First, I have found that there is a most-common ancestor between master and 6-freebsd-12 at commit https://git.rtems.org/rtems-libbsd/commit/?h=6-freebsd-12=2ce13cf6dc73855f28bc7edbbc64dc4b482a4976 This is at least promising that the discrepancy between the branches can be resolved. The proposed pending patch set to "fix" the NFS issue does not fix the underlying problem. Instead, it introduces further divergence between the branches. I would instead suggest that we should resolve to fix the underlying problem. I can see two paths forward. 1. Abandon 6-freebsd-12 after releasing 6. This is probably not ideal since what I understand is some users have projects based on 6-freebsd-12 and would like an upgrade path. (I guess there is also the option to abandon master, which also makes little sense.) A variant for this would be to introduce a 6-freebsd-13 that is based on the master branch as soon as we have one. That would allow a longer maintenance because FreeBSD 12 reaches it's EoL December 2023. 2. Pull commits from 6-freebsd-12 into master to make sure master is the development head. in the future, reject patches that only go toward release branches. This has its own problems too. It can realistically only be done in three ways: Please note that Sebastian mentioned that the file descriptors broke the NTP support (at least I think it was NTP; possible that it was another submodule). So picking the current version of the patches into the master without adding fixes makes the master unusable for some cases. Fixing the problems after making the branches the same will be better for the long-term, if we can find a path to do it. 2a: Rebase master and cherry-pick commits from 6-freebsd-12 and master back into master. This rewrites the history of master, and unfortunately will cause the head of 5-freebsd-12 and the tags for rtems-5 to no longer exist on the master branch. They will still exist in the '5' branch. The advantage is in the end there will be a linear history of development on master that reflects the timeline of actual development that spanned both branches. Theoretically, this should make it easier to git-bisect. 2b: Cherry-pick commits from 6-freebsd-12 to master and fix conflicts. This puts all the missing commits from 6-freebsd-12 on to the current head of master. I don't know how messy this would be. It ends up making the history of master convoluted to understand, with fairly old commits from 2018
Re: libbsd development policy clarification needed?
On 2023-02-05 11:38, Christian Mauderer wrote: Am 04.02.23 um 01:25 schrieb Gedare Bloom: On Fri, Feb 3, 2023 at 3:29 PM Christian Mauderer wrote: Am 3. Februar 2023 22:52:48 MEZ schrieb Gedare Bloom : On Fri, Feb 3, 2023 at 2:39 PM Christian Mauderer wrote: Am 3. Februar 2023 22:12:06 MEZ schrieb Gedare Bloom : On Fri, Feb 3, 2023 at 12:52 PM wrote: Hello Gedare, Am 03.02.23 um 19:51 schrieb Gedare Bloom: On Thu, Feb 2, 2023 at 11:24 PM Christian MAUDERER wrote: Hello Karel, On 2023-02-02 12:43, Karel Gardas wrote: Guys, recently I needed to work with RTEMS/NFS. As this is provided by libbsd I took this and following two sentences below from master branch description provided in README I took as granted that master does have all the features which are currently available and provided by the project: "This branch must be used for libbsd development. Back ports to the 6-freebsd-12 are allowed." I was surprised to be proven wrong then by Fabrizio here: https://devel.rtems.org/ticket/4723 and by later investigation which shows that 6-freebsd-12 branch accumulated NFS work by Chris done in 2021 which is not presented on master. I've investigated just NFS as this was my focus here. So if 6-freebsd-12 became development branch of some sort, then it would be great to have that clarified in the project README file to prevent users confusion? Or if the policy is still the same, then perhaps some branch sync is needed here? That currently is an open issue. Basically there is a pending patch set that should fix that since several months. But there is a disagreement about some of the changes in that patch set (and about the patches checked in to 6-freebsd-12). Therefore, it still hasn't been merged. If you want to know some more about the problematic points, I recommend reading this (long) thread: https://lists.rtems.org/pipermail/devel/2023-January/074164.html The statement that development has to happen on the master branch is still true. The master is intended to track the FreeBSD upstream development. Only changes on that branch are guaranteed to live through an upgrade to a newer base version of FreeBSD. It's very unfortunate, that there are some patches on the 6-freebsd-12 branch only. On the long term, that issue has to be resolved. I have been investigating this problem in the background, and I have some findings and some questions. First, I have found that there is a most-common ancestor between master and 6-freebsd-12 at commit https://git.rtems.org/rtems-libbsd/commit/?h=6-freebsd-12=2ce13cf6dc73855f28bc7edbbc64dc4b482a4976 This is at least promising that the discrepancy between the branches can be resolved. The proposed pending patch set to "fix" the NFS issue does not fix the underlying problem. Instead, it introduces further divergence between the branches. I would instead suggest that we should resolve to fix the underlying problem. I can see two paths forward. 1. Abandon 6-freebsd-12 after releasing 6. This is probably not ideal since what I understand is some users have projects based on 6-freebsd-12 and would like an upgrade path. (I guess there is also the option to abandon master, which also makes little sense.) A variant for this would be to introduce a 6-freebsd-13 that is based on the master branch as soon as we have one. That would allow a longer maintenance because FreeBSD 12 reaches it's EoL December 2023. 2. Pull commits from 6-freebsd-12 into master to make sure master is the development head. in the future, reject patches that only go toward release branches. This has its own problems too. It can realistically only be done in three ways: Please note that Sebastian mentioned that the file descriptors broke the NTP support (at least I think it was NTP; possible that it was another submodule). So picking the current version of the patches into the master without adding fixes makes the master unusable for some cases. Fixing the problems after making the branches the same will be better for the long-term, if we can find a path to do it. 2a: Rebase master and cherry-pick commits from 6-freebsd-12 and master back into master. This rewrites the history of master, and unfortunately will cause the head of 5-freebsd-12 and the tags for rtems-5 to no longer exist on the master branch. They will still exist in the '5' branch. The advantage is in the end there will be a linear history of development on master that reflects the timeline of actual development that spanned both branches. Theoretically, this should make it easier to git-bisect. 2b: Cherry-pick commits from 6-freebsd-12 to master and fix conflicts. This puts all the missing commits from 6-freebsd-12 on to the current head of master. I don't know how messy this would be. It ends up making the history of master convoluted to understand, with fairly old commits from 2018 being placed on top of newer commits from 2020s. 2c:
Re: libbsd development policy clarification needed?
Am 04.02.23 um 01:25 schrieb Gedare Bloom: On Fri, Feb 3, 2023 at 3:29 PM Christian Mauderer wrote: Am 3. Februar 2023 22:52:48 MEZ schrieb Gedare Bloom : On Fri, Feb 3, 2023 at 2:39 PM Christian Mauderer wrote: Am 3. Februar 2023 22:12:06 MEZ schrieb Gedare Bloom : On Fri, Feb 3, 2023 at 12:52 PM wrote: Hello Gedare, Am 03.02.23 um 19:51 schrieb Gedare Bloom: On Thu, Feb 2, 2023 at 11:24 PM Christian MAUDERER wrote: Hello Karel, On 2023-02-02 12:43, Karel Gardas wrote: Guys, recently I needed to work with RTEMS/NFS. As this is provided by libbsd I took this and following two sentences below from master branch description provided in README I took as granted that master does have all the features which are currently available and provided by the project: "This branch must be used for libbsd development. Back ports to the 6-freebsd-12 are allowed." I was surprised to be proven wrong then by Fabrizio here: https://devel.rtems.org/ticket/4723 and by later investigation which shows that 6-freebsd-12 branch accumulated NFS work by Chris done in 2021 which is not presented on master. I've investigated just NFS as this was my focus here. So if 6-freebsd-12 became development branch of some sort, then it would be great to have that clarified in the project README file to prevent users confusion? Or if the policy is still the same, then perhaps some branch sync is needed here? That currently is an open issue. Basically there is a pending patch set that should fix that since several months. But there is a disagreement about some of the changes in that patch set (and about the patches checked in to 6-freebsd-12). Therefore, it still hasn't been merged. If you want to know some more about the problematic points, I recommend reading this (long) thread: https://lists.rtems.org/pipermail/devel/2023-January/074164.html The statement that development has to happen on the master branch is still true. The master is intended to track the FreeBSD upstream development. Only changes on that branch are guaranteed to live through an upgrade to a newer base version of FreeBSD. It's very unfortunate, that there are some patches on the 6-freebsd-12 branch only. On the long term, that issue has to be resolved. I have been investigating this problem in the background, and I have some findings and some questions. First, I have found that there is a most-common ancestor between master and 6-freebsd-12 at commit https://git.rtems.org/rtems-libbsd/commit/?h=6-freebsd-12=2ce13cf6dc73855f28bc7edbbc64dc4b482a4976 This is at least promising that the discrepancy between the branches can be resolved. The proposed pending patch set to "fix" the NFS issue does not fix the underlying problem. Instead, it introduces further divergence between the branches. I would instead suggest that we should resolve to fix the underlying problem. I can see two paths forward. 1. Abandon 6-freebsd-12 after releasing 6. This is probably not ideal since what I understand is some users have projects based on 6-freebsd-12 and would like an upgrade path. (I guess there is also the option to abandon master, which also makes little sense.) A variant for this would be to introduce a 6-freebsd-13 that is based on the master branch as soon as we have one. That would allow a longer maintenance because FreeBSD 12 reaches it's EoL December 2023. 2. Pull commits from 6-freebsd-12 into master to make sure master is the development head. in the future, reject patches that only go toward release branches. This has its own problems too. It can realistically only be done in three ways: Please note that Sebastian mentioned that the file descriptors broke the NTP support (at least I think it was NTP; possible that it was another submodule). So picking the current version of the patches into the master without adding fixes makes the master unusable for some cases. Fixing the problems after making the branches the same will be better for the long-term, if we can find a path to do it. 2a: Rebase master and cherry-pick commits from 6-freebsd-12 and master back into master. This rewrites the history of master, and unfortunately will cause the head of 5-freebsd-12 and the tags for rtems-5 to no longer exist on the master branch. They will still exist in the '5' branch. The advantage is in the end there will be a linear history of development on master that reflects the timeline of actual development that spanned both branches. Theoretically, this should make it easier to git-bisect. 2b: Cherry-pick commits from 6-freebsd-12 to master and fix conflicts. This puts all the missing commits from 6-freebsd-12 on to the current head of master. I don't know how messy this would be. It ends up making the history of master convoluted to understand, with fairly old commits from 2018 being placed on top of newer commits from 2020s. 2c: Merge 6-freebsd-12 into master and fixup conflicts in the merge commit. This is pretty similar to 2a but
Re: libbsd development policy clarification needed?
Hello Christian, On 2/3/23 07:24, Christian MAUDERER wrote: If you want to know some more about the problematic points, I recommend reading this (long) thread: https://lists.rtems.org/pipermail/devel/2023-January/074164.html oh, I've seen that and ignored so far not knowing this will bite me that soon. Thank you for clarification and big thanks to all involved and dealing with this libbsd issue. Karel ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: libbsd development policy clarification needed?
On Fri, Feb 3, 2023 at 3:29 PM Christian Mauderer wrote: > > > > Am 3. Februar 2023 22:52:48 MEZ schrieb Gedare Bloom : > >On Fri, Feb 3, 2023 at 2:39 PM Christian Mauderer wrote: > >> > >> > >> > >> Am 3. Februar 2023 22:12:06 MEZ schrieb Gedare Bloom : > >> >On Fri, Feb 3, 2023 at 12:52 PM wrote: > >> >> > >> >> Hello Gedare, > >> >> > >> >> Am 03.02.23 um 19:51 schrieb Gedare Bloom: > >> >> > On Thu, Feb 2, 2023 at 11:24 PM Christian MAUDERER > >> >> > wrote: > >> >> >> > >> >> >> Hello Karel, > >> >> >> > >> >> >> On 2023-02-02 12:43, Karel Gardas wrote: > >> >> >>> > >> >> >>> Guys, > >> >> >>> > >> >> >>> recently I needed to work with RTEMS/NFS. As this is provided by > >> >> >>> libbsd > >> >> >>> I took this and following two sentences below from master branch > >> >> >>> description provided in README I took as granted that master does > >> >> >>> have > >> >> >>> all the features which are currently available and provided by the > >> >> >>> project: > >> >> >>> > >> >> >>> "This branch must be used for libbsd development. Back ports to the > >> >> >>> 6-freebsd-12 are allowed." > >> >> >>> > >> >> >>> I was surprised to be proven wrong then by Fabrizio here: > >> >> >>> https://devel.rtems.org/ticket/4723 > >> >> >>> > >> >> >>> and by later investigation which shows that 6-freebsd-12 branch > >> >> >>> accumulated NFS work by Chris done in 2021 which is not presented on > >> >> >>> master. I've investigated just NFS as this was my focus here. > >> >> >>> > >> >> >>> So if 6-freebsd-12 became development branch of some sort, then it > >> >> >>> would > >> >> >>> be great to have that clarified in the project README file to > >> >> >>> prevent > >> >> >>> users confusion? Or if the policy is still the same, then perhaps > >> >> >>> some > >> >> >>> branch sync is needed here? > >> >> >> > >> >> >> That currently is an open issue. Basically there is a pending patch > >> >> >> set > >> >> >> that should fix that since several months. But there is a > >> >> >> disagreement > >> >> >> about some of the changes in that patch set (and about the patches > >> >> >> checked in to 6-freebsd-12). Therefore, it still hasn't been merged. > >> >> >> > >> >> >> If you want to know some more about the problematic points, I > >> >> >> recommend > >> >> >> reading this (long) thread: > >> >> >> > >> >> >> https://lists.rtems.org/pipermail/devel/2023-January/074164.html > >> >> >> > >> >> >> The statement that development has to happen on the master branch is > >> >> >> still true. The master is intended to track the FreeBSD upstream > >> >> >> development. Only changes on that branch are guaranteed to live > >> >> >> through > >> >> >> an upgrade to a newer base version of FreeBSD. It's very unfortunate, > >> >> >> that there are some patches on the 6-freebsd-12 branch only. On the > >> >> >> long > >> >> >> term, that issue has to be resolved. > >> >> >> > >> >> > > >> >> > I have been investigating this problem in the background, and I have > >> >> > some findings and some questions. First, I have found that there is a > >> >> > most-common ancestor between master and 6-freebsd-12 at commit > >> >> > https://git.rtems.org/rtems-libbsd/commit/?h=6-freebsd-12=2ce13cf6dc73855f28bc7edbbc64dc4b482a4976 > >> >> > This is at least promising that the discrepancy between the branches > >> >> > can be resolved. > >> >> > > >> >> > The proposed pending patch set to "fix" the NFS issue does not fix the > >> >> > underlying problem. Instead, it introduces further divergence between > >> >> > the branches. I would instead suggest that we should resolve to fix > >> >> > the underlying problem. I can see two paths forward. > >> >> > > >> >> > 1. Abandon 6-freebsd-12 after releasing 6. This is probably not ideal > >> >> > since what I understand is some users have projects based on > >> >> > 6-freebsd-12 and would like an upgrade path. (I guess there is also > >> >> > the option to abandon master, which also makes little sense.) > >> >> > >> >> A variant for this would be to introduce a 6-freebsd-13 that is based on > >> >> the master branch as soon as we have one. That would allow a longer > >> >> maintenance because FreeBSD 12 reaches it's EoL December 2023. > >> >> > >> >> > > >> >> > 2. Pull commits from 6-freebsd-12 into master to make sure master is > >> >> > the development head. in the future, reject patches that only go > >> >> > toward release branches. This has its own problems too. It can > >> >> > realistically only be done in three ways: > >> >> > >> >> Please note that Sebastian mentioned that the file descriptors broke the > >> >> NTP support (at least I think it was NTP; possible that it was another > >> >> submodule). So picking the current version of the patches into the > >> >> master without adding fixes makes the master unusable for some cases. > >> >> > >> >Fixing the problems after making the branches the same will be better > >> >for the long-term, if we can find a path to do it. > >>
Re: libbsd development policy clarification needed?
Am 3. Februar 2023 22:52:48 MEZ schrieb Gedare Bloom : >On Fri, Feb 3, 2023 at 2:39 PM Christian Mauderer wrote: >> >> >> >> Am 3. Februar 2023 22:12:06 MEZ schrieb Gedare Bloom : >> >On Fri, Feb 3, 2023 at 12:52 PM wrote: >> >> >> >> Hello Gedare, >> >> >> >> Am 03.02.23 um 19:51 schrieb Gedare Bloom: >> >> > On Thu, Feb 2, 2023 at 11:24 PM Christian MAUDERER >> >> > wrote: >> >> >> >> >> >> Hello Karel, >> >> >> >> >> >> On 2023-02-02 12:43, Karel Gardas wrote: >> >> >>> >> >> >>> Guys, >> >> >>> >> >> >>> recently I needed to work with RTEMS/NFS. As this is provided by >> >> >>> libbsd >> >> >>> I took this and following two sentences below from master branch >> >> >>> description provided in README I took as granted that master does have >> >> >>> all the features which are currently available and provided by the >> >> >>> project: >> >> >>> >> >> >>> "This branch must be used for libbsd development. Back ports to the >> >> >>> 6-freebsd-12 are allowed." >> >> >>> >> >> >>> I was surprised to be proven wrong then by Fabrizio here: >> >> >>> https://devel.rtems.org/ticket/4723 >> >> >>> >> >> >>> and by later investigation which shows that 6-freebsd-12 branch >> >> >>> accumulated NFS work by Chris done in 2021 which is not presented on >> >> >>> master. I've investigated just NFS as this was my focus here. >> >> >>> >> >> >>> So if 6-freebsd-12 became development branch of some sort, then it >> >> >>> would >> >> >>> be great to have that clarified in the project README file to prevent >> >> >>> users confusion? Or if the policy is still the same, then perhaps some >> >> >>> branch sync is needed here? >> >> >> >> >> >> That currently is an open issue. Basically there is a pending patch set >> >> >> that should fix that since several months. But there is a disagreement >> >> >> about some of the changes in that patch set (and about the patches >> >> >> checked in to 6-freebsd-12). Therefore, it still hasn't been merged. >> >> >> >> >> >> If you want to know some more about the problematic points, I recommend >> >> >> reading this (long) thread: >> >> >> >> >> >> https://lists.rtems.org/pipermail/devel/2023-January/074164.html >> >> >> >> >> >> The statement that development has to happen on the master branch is >> >> >> still true. The master is intended to track the FreeBSD upstream >> >> >> development. Only changes on that branch are guaranteed to live through >> >> >> an upgrade to a newer base version of FreeBSD. It's very unfortunate, >> >> >> that there are some patches on the 6-freebsd-12 branch only. On the >> >> >> long >> >> >> term, that issue has to be resolved. >> >> >> >> >> > >> >> > I have been investigating this problem in the background, and I have >> >> > some findings and some questions. First, I have found that there is a >> >> > most-common ancestor between master and 6-freebsd-12 at commit >> >> > https://git.rtems.org/rtems-libbsd/commit/?h=6-freebsd-12=2ce13cf6dc73855f28bc7edbbc64dc4b482a4976 >> >> > This is at least promising that the discrepancy between the branches >> >> > can be resolved. >> >> > >> >> > The proposed pending patch set to "fix" the NFS issue does not fix the >> >> > underlying problem. Instead, it introduces further divergence between >> >> > the branches. I would instead suggest that we should resolve to fix >> >> > the underlying problem. I can see two paths forward. >> >> > >> >> > 1. Abandon 6-freebsd-12 after releasing 6. This is probably not ideal >> >> > since what I understand is some users have projects based on >> >> > 6-freebsd-12 and would like an upgrade path. (I guess there is also >> >> > the option to abandon master, which also makes little sense.) >> >> >> >> A variant for this would be to introduce a 6-freebsd-13 that is based on >> >> the master branch as soon as we have one. That would allow a longer >> >> maintenance because FreeBSD 12 reaches it's EoL December 2023. >> >> >> >> > >> >> > 2. Pull commits from 6-freebsd-12 into master to make sure master is >> >> > the development head. in the future, reject patches that only go >> >> > toward release branches. This has its own problems too. It can >> >> > realistically only be done in three ways: >> >> >> >> Please note that Sebastian mentioned that the file descriptors broke the >> >> NTP support (at least I think it was NTP; possible that it was another >> >> submodule). So picking the current version of the patches into the >> >> master without adding fixes makes the master unusable for some cases. >> >> >> >Fixing the problems after making the branches the same will be better >> >for the long-term, if we can find a path to do it. >> > >> >> > >> >> > 2a: Rebase master and cherry-pick commits from 6-freebsd-12 and master >> >> > back into master. This rewrites the history of master, and >> >> > unfortunately will cause the head of 5-freebsd-12 and the tags for >> >> > rtems-5 to no longer exist on the master branch. They will still exist >> >> > in the '5' branch. The
Re: libbsd development policy clarification needed?
On Fri, Feb 3, 2023 at 2:39 PM Christian Mauderer wrote: > > > > Am 3. Februar 2023 22:12:06 MEZ schrieb Gedare Bloom : > >On Fri, Feb 3, 2023 at 12:52 PM wrote: > >> > >> Hello Gedare, > >> > >> Am 03.02.23 um 19:51 schrieb Gedare Bloom: > >> > On Thu, Feb 2, 2023 at 11:24 PM Christian MAUDERER > >> > wrote: > >> >> > >> >> Hello Karel, > >> >> > >> >> On 2023-02-02 12:43, Karel Gardas wrote: > >> >>> > >> >>> Guys, > >> >>> > >> >>> recently I needed to work with RTEMS/NFS. As this is provided by libbsd > >> >>> I took this and following two sentences below from master branch > >> >>> description provided in README I took as granted that master does have > >> >>> all the features which are currently available and provided by the > >> >>> project: > >> >>> > >> >>> "This branch must be used for libbsd development. Back ports to the > >> >>> 6-freebsd-12 are allowed." > >> >>> > >> >>> I was surprised to be proven wrong then by Fabrizio here: > >> >>> https://devel.rtems.org/ticket/4723 > >> >>> > >> >>> and by later investigation which shows that 6-freebsd-12 branch > >> >>> accumulated NFS work by Chris done in 2021 which is not presented on > >> >>> master. I've investigated just NFS as this was my focus here. > >> >>> > >> >>> So if 6-freebsd-12 became development branch of some sort, then it > >> >>> would > >> >>> be great to have that clarified in the project README file to prevent > >> >>> users confusion? Or if the policy is still the same, then perhaps some > >> >>> branch sync is needed here? > >> >> > >> >> That currently is an open issue. Basically there is a pending patch set > >> >> that should fix that since several months. But there is a disagreement > >> >> about some of the changes in that patch set (and about the patches > >> >> checked in to 6-freebsd-12). Therefore, it still hasn't been merged. > >> >> > >> >> If you want to know some more about the problematic points, I recommend > >> >> reading this (long) thread: > >> >> > >> >> https://lists.rtems.org/pipermail/devel/2023-January/074164.html > >> >> > >> >> The statement that development has to happen on the master branch is > >> >> still true. The master is intended to track the FreeBSD upstream > >> >> development. Only changes on that branch are guaranteed to live through > >> >> an upgrade to a newer base version of FreeBSD. It's very unfortunate, > >> >> that there are some patches on the 6-freebsd-12 branch only. On the long > >> >> term, that issue has to be resolved. > >> >> > >> > > >> > I have been investigating this problem in the background, and I have > >> > some findings and some questions. First, I have found that there is a > >> > most-common ancestor between master and 6-freebsd-12 at commit > >> > https://git.rtems.org/rtems-libbsd/commit/?h=6-freebsd-12=2ce13cf6dc73855f28bc7edbbc64dc4b482a4976 > >> > This is at least promising that the discrepancy between the branches > >> > can be resolved. > >> > > >> > The proposed pending patch set to "fix" the NFS issue does not fix the > >> > underlying problem. Instead, it introduces further divergence between > >> > the branches. I would instead suggest that we should resolve to fix > >> > the underlying problem. I can see two paths forward. > >> > > >> > 1. Abandon 6-freebsd-12 after releasing 6. This is probably not ideal > >> > since what I understand is some users have projects based on > >> > 6-freebsd-12 and would like an upgrade path. (I guess there is also > >> > the option to abandon master, which also makes little sense.) > >> > >> A variant for this would be to introduce a 6-freebsd-13 that is based on > >> the master branch as soon as we have one. That would allow a longer > >> maintenance because FreeBSD 12 reaches it's EoL December 2023. > >> > >> > > >> > 2. Pull commits from 6-freebsd-12 into master to make sure master is > >> > the development head. in the future, reject patches that only go > >> > toward release branches. This has its own problems too. It can > >> > realistically only be done in three ways: > >> > >> Please note that Sebastian mentioned that the file descriptors broke the > >> NTP support (at least I think it was NTP; possible that it was another > >> submodule). So picking the current version of the patches into the > >> master without adding fixes makes the master unusable for some cases. > >> > >Fixing the problems after making the branches the same will be better > >for the long-term, if we can find a path to do it. > > > >> > > >> > 2a: Rebase master and cherry-pick commits from 6-freebsd-12 and master > >> > back into master. This rewrites the history of master, and > >> > unfortunately will cause the head of 5-freebsd-12 and the tags for > >> > rtems-5 to no longer exist on the master branch. They will still exist > >> > in the '5' branch. The advantage is in the end there will be a linear > >> > history of development on master that reflects the timeline of actual > >> > development that spanned both branches.
Re: libbsd development policy clarification needed?
Am 3. Februar 2023 22:12:06 MEZ schrieb Gedare Bloom : >On Fri, Feb 3, 2023 at 12:52 PM wrote: >> >> Hello Gedare, >> >> Am 03.02.23 um 19:51 schrieb Gedare Bloom: >> > On Thu, Feb 2, 2023 at 11:24 PM Christian MAUDERER >> > wrote: >> >> >> >> Hello Karel, >> >> >> >> On 2023-02-02 12:43, Karel Gardas wrote: >> >>> >> >>> Guys, >> >>> >> >>> recently I needed to work with RTEMS/NFS. As this is provided by libbsd >> >>> I took this and following two sentences below from master branch >> >>> description provided in README I took as granted that master does have >> >>> all the features which are currently available and provided by the >> >>> project: >> >>> >> >>> "This branch must be used for libbsd development. Back ports to the >> >>> 6-freebsd-12 are allowed." >> >>> >> >>> I was surprised to be proven wrong then by Fabrizio here: >> >>> https://devel.rtems.org/ticket/4723 >> >>> >> >>> and by later investigation which shows that 6-freebsd-12 branch >> >>> accumulated NFS work by Chris done in 2021 which is not presented on >> >>> master. I've investigated just NFS as this was my focus here. >> >>> >> >>> So if 6-freebsd-12 became development branch of some sort, then it would >> >>> be great to have that clarified in the project README file to prevent >> >>> users confusion? Or if the policy is still the same, then perhaps some >> >>> branch sync is needed here? >> >> >> >> That currently is an open issue. Basically there is a pending patch set >> >> that should fix that since several months. But there is a disagreement >> >> about some of the changes in that patch set (and about the patches >> >> checked in to 6-freebsd-12). Therefore, it still hasn't been merged. >> >> >> >> If you want to know some more about the problematic points, I recommend >> >> reading this (long) thread: >> >> >> >> https://lists.rtems.org/pipermail/devel/2023-January/074164.html >> >> >> >> The statement that development has to happen on the master branch is >> >> still true. The master is intended to track the FreeBSD upstream >> >> development. Only changes on that branch are guaranteed to live through >> >> an upgrade to a newer base version of FreeBSD. It's very unfortunate, >> >> that there are some patches on the 6-freebsd-12 branch only. On the long >> >> term, that issue has to be resolved. >> >> >> > >> > I have been investigating this problem in the background, and I have >> > some findings and some questions. First, I have found that there is a >> > most-common ancestor between master and 6-freebsd-12 at commit >> > https://git.rtems.org/rtems-libbsd/commit/?h=6-freebsd-12=2ce13cf6dc73855f28bc7edbbc64dc4b482a4976 >> > This is at least promising that the discrepancy between the branches >> > can be resolved. >> > >> > The proposed pending patch set to "fix" the NFS issue does not fix the >> > underlying problem. Instead, it introduces further divergence between >> > the branches. I would instead suggest that we should resolve to fix >> > the underlying problem. I can see two paths forward. >> > >> > 1. Abandon 6-freebsd-12 after releasing 6. This is probably not ideal >> > since what I understand is some users have projects based on >> > 6-freebsd-12 and would like an upgrade path. (I guess there is also >> > the option to abandon master, which also makes little sense.) >> >> A variant for this would be to introduce a 6-freebsd-13 that is based on >> the master branch as soon as we have one. That would allow a longer >> maintenance because FreeBSD 12 reaches it's EoL December 2023. >> >> > >> > 2. Pull commits from 6-freebsd-12 into master to make sure master is >> > the development head. in the future, reject patches that only go >> > toward release branches. This has its own problems too. It can >> > realistically only be done in three ways: >> >> Please note that Sebastian mentioned that the file descriptors broke the >> NTP support (at least I think it was NTP; possible that it was another >> submodule). So picking the current version of the patches into the >> master without adding fixes makes the master unusable for some cases. >> >Fixing the problems after making the branches the same will be better >for the long-term, if we can find a path to do it. > >> > >> > 2a: Rebase master and cherry-pick commits from 6-freebsd-12 and master >> > back into master. This rewrites the history of master, and >> > unfortunately will cause the head of 5-freebsd-12 and the tags for >> > rtems-5 to no longer exist on the master branch. They will still exist >> > in the '5' branch. The advantage is in the end there will be a linear >> > history of development on master that reflects the timeline of actual >> > development that spanned both branches. Theoretically, this should >> > make it easier to git-bisect. >> > >> > 2b: Cherry-pick commits from 6-freebsd-12 to master and fix conflicts. >> > This puts all the missing commits from 6-freebsd-12 on to the current >> > head of master. I don't know how messy this would
Re: libbsd development policy clarification needed?
On Fri, Feb 3, 2023 at 12:52 PM wrote: > > Hello Gedare, > > Am 03.02.23 um 19:51 schrieb Gedare Bloom: > > On Thu, Feb 2, 2023 at 11:24 PM Christian MAUDERER > > wrote: > >> > >> Hello Karel, > >> > >> On 2023-02-02 12:43, Karel Gardas wrote: > >>> > >>> Guys, > >>> > >>> recently I needed to work with RTEMS/NFS. As this is provided by libbsd > >>> I took this and following two sentences below from master branch > >>> description provided in README I took as granted that master does have > >>> all the features which are currently available and provided by the > >>> project: > >>> > >>> "This branch must be used for libbsd development. Back ports to the > >>> 6-freebsd-12 are allowed." > >>> > >>> I was surprised to be proven wrong then by Fabrizio here: > >>> https://devel.rtems.org/ticket/4723 > >>> > >>> and by later investigation which shows that 6-freebsd-12 branch > >>> accumulated NFS work by Chris done in 2021 which is not presented on > >>> master. I've investigated just NFS as this was my focus here. > >>> > >>> So if 6-freebsd-12 became development branch of some sort, then it would > >>> be great to have that clarified in the project README file to prevent > >>> users confusion? Or if the policy is still the same, then perhaps some > >>> branch sync is needed here? > >> > >> That currently is an open issue. Basically there is a pending patch set > >> that should fix that since several months. But there is a disagreement > >> about some of the changes in that patch set (and about the patches > >> checked in to 6-freebsd-12). Therefore, it still hasn't been merged. > >> > >> If you want to know some more about the problematic points, I recommend > >> reading this (long) thread: > >> > >> https://lists.rtems.org/pipermail/devel/2023-January/074164.html > >> > >> The statement that development has to happen on the master branch is > >> still true. The master is intended to track the FreeBSD upstream > >> development. Only changes on that branch are guaranteed to live through > >> an upgrade to a newer base version of FreeBSD. It's very unfortunate, > >> that there are some patches on the 6-freebsd-12 branch only. On the long > >> term, that issue has to be resolved. > >> > > > > I have been investigating this problem in the background, and I have > > some findings and some questions. First, I have found that there is a > > most-common ancestor between master and 6-freebsd-12 at commit > > https://git.rtems.org/rtems-libbsd/commit/?h=6-freebsd-12=2ce13cf6dc73855f28bc7edbbc64dc4b482a4976 > > This is at least promising that the discrepancy between the branches > > can be resolved. > > > > The proposed pending patch set to "fix" the NFS issue does not fix the > > underlying problem. Instead, it introduces further divergence between > > the branches. I would instead suggest that we should resolve to fix > > the underlying problem. I can see two paths forward. > > > > 1. Abandon 6-freebsd-12 after releasing 6. This is probably not ideal > > since what I understand is some users have projects based on > > 6-freebsd-12 and would like an upgrade path. (I guess there is also > > the option to abandon master, which also makes little sense.) > > A variant for this would be to introduce a 6-freebsd-13 that is based on > the master branch as soon as we have one. That would allow a longer > maintenance because FreeBSD 12 reaches it's EoL December 2023. > > > > > 2. Pull commits from 6-freebsd-12 into master to make sure master is > > the development head. in the future, reject patches that only go > > toward release branches. This has its own problems too. It can > > realistically only be done in three ways: > > Please note that Sebastian mentioned that the file descriptors broke the > NTP support (at least I think it was NTP; possible that it was another > submodule). So picking the current version of the patches into the > master without adding fixes makes the master unusable for some cases. > Fixing the problems after making the branches the same will be better for the long-term, if we can find a path to do it. > > > > 2a: Rebase master and cherry-pick commits from 6-freebsd-12 and master > > back into master. This rewrites the history of master, and > > unfortunately will cause the head of 5-freebsd-12 and the tags for > > rtems-5 to no longer exist on the master branch. They will still exist > > in the '5' branch. The advantage is in the end there will be a linear > > history of development on master that reflects the timeline of actual > > development that spanned both branches. Theoretically, this should > > make it easier to git-bisect. > > > > 2b: Cherry-pick commits from 6-freebsd-12 to master and fix conflicts. > > This puts all the missing commits from 6-freebsd-12 on to the current > > head of master. I don't know how messy this would be. It ends up > > making the history of master convoluted to understand, with fairly old > > commits from 2018 being placed on top of newer commits from
Re: libbsd development policy clarification needed?
Hello Gedare, Am 03.02.23 um 19:51 schrieb Gedare Bloom: On Thu, Feb 2, 2023 at 11:24 PM Christian MAUDERER wrote: Hello Karel, On 2023-02-02 12:43, Karel Gardas wrote: Guys, recently I needed to work with RTEMS/NFS. As this is provided by libbsd I took this and following two sentences below from master branch description provided in README I took as granted that master does have all the features which are currently available and provided by the project: "This branch must be used for libbsd development. Back ports to the 6-freebsd-12 are allowed." I was surprised to be proven wrong then by Fabrizio here: https://devel.rtems.org/ticket/4723 and by later investigation which shows that 6-freebsd-12 branch accumulated NFS work by Chris done in 2021 which is not presented on master. I've investigated just NFS as this was my focus here. So if 6-freebsd-12 became development branch of some sort, then it would be great to have that clarified in the project README file to prevent users confusion? Or if the policy is still the same, then perhaps some branch sync is needed here? That currently is an open issue. Basically there is a pending patch set that should fix that since several months. But there is a disagreement about some of the changes in that patch set (and about the patches checked in to 6-freebsd-12). Therefore, it still hasn't been merged. If you want to know some more about the problematic points, I recommend reading this (long) thread: https://lists.rtems.org/pipermail/devel/2023-January/074164.html The statement that development has to happen on the master branch is still true. The master is intended to track the FreeBSD upstream development. Only changes on that branch are guaranteed to live through an upgrade to a newer base version of FreeBSD. It's very unfortunate, that there are some patches on the 6-freebsd-12 branch only. On the long term, that issue has to be resolved. I have been investigating this problem in the background, and I have some findings and some questions. First, I have found that there is a most-common ancestor between master and 6-freebsd-12 at commit https://git.rtems.org/rtems-libbsd/commit/?h=6-freebsd-12=2ce13cf6dc73855f28bc7edbbc64dc4b482a4976 This is at least promising that the discrepancy between the branches can be resolved. The proposed pending patch set to "fix" the NFS issue does not fix the underlying problem. Instead, it introduces further divergence between the branches. I would instead suggest that we should resolve to fix the underlying problem. I can see two paths forward. 1. Abandon 6-freebsd-12 after releasing 6. This is probably not ideal since what I understand is some users have projects based on 6-freebsd-12 and would like an upgrade path. (I guess there is also the option to abandon master, which also makes little sense.) A variant for this would be to introduce a 6-freebsd-13 that is based on the master branch as soon as we have one. That would allow a longer maintenance because FreeBSD 12 reaches it's EoL December 2023. 2. Pull commits from 6-freebsd-12 into master to make sure master is the development head. in the future, reject patches that only go toward release branches. This has its own problems too. It can realistically only be done in three ways: Please note that Sebastian mentioned that the file descriptors broke the NTP support (at least I think it was NTP; possible that it was another submodule). So picking the current version of the patches into the master without adding fixes makes the master unusable for some cases. 2a: Rebase master and cherry-pick commits from 6-freebsd-12 and master back into master. This rewrites the history of master, and unfortunately will cause the head of 5-freebsd-12 and the tags for rtems-5 to no longer exist on the master branch. They will still exist in the '5' branch. The advantage is in the end there will be a linear history of development on master that reflects the timeline of actual development that spanned both branches. Theoretically, this should make it easier to git-bisect. 2b: Cherry-pick commits from 6-freebsd-12 to master and fix conflicts. This puts all the missing commits from 6-freebsd-12 on to the current head of master. I don't know how messy this would be. It ends up making the history of master convoluted to understand, with fairly old commits from 2018 being placed on top of newer commits from 2020s. 2c: Merge 6-freebsd-12 into master and fixup conflicts in the merge commit. This is pretty similar to 2a but ends up with a non-linear history and a merge commit. It may be a fairly complex merge commit. For all of the 2x solutions: The commits from 6-freebsd-12 can't just be cherry-picked. You have to re-import the NFS files from the FreeBSD master version that is used as base for the current libbsd master. Otherwise we mix different FreeBSD source versions. We had that some time back in libbsd and Sebastian needed a lot of time cleaning
Re: libbsd development policy clarification needed?
On Thu, Feb 2, 2023 at 11:24 PM Christian MAUDERER wrote: > > Hello Karel, > > On 2023-02-02 12:43, Karel Gardas wrote: > > > >Guys, > > > > recently I needed to work with RTEMS/NFS. As this is provided by libbsd > > I took this and following two sentences below from master branch > > description provided in README I took as granted that master does have > > all the features which are currently available and provided by the project: > > > > "This branch must be used for libbsd development. Back ports to the > > 6-freebsd-12 are allowed." > > > > I was surprised to be proven wrong then by Fabrizio here: > > https://devel.rtems.org/ticket/4723 > > > > and by later investigation which shows that 6-freebsd-12 branch > > accumulated NFS work by Chris done in 2021 which is not presented on > > master. I've investigated just NFS as this was my focus here. > > > > So if 6-freebsd-12 became development branch of some sort, then it would > > be great to have that clarified in the project README file to prevent > > users confusion? Or if the policy is still the same, then perhaps some > > branch sync is needed here? > > That currently is an open issue. Basically there is a pending patch set > that should fix that since several months. But there is a disagreement > about some of the changes in that patch set (and about the patches > checked in to 6-freebsd-12). Therefore, it still hasn't been merged. > > If you want to know some more about the problematic points, I recommend > reading this (long) thread: > > https://lists.rtems.org/pipermail/devel/2023-January/074164.html > > The statement that development has to happen on the master branch is > still true. The master is intended to track the FreeBSD upstream > development. Only changes on that branch are guaranteed to live through > an upgrade to a newer base version of FreeBSD. It's very unfortunate, > that there are some patches on the 6-freebsd-12 branch only. On the long > term, that issue has to be resolved. > I have been investigating this problem in the background, and I have some findings and some questions. First, I have found that there is a most-common ancestor between master and 6-freebsd-12 at commit https://git.rtems.org/rtems-libbsd/commit/?h=6-freebsd-12=2ce13cf6dc73855f28bc7edbbc64dc4b482a4976 This is at least promising that the discrepancy between the branches can be resolved. The proposed pending patch set to "fix" the NFS issue does not fix the underlying problem. Instead, it introduces further divergence between the branches. I would instead suggest that we should resolve to fix the underlying problem. I can see two paths forward. 1. Abandon 6-freebsd-12 after releasing 6. This is probably not ideal since what I understand is some users have projects based on 6-freebsd-12 and would like an upgrade path. (I guess there is also the option to abandon master, which also makes little sense.) 2. Pull commits from 6-freebsd-12 into master to make sure master is the development head. in the future, reject patches that only go toward release branches. This has its own problems too. It can realistically only be done in three ways: 2a: Rebase master and cherry-pick commits from 6-freebsd-12 and master back into master. This rewrites the history of master, and unfortunately will cause the head of 5-freebsd-12 and the tags for rtems-5 to no longer exist on the master branch. They will still exist in the '5' branch. The advantage is in the end there will be a linear history of development on master that reflects the timeline of actual development that spanned both branches. Theoretically, this should make it easier to git-bisect. 2b: Cherry-pick commits from 6-freebsd-12 to master and fix conflicts. This puts all the missing commits from 6-freebsd-12 on to the current head of master. I don't know how messy this would be. It ends up making the history of master convoluted to understand, with fairly old commits from 2018 being placed on top of newer commits from 2020s. 2c: Merge 6-freebsd-12 into master and fixup conflicts in the merge commit. This is pretty similar to 2a but ends up with a non-linear history and a merge commit. It may be a fairly complex merge commit. To get a sense of the difference between the two branches, I have done the following command: $ git log --pretty=oneline master...6-freebsd-12 > ../log.txt This uses the ... (three-dot) Symmetric Difference Notation. The result of that is a 750 line file, so 750 commits are different between the two branches. Some of those commits are actually the same content, but they have different parents so different hashes. In a rebase or merge situation, those commits should end up the same. There may be other git-fu to find just the patches that are unique in the two branches. In any case, doing this in a way that ensures the commits build and tests run is challenging due to the interactions with the rtems.git, toolchain, and the submodules. After the 6-freebsd-12 and master are made
Re: libbsd development policy clarification needed?
Hello Karel, On 2023-02-02 12:43, Karel Gardas wrote: Guys, recently I needed to work with RTEMS/NFS. As this is provided by libbsd I took this and following two sentences below from master branch description provided in README I took as granted that master does have all the features which are currently available and provided by the project: "This branch must be used for libbsd development. Back ports to the 6-freebsd-12 are allowed." I was surprised to be proven wrong then by Fabrizio here: https://devel.rtems.org/ticket/4723 and by later investigation which shows that 6-freebsd-12 branch accumulated NFS work by Chris done in 2021 which is not presented on master. I've investigated just NFS as this was my focus here. So if 6-freebsd-12 became development branch of some sort, then it would be great to have that clarified in the project README file to prevent users confusion? Or if the policy is still the same, then perhaps some branch sync is needed here? That currently is an open issue. Basically there is a pending patch set that should fix that since several months. But there is a disagreement about some of the changes in that patch set (and about the patches checked in to 6-freebsd-12). Therefore, it still hasn't been merged. If you want to know some more about the problematic points, I recommend reading this (long) thread: https://lists.rtems.org/pipermail/devel/2023-January/074164.html The statement that development has to happen on the master branch is still true. The master is intended to track the FreeBSD upstream development. Only changes on that branch are guaranteed to live through an upgrade to a newer base version of FreeBSD. It's very unfortunate, that there are some patches on the 6-freebsd-12 branch only. On the long term, that issue has to be resolved. Best regards Christian I'm fine with either way, as a user I just need clear not confusing project message... Thanks! Karel ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel -- embedded brains GmbH Herr Christian MAUDERER Dornierstr. 4 82178 Puchheim Germany email: christian.maude...@embedded-brains.de phone: +49-89-18 94 741 - 18 mobile: +49-176-152 206 08 Registergericht: Amtsgericht München Registernummer: HRB 157899 Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler Unsere Datenschutzerklärung finden Sie hier: https://embedded-brains.de/datenschutzerklaerung/ ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
libbsd development policy clarification needed?
Guys, recently I needed to work with RTEMS/NFS. As this is provided by libbsd I took this and following two sentences below from master branch description provided in README I took as granted that master does have all the features which are currently available and provided by the project: "This branch must be used for libbsd development. Back ports to the 6-freebsd-12 are allowed." I was surprised to be proven wrong then by Fabrizio here: https://devel.rtems.org/ticket/4723 and by later investigation which shows that 6-freebsd-12 branch accumulated NFS work by Chris done in 2021 which is not presented on master. I've investigated just NFS as this was my focus here. So if 6-freebsd-12 became development branch of some sort, then it would be great to have that clarified in the project README file to prevent users confusion? Or if the policy is still the same, then perhaps some branch sync is needed here? I'm fine with either way, as a user I just need clear not confusing project message... Thanks! Karel ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
