Change in coreboot[master]: 4.12 release notes: Add some explanation behind depreciations
Arthur Heymans has uploaded this change for review. ( https://review.coreboot.org/c/coreboot/+/37064 )
Change subject: 4.12 release notes: Add some explanation behind depreciations ......................................................................
4.12 release notes: Add some explanation behind depreciations
Some features are made mandatory, meaning that some platforms have been dropped from master. This also explains that further development on these popular platforms can happen on the 4.11 branch.
TODO is this really the right place or is it too technical for release notes?
Change-Id: I95e01c301e7db6f81ef88a89d709ebab35c9ccfb Signed-off-by: Arthur Heymans arthur@aheymans.xyz --- M Documentation/releases/coreboot-4.12-relnotes.md 1 file changed, 61 insertions(+), 0 deletions(-)
git pull ssh://review.coreboot.org:29418/coreboot refs/changes/64/37064/1
diff --git a/Documentation/releases/coreboot-4.12-relnotes.md b/Documentation/releases/coreboot-4.12-relnotes.md index f9c5f7e..67bef34 100644 --- a/Documentation/releases/coreboot-4.12-relnotes.md +++ b/Documentation/releases/coreboot-4.12-relnotes.md @@ -10,6 +10,67 @@ * The chip and board additions and removals will be updated right before the release, so those do not need to be added.
+Deprecations +------------ + +For the 4.12 release a few features on x86 became mandatory. These are +relocatable ramstage, postcar stage and C_ENVIRONMENT_BOOTBLOCK. + +### Relocatable ramstage + +Relocatable stages are a feature only implemented only on x86, where +stages can be relocated at runtime. This is used to place ramstage in +a better location that does not collide with memory the OS tends to +use. The rationale behind making this mandatory is that you always +want cbmem to be cached so it's a good location to run ramstage from. +It avoids using lower memory altogether so the OS can make use +of it and no backing up needs to happen on S3 resume. + +### Postcar stage + +With Postcar stage tearing down Cache-as-Ram is done in a separate +stage. This means that romstage has a clean program boundary and +that all variables in romstage can be accessed via their initial +reference at all times. There is no need to link global and static +variables via the CAR_GLOBAL macro and no need to access them with +car_set/get_var/ptr functions. + +### C_ENVIRONMENT_BOOTBLOCK + +Historically the bootblock on x86 platforms has been compiled with +romcc. This means that the generated code only uses CPU registers +and therefore no stack. This 20K+ LOC compiler is limited and hard +to maintain. A different solution is to set up Cache-as-Ram in the +bootblock and run GCC compiled code in the bootblock. The advantages +are increased flexibility: e.g. printing to console is possible and +VBOOT can run before romstage, making romstage updatable via RW FMAP +regions. + +### Platforms dropped from master + +The following platforms did not implement those feature are dropped +from master to allow the master branch to move on: +- AMDFAM10 +- all FSP1.0 platforms: BROADWELL_DE, FSP_BAYTRAIL, RANGELEY +- VIA VX900 +- TODO (AMD?) + +In particular on FSP1.0 it is impossible to implement POSTCAR stage. +The reason is that FSP1.0 relocates the CAR region to the HOB before +returning to coreboot. This means that after FSP returns to coreboot +accessing variables via their original address is not possible. One +way of obtaining that behavior would be to set up Cache-as-Ram again +(but with open source code) and copy the relocated data from the HOB +there. This solution is deemed too hacky. Maybe a lesson can be +learned from this: blobs should not interfere with the execution +environment, as this makes proper integration much harder. + +### 4.11_branch + +Given that some platforms supported by FSP1.0 are being produced and +popular, the 4.11 release was made into a branch in which further +development can happen. + Significant changes -------------------
Aaron Durbin has posted comments on this change. ( https://review.coreboot.org/c/coreboot/+/37064 )
Change subject: 4.12 release notes: Add some explanation behind depreciations ......................................................................
Patch Set 1:
(3 comments)
https://review.coreboot.org/c/coreboot/+/37064/1/Documentation/releases/core... File Documentation/releases/coreboot-4.12-relnotes.md:
https://review.coreboot.org/c/coreboot/+/37064/1/Documentation/releases/core... PS1, Line 33: initial : reference linked addresses without runtime address resolution.
https://review.coreboot.org/c/coreboot/+/37064/1/Documentation/releases/core... PS1, Line 42: compiler And the code one has to write/use/maintain in that environment.
https://review.coreboot.org/c/coreboot/+/37064/1/Documentation/releases/core... PS1, Line 45: flexibility as well as consistency across architectures as well as the code utilized in each stage.
Hello Aaron Durbin, David Hendricks, Patrick Georgi,
I'd like you to reexamine a change. Please visit
https://review.coreboot.org/c/coreboot/+/37064
to look at the new patch set (#2).
Change subject: 4.12 release notes: Add some explanation behind depreciations ......................................................................
4.12 release notes: Add some explanation behind depreciations
Some features are made mandatory, meaning that some platforms have been dropped from master. This also explains that further development on these popular platforms can happen on the 4.11 branch.
TODO is this really the right place or is it too technical for release notes?
Change-Id: I95e01c301e7db6f81ef88a89d709ebab35c9ccfb Signed-off-by: Arthur Heymans arthur@aheymans.xyz --- M Documentation/releases/coreboot-4.12-relnotes.md 1 file changed, 63 insertions(+), 0 deletions(-)
git pull ssh://review.coreboot.org:29418/coreboot refs/changes/64/37064/2
Arthur Heymans has posted comments on this change. ( https://review.coreboot.org/c/coreboot/+/37064 )
Change subject: 4.12 release notes: Add some explanation behind depreciations ......................................................................
Patch Set 2:
(3 comments)
https://review.coreboot.org/c/coreboot/+/37064/1/Documentation/releases/core... File Documentation/releases/coreboot-4.12-relnotes.md:
https://review.coreboot.org/c/coreboot/+/37064/1/Documentation/releases/core... PS1, Line 33: initial : reference
linked addresses without runtime address resolution.
Done
https://review.coreboot.org/c/coreboot/+/37064/1/Documentation/releases/core... PS1, Line 42: compiler
And the code one has to write/use/maintain in that environment.
Done
https://review.coreboot.org/c/coreboot/+/37064/1/Documentation/releases/core... PS1, Line 45: flexibility
as well as consistency across architectures as well as the code utilized in each stage.
Done
Aaron Durbin has posted comments on this change. ( https://review.coreboot.org/c/coreboot/+/37064 )
Change subject: 4.12 release notes: Add some explanation behind depreciations ......................................................................
Patch Set 2:
(1 comment)
https://review.coreboot.org/c/coreboot/+/37064/2/Documentation/releases/core... File Documentation/releases/coreboot-4.12-relnotes.md:
https://review.coreboot.org/c/coreboot/+/37064/2/Documentation/releases/core... PS2, Line 46: e y
Hello Aaron Durbin, David Hendricks, build bot (Jenkins), Patrick Georgi,
I'd like you to reexamine a change. Please visit
https://review.coreboot.org/c/coreboot/+/37064
to look at the new patch set (#3).
Change subject: 4.12 release notes: Add some explanation behind depreciations ......................................................................
4.12 release notes: Add some explanation behind depreciations
Some features are made mandatory, meaning that some platforms have been dropped from master. This also explains that further development on these popular platforms can happen on the 4.11 branch.
TODO is this really the right place or is it too technical for release notes?
Change-Id: I95e01c301e7db6f81ef88a89d709ebab35c9ccfb Signed-off-by: Arthur Heymans arthur@aheymans.xyz --- M Documentation/releases/coreboot-4.12-relnotes.md 1 file changed, 63 insertions(+), 0 deletions(-)
git pull ssh://review.coreboot.org:29418/coreboot refs/changes/64/37064/3
Aaron Durbin has posted comments on this change. ( https://review.coreboot.org/c/coreboot/+/37064 )
Change subject: 4.12 release notes: Add some explanation behind depreciations ......................................................................
Patch Set 3: Code-Review+2
Kyösti Mälkki has posted comments on this change. ( https://review.coreboot.org/c/coreboot/+/37064 )
Change subject: 4.12 release notes: Add some explanation behind depreciations ......................................................................
Patch Set 3: Code-Review+1
(3 comments)
https://review.coreboot.org/c/coreboot/+/37064/3/Documentation/releases/core... File Documentation/releases/coreboot-4.12-relnotes.md:
https://review.coreboot.org/c/coreboot/+/37064/3/Documentation/releases/core... PS3, Line 21: Relocatable stages are a feature only implemented only on x86, where -only
https://review.coreboot.org/c/coreboot/+/37064/3/Documentation/releases/core... PS3, Line 27: of it and no backing up needs to happen on S3 resume. Also, non-relocatable ramstage sometimes collided with the loaded payload. But we kind of fixed those bounce-buffers with a workaround (of which nobody has complained so far).
https://review.coreboot.org/c/coreboot/+/37064/3/Documentation/releases/core... PS3, Line 74: development can happen. I find the last paragraph about 4.11 somewhat redundant but if you want to mention this explicitly go ahead.
Hello Kyösti Mälkki, Aaron Durbin, David Hendricks, build bot (Jenkins), Patrick Georgi,
I'd like you to reexamine a change. Please visit
https://review.coreboot.org/c/coreboot/+/37064
to look at the new patch set (#4).
Change subject: 4.12 release notes: Add some explanation behind depreciations ......................................................................
4.12 release notes: Add some explanation behind depreciations
Some features are made mandatory, meaning that some platforms have been dropped from master. This also explains that further development on these popular platforms can happen on the 4.11 branch.
TODO is this really the right place or is it too technical for release notes?
Change-Id: I95e01c301e7db6f81ef88a89d709ebab35c9ccfb Signed-off-by: Arthur Heymans arthur@aheymans.xyz --- M Documentation/releases/coreboot-4.12-relnotes.md 1 file changed, 63 insertions(+), 0 deletions(-)
git pull ssh://review.coreboot.org:29418/coreboot refs/changes/64/37064/4
Kyösti Mälkki has posted comments on this change. ( https://review.coreboot.org/c/coreboot/+/37064 )
Change subject: 4.12 release notes: Add some explanation behind depreciations ......................................................................
Patch Set 4: Code-Review+1
(4 comments)
https://review.coreboot.org/c/coreboot/+/37064/2/Documentation/releases/core... File Documentation/releases/coreboot-4.12-relnotes.md:
https://review.coreboot.org/c/coreboot/+/37064/2/Documentation/releases/core... PS2, Line 46: e
y
Done
https://review.coreboot.org/c/coreboot/+/37064/3/Documentation/releases/core... File Documentation/releases/coreboot-4.12-relnotes.md:
https://review.coreboot.org/c/coreboot/+/37064/3/Documentation/releases/core... PS3, Line 21: Relocatable stages are a feature only implemented only on x86, where
-only
Done
https://review.coreboot.org/c/coreboot/+/37064/3/Documentation/releases/core... PS3, Line 27: of it and no backing up needs to happen on S3 resume.
Also, non-relocatable ramstage sometimes collided with the loaded payload. […]
Done
https://review.coreboot.org/c/coreboot/+/37064/3/Documentation/releases/core... PS3, Line 74: development can happen.
I find the last paragraph about 4. […]
Ack
Kyösti Mälkki has posted comments on this change. ( https://review.coreboot.org/c/coreboot/+/37064 )
Change subject: 4.12 release notes: Add some explanation behind depreciations ......................................................................
Patch Set 4:
(1 comment)
https://review.coreboot.org/c/coreboot/+/37064/4//COMMIT_MSG Commit Message:
https://review.coreboot.org/c/coreboot/+/37064/4//COMMIT_MSG@14 PS4, Line 14: notes? Maybe the depreciation arguments could be a file of its own, not tied to the most recent release?
Angel Pons has posted comments on this change. ( https://review.coreboot.org/c/coreboot/+/37064 )
Change subject: 4.12 release notes: Add some explanation behind depreciations ......................................................................
Patch Set 4:
(1 comment)
https://review.coreboot.org/c/coreboot/+/37064/4//COMMIT_MSG Commit Message:
https://review.coreboot.org/c/coreboot/+/37064/4//COMMIT_MSG@7 PS4, Line 7: depreciations deprecations
Denis 'GNUtoo' Carikli has posted comments on this change. ( https://review.coreboot.org/c/coreboot/+/37064 )
Change subject: 4.12 release notes: Add some explanation behind depreciations ......................................................................
Patch Set 4:
(1 comment)
https://review.coreboot.org/c/coreboot/+/37064/4//COMMIT_MSG Commit Message:
https://review.coreboot.org/c/coreboot/+/37064/4//COMMIT_MSG@14 PS4, Line 14: notes?
Maybe the depreciation arguments could be a file of its own, not tied to the most recent release?
I think it would also be a important to create a file about deprecation itself with: - Arguments for dropping support for hardware, along with arguments against it (in order not to keep re-doing huge debates about it), and why the argument for dropping hardware won. - How it is possible to change the decision (like majority of developers for + bring a new argument that is compelling and that was not already taken into account). - Ideas on how to deal with deprecation (For instance something that tell people to read the releases notes at each release, submit test results in board-status because it'll require less work to convert the mainboard if it's already working on master, paying people to do the work(how?), etc) - Information on how to decide to force hardware to be converted to a new API or drop boards.
I've the feeling that many developers like me (maybe not the ones that are the most involved) have issue dealing with the idea that the hardware you use, depend on, or your work could be removed as it seems that there is no unique reference on the topic, and that the information is instead scattered around, leading to misunderstanding. If there is such document I would be very happy to be pointed at it.
If not, I'll probably consider working on that but not before next year as I'm overbooked theses days. I'll probably start by digging information in the the community meeting reports since 2017 as I was pointed to it on IRC.
Denis 'GNUtoo' Carikli has posted comments on this change. ( https://review.coreboot.org/c/coreboot/+/37064 )
Change subject: 4.12 release notes: Add some explanation behind depreciations ......................................................................
Patch Set 4:
(1 comment)
https://review.coreboot.org/c/coreboot/+/37064/4/Documentation/releases/core... File Documentation/releases/coreboot-4.12-relnotes.md:
https://review.coreboot.org/c/coreboot/+/37064/4/Documentation/releases/core... PS4, Line 40: Historically the bootblock on x86 platforms has been compiled with : romcc. This means that the generated code only uses CPU registers : and therefore no stack. This 20K+ LOC compiler is limited and hard : to maintain and so is the code that one has to write in that : environment. A different solution is to set up Cache-as-Ram in the : bootblock and run GCC compiled code in the bootblock. The advantages : are increased flexibility and consistency with other architectures as : well as other stages: e.g. printing to console is possible and : VBOOT can run before romstage, making romstage updatable via RW FMAP : regions. If the normal/fallback mechanism is dropped as a consequence of this change, it would also be a good idea to mention that.
Angel Pons has posted comments on this change. ( https://review.coreboot.org/c/coreboot/+/37064 )
Change subject: 4.12 release notes: Add some explanation behind depreciations ......................................................................
Patch Set 4:
(1 comment)
https://review.coreboot.org/c/coreboot/+/37064/4/Documentation/releases/core... File Documentation/releases/coreboot-4.12-relnotes.md:
https://review.coreboot.org/c/coreboot/+/37064/4/Documentation/releases/core... PS4, Line 40: Historically the bootblock on x86 platforms has been compiled with : romcc. This means that the generated code only uses CPU registers : and therefore no stack. This 20K+ LOC compiler is limited and hard : to maintain and so is the code that one has to write in that : environment. A different solution is to set up Cache-as-Ram in the : bootblock and run GCC compiled code in the bootblock. The advantages : are increased flexibility and consistency with other architectures as : well as other stages: e.g. printing to console is possible and : VBOOT can run before romstage, making romstage updatable via RW FMAP : regions.
If the normal/fallback mechanism is dropped as a consequence of this change, it would also be a good […]
It's not about dropping it or not, it's that when you change the bootblock, you can't use normal/fallback as-is to test the new bootblock
Kyösti Mälkki has posted comments on this change. ( https://review.coreboot.org/c/coreboot/+/37064 )
Change subject: 4.12 release notes: Add some explanation behind depreciations ......................................................................
Patch Set 4:
(1 comment)
https://review.coreboot.org/c/coreboot/+/37064/4/Documentation/releases/core... File Documentation/releases/coreboot-4.12-relnotes.md:
https://review.coreboot.org/c/coreboot/+/37064/4/Documentation/releases/core... PS4, Line 40: Historically the bootblock on x86 platforms has been compiled with : romcc. This means that the generated code only uses CPU registers : and therefore no stack. This 20K+ LOC compiler is limited and hard : to maintain and so is the code that one has to write in that : environment. A different solution is to set up Cache-as-Ram in the : bootblock and run GCC compiled code in the bootblock. The advantages : are increased flexibility and consistency with other architectures as : well as other stages: e.g. printing to console is possible and : VBOOT can run before romstage, making romstage updatable via RW FMAP : regions.
It's not about dropping it or not, it's that when you change the bootblock, you can't use normal/fal […]
Well the attempt is to design bootblock to be read-only flash region.
The equivalent of normal/fallback mechanism should appear for testing in just a few days.
David Hendricks has posted comments on this change. ( https://review.coreboot.org/c/coreboot/+/37064 )
Change subject: 4.12 release notes: Add some explanation behind depreciations ......................................................................
Patch Set 4: Code-Review+2
(1 comment)
https://review.coreboot.org/c/coreboot/+/37064/4//COMMIT_MSG Commit Message:
https://review.coreboot.org/c/coreboot/+/37064/4//COMMIT_MSG@14 PS4, Line 14: notes?
I think it would also be a important to create a file about deprecation itself with: […]
You're correct and this is a good idea, however I think it's outside the scope of this patch which is specific to FSP 1.0 deprecation.
David Hendricks has posted comments on this change. ( https://review.coreboot.org/c/coreboot/+/37064 )
Change subject: 4.12 release notes: Add some explanation behind depreciations ......................................................................
Patch Set 5:
Friendly ping. Was there anything left to do here?
Hello build bot (Jenkins), Patrick Georgi, David Hendricks, Angel Pons, Kyösti Mälkki, Aaron Durbin,
I'd like you to reexamine a change. Please visit
https://review.coreboot.org/c/coreboot/+/37064
to look at the new patch set (#6).
Change subject: 4.12 release notes: Add some explanation behind deprecations ......................................................................
4.12 release notes: Add some explanation behind deprecations
Some features are made mandatory, meaning that some platforms have been dropped from master. This also explains that further development on these popular platforms can happen on the 4.11 branch.
TODO is this really the right place or is it too technical for release notes?
Change-Id: I95e01c301e7db6f81ef88a89d709ebab35c9ccfb Signed-off-by: Arthur Heymans arthur@aheymans.xyz --- M Documentation/releases/coreboot-4.12-relnotes.md 1 file changed, 63 insertions(+), 0 deletions(-)
git pull ssh://review.coreboot.org:29418/coreboot refs/changes/64/37064/6
Arthur Heymans has posted comments on this change. ( https://review.coreboot.org/c/coreboot/+/37064 )
Change subject: 4.12 release notes: Add some explanation behind deprecations ......................................................................
Patch Set 6:
(3 comments)
https://review.coreboot.org/c/coreboot/+/37064/4//COMMIT_MSG Commit Message:
https://review.coreboot.org/c/coreboot/+/37064/4//COMMIT_MSG@7 PS4, Line 7: depreciations
deprecations
Done
https://review.coreboot.org/c/coreboot/+/37064/4//COMMIT_MSG@14 PS4, Line 14: notes?
You're correct and this is a good idea, however I think it's outside the scope of this patch which i […]
Ack
https://review.coreboot.org/c/coreboot/+/37064/4/Documentation/releases/core... File Documentation/releases/coreboot-4.12-relnotes.md:
https://review.coreboot.org/c/coreboot/+/37064/4/Documentation/releases/core... PS4, Line 40: Historically the bootblock on x86 platforms has been compiled with : romcc. This means that the generated code only uses CPU registers : and therefore no stack. This 20K+ LOC compiler is limited and hard : to maintain and so is the code that one has to write in that : environment. A different solution is to set up Cache-as-Ram in the : bootblock and run GCC compiled code in the bootblock. The advantages : are increased flexibility and consistency with other architectures as : well as other stages: e.g. printing to console is possible and : VBOOT can run before romstage, making romstage updatable via RW FMAP : regions.
Well the attempt is to design bootblock to be read-only flash region. […]
Done
Angel Pons has posted comments on this change. ( https://review.coreboot.org/c/coreboot/+/37064 )
Change subject: 4.12 release notes: Add some explanation behind deprecations ......................................................................
Patch Set 6: Code-Review+2
Paul Menzel has posted comments on this change. ( https://review.coreboot.org/c/coreboot/+/37064 )
Change subject: 4.12 release notes: Add some explanation behind deprecations ......................................................................
Patch Set 6: Code-Review+1
Patrick Georgi has submitted this change. ( https://review.coreboot.org/c/coreboot/+/37064 )
Change subject: 4.12 release notes: Add some explanation behind deprecations ......................................................................
4.12 release notes: Add some explanation behind deprecations
Some features are made mandatory, meaning that some platforms have been dropped from master. This also explains that further development on these popular platforms can happen on the 4.11 branch.
TODO is this really the right place or is it too technical for release notes?
Change-Id: I95e01c301e7db6f81ef88a89d709ebab35c9ccfb Signed-off-by: Arthur Heymans arthur@aheymans.xyz Reviewed-on: https://review.coreboot.org/c/coreboot/+/37064 Tested-by: build bot (Jenkins) no-reply@coreboot.org Reviewed-by: Angel Pons th3fanbus@gmail.com Reviewed-by: Paul Menzel paulepanter@users.sourceforge.net Reviewed-by: Kyösti Mälkki kyosti.malkki@gmail.com Reviewed-by: David Hendricks david.hendricks@gmail.com --- M Documentation/releases/coreboot-4.12-relnotes.md 1 file changed, 63 insertions(+), 0 deletions(-)
Approvals: build bot (Jenkins): Verified David Hendricks: Looks good to me, approved Kyösti Mälkki: Looks good to me, but someone else must approve Paul Menzel: Looks good to me, but someone else must approve Angel Pons: Looks good to me, approved
diff --git a/Documentation/releases/coreboot-4.12-relnotes.md b/Documentation/releases/coreboot-4.12-relnotes.md index 7943aa7..b172c4a 100644 --- a/Documentation/releases/coreboot-4.12-relnotes.md +++ b/Documentation/releases/coreboot-4.12-relnotes.md @@ -10,6 +10,69 @@ * The chip and board additions and removals will be updated right before the release, so those do not need to be added.
+Deprecations +------------ + +For the 4.12 release a few features on x86 became mandatory. These are +relocatable ramstage, postcar stage and C_ENVIRONMENT_BOOTBLOCK. + +### Relocatable ramstage + +Relocatable stages are a feature implemented only on x86, where stages +can be relocated at runtime. This is used to place ramstage in a better +location that does not collide with memory the OS or the payload tends +to use. The rationale behind making this mandatory is that you always +want cbmem to be cached so it's a good location to run ramstage from. +It avoids using lower memory altogether so the OS can make use of it +and no backing up needs to happen on S3 resume. + +### Postcar stage + +With Postcar stage tearing down Cache-as-Ram is done in a separate +stage. This means that romstage has a clean program boundary and +that all variables in romstage can be accessed via their linked +addresses without runtime resolution. There is no need to link +global and static variables via the CAR_GLOBAL macro and no need +to access them with car_set/get_var/ptr functions. + +### C_ENVIRONMENT_BOOTBLOCK + +Historically the bootblock on x86 platforms has been compiled with +romcc. This means that the generated code only uses CPU registers +and therefore no stack. This 20K+ LOC compiler is limited and hard +to maintain and so is the code that one has to write in that +environment. A different solution is to set up Cache-as-Ram in the +bootblock and run GCC compiled code in the bootblock. The advantages +are increased flexibility and consistency with other architectures as +well as other stages: e.g. printing to console is possible and +VBOOT can run before romstage, making romstage updatable via RW FMAP +regions. + +### Platforms dropped from master + +The following platforms did not implement those feature are dropped +from master to allow the master branch to move on: +- AMDFAM10 +- all FSP1.0 platforms: BROADWELL_DE, FSP_BAYTRAIL, RANGELEY +- VIA VX900 +- TODO (AMD?) + +In particular on FSP1.0 it is impossible to implement POSTCAR stage. +The reason is that FSP1.0 relocates the CAR region to the HOB before +returning to coreboot. This means that after FSP returns to coreboot +accessing variables via their original address is not possible. One +way of obtaining that behavior would be to set up Cache-as-Ram again +(but with open source code) and copy the relocated data from the HOB +there. This solution is deemed too hacky. Maybe a lesson can be +learned from this: blobs should not interfere with the execution +environment, as this makes proper integration much harder. + +### 4.11_branch + +Given that some platforms supported by FSP1.0 are being produced and +popular, the 4.11 release was made into a branch in which further +development can happen. + Significant changes -------------------
-
Aaron Durbin (Code Review) -
Angel Pons (Code Review)
-
Arthur Heymans (Code Review)
-
David Hendricks (Code Review)
-
Denis 'GNUtoo' Carikli (Code Review)
-
Kyösti Mälkki (Code Review)
-
Patrick Georgi (Code Review)
-
Paul Menzel (Code Review)