Notes from Thomas ================= * The importance of scheduling the submission of patches: the community has a limited absorption rate. Need to pipeline the development: develop the new features will you submit/review the previous ones. * Interaction with the vendor tree: - Initially very far from mainline (HAL based): all the code has to be rewritten. Duplicated debugging effort between the teams working on the internal BSP and the team working on mainlining. - Importance of having the mainline code used as a basis for the new internal BSP, and to communicate in both directions the bug fixes. * Choice of compatible strings: mistakes we made by chosing too generic compatible string names (example: "marvell,coherency-fabric"). Don't suppose that you know that two SOCs are the same if they originally look similar: they are often subtle differences that arise later. * Supporting the weird "system registers and functions", mistake of grouping them together in one driver, which breaks on future SOCs. Example of the PMSU on Armada 370/XP vs Armada 375. * Importance of an active sub-achitecture maintainer, to ensure that not only the arch/arm patches get pushed, but also the drivers/ patches. This is especially important for drivers subsystem that are very actively maintained. * Making estimates: a very difficult/impossible task for mainlining work. Example of the PCIe driver. Tips on estimates: if your stuff its in existing frameworks and DT bindings with no change, then things should be fast. If your stuff need an extension of the framework, or a new DT binding, except some fairly long delays. * Mainlining actually works: when new SOCs share many hardware blocks with previous SOCs, their bring up in mainline is fairly quick. * Device Tree binding: don't encode too much hardware details in the DT, and leave them inside the device driver. It allows for greater flexibility when newer SOCs arrive. Notes from Tawfik ================= Problems: - Contradiction between merge windows and commitment to customers. The network issue for the Matrix is a typical problem. We have customers that are blocked because we don't have network working on the Matrix without an external patch. - Qualification level of mainline releases. The kernel cycle time is too short for doing a good QA cycle. So doing QA and introducing fixes might take 2/3 kernel releases to be done. - The race condition between the releasing new Silicone and having it ready in the mainline. Si vendors want the mainline to be ready as closest as possible to Si arrival and at the same time this is not achieved unless having all stuff merged and tested on the real HW. So this is usually of 4-6 months. Take the A380 as a good example. It A380-Z1 was a production silicone, then we would had ~6 months delay between having the silicone and having the first kernel officially supporting the new Hw. Benefits: - Knowledge sharing with the best people in the world. Each in his specific field. - Publicity (Public Relations in other words). - Accessibility to customers. - Standardization. - Support from the mailing lists. - Maintenance over time. Notes from Ezequiel =================== Towards community ----------------- In order to get patches accepted you need to have your patches discussed, reviewed, tested, flamed, shared, etc. A few tips to get this: 1. Write a cover letter or watch your work fall into oblivion It's much nicer for people to read some well-structured, carefully written text describing a set of patches, rather than receiving a bunch of fixes on the mailbox. 2. Push a git branch Not everyone has a nice mutt to apply patches easily. And even the ones that do, are usually lazy to do so. Pushing a patchset as a git branch is almost always a good way of getting Tested-by's. 3. Review others Other than ethical, there's a scientific reason for this. Here's my theory. Statistically speaking you can speed-up your own reviewing process by reviewing other patches *on the same queue*. By queue I mean the group of patches that need to be Acked-by from a specific maintainer before being merged. You can make your own patches move upper on the queue, by picking other patches on the same queue and providing feedback. You don't need to know the hardware or the subsystem deeply, as you can start with the easy stuff, replying about coding styles and simple API usage. After you review something, it's expected the submitter will have to do a v{N+1} which will be submitted after *your* patches in the queue. This way you produce an effective forward-moving. Sounds crazy, uh? 4. Push/ping frequently (?) There are lots of reasons to push a new version of your patches: addressing new feedback, adding Acked-by's, Tested-by's. The idea is to be spammy enough to get attention, but not too spammy to be filtered for life :-) 5. Learn the release cycle So you'll know when the timing is right to send your patchset, and you'll be able to plan your work accordingly. With experience, you'll be able to predict which features will be merged on the next release, and which must wait until the after-next release. 6. Ccing the right people and ML And I'm not talking about monkey-using get_maintainer.pl. Instead, try to build a list of the ones that have been patching and reviewing on the file or driver you're modifying. It's not hard: just use git log and search mailing lists for recent activity. 7. Sync with your reviewing audience It's useful to know the timezone of the people you expect to be reviewed by, so you can be in sync for mail or IRC discussion. This can make the difference between discussing for just one day, or for a full week. 8. Learn to rebase and rework patches in turbo mode Since we spend a lot of time preparing patches, and since we often go through a long reviewing process, and are asked to re-do our work, it's very important to be able to do this painlessly. For instance, you can take advantage of git to fix in-between commits by using a fixup + rebase --interactive alias: fixcommit = !sh -c 'git commit --fixup=$1 $2 && git rebase --interactive --autosquash $1^' - And I guess that's it. I hope some of this makes sense!