* Stefan Tauner email@example.com [151231 19:18]:
My counterproposal is to use gitub instead of Gerrit.
- We (relatively) often get patches from one-time contributors which is way easier on github because "everybody" has an account there and knows how to work with it (and if not it is straight forward compared to gerrit).
Unlike with gerrit, you explicitly have to sign up with github. With Gerrit you can use any Oauth2 provider that you already signed up with, significantly lowering the entry barrier
- We don't really need jenkins. I am not a big fan of CI although I am a fan of build testing (hence flashrom is build tested for over 30 architecture/OS combinations manually). Depending on how it would be to interface my build bot with jenkins it would however be an improvement (not sure if it is worth it though).
That is exactly what we are doing with the current infrastructure, and it has worked quite well for the coreboot project for about five years. Sure you can roll your own and probably end up with something slimmer, but jenkins is well tested and security reviewed, so it is very convenient and basically out of the way once you set it up.
- The only reason to avoid github for me would be due to its proprietary nature and related problems (lock-in etc). Please give me other reasons if you prefer coreboot.org-hosted gerrit over github.
I don't feel as strongly about trusting github with all of your project data, especially as you can recreate the repository from any checked out tree, but I remember the libreboot guys having strong opinions about github.
With a fair amount of overlap between developers, using one common infrastructure for both coreboot and flashrom seems to make sense to me, but honestly, any improvement of both process and tooling would be greatly appreciated. Right now we are going out of our way with one-offs to keep the environment painful.
Though I know stefanct often makes small corrections/modifications to patches before submitting them (because our code review process makes even small amounts of back-and-forth comments so cumbersome). At least this way such changes can be tracked trivially on-line by diffing the N and N-1 patch revisions in gerrit.
The reason is not because the back-and-forth is cumbersome but because I am a perfectionist who does not want to bother others with my annoying views of details and I don't expect anybody to care about these changes like me (this does not always hold). The same goes for commit messages. With Carl-Daniel I do exchange my views about these kind of things *if* there is any exchange that is ;)
I think a cleaner work flow in which it is clear which changes have been done by the original author and what changes have been done by Stefan on top of that would be very beneficial for the project. I don't think that the lack of transparency in this regard can or should be explained by perfectionism.
The auto-tag of every commit sounds like an option I could agree with. It would preserve the convenience of the global strong svn commit ID even for git. However, I don't know if this would be acceptable for Stefan (especially from a merging perspective).
We have the infrastructure for using this kind of version strings since about 2,5 years and there is a patch that would make flashrom use them in prints which is lingering uncommented in the mailing list since August 2013. It might not be exactly what we want eventually, but if there are no comments I'll have to decide on something...
You guys should explore what coreboot has done in this area, also with the work on reproducible builds. As an anecdote, I was insisting on the usefulness of sequencial commit ids just about until the day we switched coreboot to git. What you really want is a process that enables interactive development, tools to track the process, and more frequent releases. Unless you want to make sure that there are exactly two people working on this project, in which case all of this infrastructure talk is really overkill.
My current plan is to do a 0.9.9 release in January 2016 and switch to git afterwards. I'd like to keep patchwork at least for a while and figure out a way to keep the patches.
Cool. Please let me know what your preferred direction is by the end of this month then. We are currently in the process of migrating coreboot.org's services and the old infrastructure as we have it today will most likely be going away around that same time frame.