Derivatives panel gobby infinote://gobby.debian.org/debconf15/panel/derivatives 2015-08-20 at 11:00 localtime. Members Chaired by Paul Wise Raphael Hertzog representing Kali Linux Joshua Powers representing hLinux Nolan Leake representing Cumulus Linux Adrián Gibanel López representing Rescatux Matthias Klumpp representing Tanglu Solvieg representing Tails ... Backups Gaudenz Steinlin for Lernstick other Tails folks Michael Prokop for Grml Emmanuel Kasper for Proxmox John Vert representing SteamOS maybe some folks for Ubuntu? Prepared questions Introductions; briefly tell us about your derivative and your role in it. What are we (Debian) doing well? Why base on Debian and not another distro (Fedora etc)? What can we do to make derivative's lives easier? What is your experience of rebranding Debian? What are your derivatives doing for Debian? Where do you want to see your distro in 5 years? Any plans for the near future? What are some challenges your derivative has faced or is facing? Do you import the full Debian archive or is your derivative an overlay? Are any of your developers members of Debian or in NM? Funding sources and relationships with your corporate backer? Influence development direction? Release cycle working for you? Those derivatives not based on stable; how is your release process different or better than Debian? How could we accommodate your improvements within Debian? When patching orphaned packages, do you do QA uploads? ARM strategies - dealing with a multitude of kernel versions and binary blobs. Preinstalled/OEM images - Some derivatives are producing images of pre-installed systems. How are you dealing with things like avoiding having OpenSSH generated private keys in the image. Should Debian do things in a more optimal way? Is your repository key(ring) in Debian's archive? If not would this be interesting for you/should we consider doing this? Have you considered becoming a Blend rather than a derivative? Discussion summary LArjona's notes from the DebConf15 Derivatives panel (after watching the video) Why Debian? * Strong focus on Quality Assurance: the packages from Debian are very well tested and work well * Making a derivative in top of Debian is not very hard * Tradition of supporting derivatives in Debian community * Strong community (big), no need to go to a commercial entity to look for support. * Licenses checked out: we can be sure what is free software and what is not * Support of different architectures, no need to recompile packages. * Consistency among the whole archive (different packages work well together) * You can focus in the packages and particularities of your derivative, the rest it just works, and it's well maintained by the Debian community. * Debian is stable, when you want to build a live system to fix computers, you need that system to work well, to be stable. * Other Debian derivatives can get benefit of your improvements (if you derive from Ubuntu, for example, only Ubuntu derivatives will benefit, probably) * It's the best known. Why not Debian? (Why a derivative? How is it going the relationship?) * A few software not suitable for Debian main (e.g. software with licenses not allowing attacks in Kali) * We ship web applications whose dependencies are not in Debian and it would be very hard. * Dropping certain architectures, or achieving new ones. * The release cycles may not be adequate (time-based release cycle, for example) * Contributing directly upstream. * Defaults for target users of the derivative may not be adequate for Debian (less flexible, etc). Guidelines: Ideas for improving Bug reports (coordination) * Specific bug tracker, and filter: to Debian or directly to upstream * Inserting the word hlinux in the name of the package if they modified the source (then avoid sending bugs directly to Debian) * Reportbug display the link to the correct bug tracker or mailing list or whatever: looks like easy to implement * Don't ship reportbug What can we do in Debian to make derivative's life easier * Strong ownership of packages in Debian (packager uploads whenever (s)he consider and can break things in derivatives): coordinated uploads (know when or where to upload) or declare the versions supported. * Reproducible builds. * Trademark issues. * Testing builds (backports) * Raise awareness in Debian about some packages actually being used by derivatives and maybe consider twice before removing them, or contact the corresponding team. * Any effort to improve testing (make it really working all the time) * Debian is a great upstream, thank you! * Improve debian derivatives wiki * "Bring your packages into Debian": ok, but we should also improve the communication with derivatives * Make the Debian infrastructure work also for derivatives (hardcoded distributions names (unstable, testing) in dak, for example) * Derivative makes some changes that are not suitable for Debian: ok, but include it with a conditional that can be activated if the packaged is installed in the derivative (separate patch, for example. This way people could switch easily between the Debian and the derivative flavours).