Build system migrations are not easy: Lessons from empirical studies of KDE and Linux kernel
•
1 gefällt mir•1,290 views
This document summarizes the key findings of a study on build system migrations in large open source projects. It identifies common migration methodologies, challenges, and lessons learned. Major contributions include identifying a spiral model for incremental migrations. Key challenges are requirements gathering, communication between roles, and balancing performance vs complexity. The study compares a failed migration (SCons for KDE) to a successful one (CMake for Linux kernel) to understand best practices for requirements elicitation, analysis, and stakeholder involvement.
Empfohlen
Empfohlen
Weitere ähnliche Inhalte
Ähnlich wie Build system migrations are not easy: Lessons from empirical studies of KDE and Linux kernel
Ähnlich wie Build system migrations are not easy: Lessons from empirical studies of KDE and Linux kernel (20)
Kürzlich hochgeladen
Kürzlich hochgeladen (20)
Build system migrations are not easy: Lessons from empirical studies of KDE and Linux kernel
- 1. An Empirical Study of Build System Migrations in Practice Case Studies on KDE and the Linux Kernel 1 R. Suvorov, B.Adams, M. Nagappan, A. E. Hassan,Y. Zou
- 2. Analogy: Car Assembly 2 +4x + assembly +
- 3. Build System Transforms Source Code & Resources into Executables 3 + bdSys +
- 4. bdSys is at the Heart of the Development Process! 4 bdSys + Developers QA Personnel Testers
- 5. bdSys Technology is “different” 5
- 6. bdSys Technology is “different” 5 Our record so far is a project weinherited with an Ant scriptweighing in at 10,000 lines ofXML. Needless to say, this projectrequired an entire team devotedto keeping the build working - acomplete waste of resources.[Jez Humble & David Farley] KDE 4 is leaving the aging "autotool" build chain behind. Some developers, not only in KDE, like to nickname the autotools as "auto-hell" because of its difficult to comprehend architecture. [Alexander Neundorf] I've been examining the existingkernel configuration system, andconcluded that the best favor wecould do everybody involved withit is to take it out behind the barnand shoot it through thehead. [Eric Raymond]
- 7. ... yet a bdSys Must Keep on Evolving 6 MLOC
- 8. ..., in fact a bdSys Changes Relatively More than Source Code 71 (c) McIntosh et al.: “An Empirical Study of Build Maintenance Effort”
- 9. ..., in fact a bdSys Changes Relatively More than Source Code 71 ArgoUML Hibernate Eclipse GCC Git Linux Mozilla PLPlot PostgreSQL 0 0.5 1 1.5 2 2.5 3 3.5 4 4.5 5 # changes / source file # changes / build file (c) McIntosh et al.: “An Empirical Study of Build Maintenance Effort”
- 10. ..., in fact a bdSys Changes Relatively More than Source Code 71 ArgoUML Hibernate Eclipse GCC Git Linux Mozilla PLPlot PostgreSQL 0 0.5 1 1.5 2 2.5 3 3.5 4 4.5 5 # changes / source file # changes / build file (c) McIntosh et al.: “An Empirical Study of Build Maintenance Effort”
- 11. ..., in fact a bdSys Changes Relatively More than Source Code 71 ArgoUML Hibernate Eclipse GCC Git Linux Mozilla PLPlot PostgreSQL 0 0.5 1 1.5 2 2.5 3 3.5 4 4.5 5 # changes / source file # changes / build file (c) McIntosh et al.: “An Empirical Study of Build Maintenance Effort”
- 12. In Other Words ... 8
- 13. In Other Words ... 8 Software Projects need HELP Maintaining their Build Systems
- 14. The “easy” way out: Build System Migrations 9
- 15. The “easy” way out: Build System Migrations 9
- 16. 10
- 17. 11
- 18. 12
- 19. 12 Build system migrations are not that easy! But why?
- 21. Study Setup • Linux & KDE: • Two established projects: 21 & 16 years old • Large: 25 & 4.3 MLOC • 1 failed & 1 successful migration each • Data sources: • git repos: 300 K & 100 K commits • 4 mailing lists, over 1.5 million messages 14
- 22. Quantitative Study of Developer Commits • git repositories • Native git tools + bash scripts • Statistics on source & bdSys code: • Evolution • Churn • Distinguish between “normal” periods & migrations 15
- 23. Qualitative Analysis of Developer Communication • Personal emails to migration participants • Mailing lists • Mass-downloaded and analyzed • Statistics on number of messages: • By groups (roles) • By period of time • Distinguish between “normal” periods & migrations 16
- 26. The Spiral Model of bdSys Migration 19 1. Planning 2. Risk Analysis 3. Development 4. Evaluation
- 27. Why? Migration is Incremental! • Linux kernel • 33K+ source code files • 2,300+ subdirectories • 5 major subsystems • KDE • 11K+ source code files • 22 packages 20
- 33. Communication Among Key Participants 23 bdSys Manager major decisions
- 34. Communication Among Key Participants 23 bdSys Manager major decisions bdSys Champion leading bdSys dev’t
- 35. Communication Among Key Participants 23 bdSys Manager major decisions bdSys Champion leading bdSys dev’t bdSys Expert bdSys contributor
- 36. Communication Among Key Participants 23 bdSys Manager major decisions bdSys Champion leading bdSys dev’t bdSys Expert bdSys contributor Core Developer source contributor
- 37. Major Challenges • Communication issues • Build experts form a sub-community often reluctant to communicate effectively • Performance vs. complexity • Improving performance often means introducing hacks • Effective evaluation • When is migration "successfully finished"? How to measure? • Requirements gathering (see remainder) 24
- 44. Example bdSys Requirements • Platform independence • Two new major platforms: Mac OS X & Windows • High-level configuration • Single-pass methodology • Away with multiple-steps build! • Simple and platform-independent syntax 27
- 45. Requirements Gathering Process 1. Stakeholder identification - who? • Who needs to be involved? 2. Elicitation • What requirements are there? 3. Analysis • Get all requirement data. Resolve conflicts, refine and organize. 4. Specification & Maintenance • Document & order resulting requirements. 28
- 46. How SCons failed • Stakeholder identification • Only 150 of 800 developers attended aKademy • Elicitation • Too little, too late: “trawled” for requirements • Analysis • Not enough attention paid to this phase! • Specification & Maintenance • Not done at all! 29
- 47. 30 “the main SCons tree has intolerable problems, and there are so many layers [...] that it barely resembles what a normal SCons build system looks like. Don't get me wrong; I use SCons at work and I really like it, but if it isn't capable of handling KDE then why are we trying to make it do so? Is it really worth keeping a KDE specific build system (which is what we are moving towards)? [...] Perhaps it’s time to cut our losses and run.” [Jaison Lee] As a Result:
- 48. Rise and Fall of SCons 31 %max(LOC)
- 49. How succeeded • Stakeholder identification • Learned from SCons. Involved experts early. • Elicitation • Reuse some of SCons’ data. Active participation by experts! • Analysis • Identified conflicting requirements early. • Specification & Maintenance • An initiative by the build champion. 32
- 52. 33 Common Migration Methodology Major Migration Challenges Major Challenge: Requirements Gathering spiral model! requirements communication performance evaluation migration happens incrementally involve all stakeholders identify & resolve conflicts
- 53. 33 Common Migration Methodology Major Migration Challenges Major Challenge: Requirements Gathering spiral model! requirements communication performance evaluation migration happens incrementally involve all stakeholders identify & resolve conflicts efficient elicitation
- 54. 34
- 57. 34 Major Migration Challenges requirements communication performance evaluation Common Migration Methodology spiral model! migration happens incrementally Major Challenge: Requirements Gathering involve all stakeholders identify & resolve conflicts efficient elicitation