On Mon, Jul 13, 2020 at 06:05:42PM -0400, Corey Clayton wrote: > On Mon, Jul 13, 2020 at 12:25:42PM -0600, Simon Glass wrote: > > > At present U-Boot uses the mailing list for patch review. What do > > people think about trying out geritt or github for this? I'd be > > willing to do a trial with the -dm mailing list. > > This is both my first message to the mailing list and my first > email sent using mutt. I'm hoping to eventually participate > with patches and reviews but the mailing-list-driven > developement model has been a barrier for myself an probably > many others. I'm slowly trying to climb over it now but some > will never find the time. Perhaps a good question is: How long > does it take to learn the mailing-list workflow vs the github > workflow? > > If u-boot was using github, I would have contributed long ago > and I suspect there are others in the same bucket. Thats my > perspective at least :)
Hello, to provide a different perspective: if U-Boot would have done everything inside github instead of using its traditional mailinglist-based workflow, I would never have contributed to U-Boot, and moving everything from the mailinglist to github would make any future contributions infeasible for me. The github workflow makes it impossible to open an issue or to comment on an existing issue or to provide feedback about a patch without being a github customer, and becoming a github customer is not an option for me (and quite a number of other open-source developers) as the github TOS contain clauses that I (and other people) consider completely unacceptable. Besides the aforementioned points I am generally concerned about the closed nature of the github issue- and pull-request system. While it is of course easily possible to move a git repo from github to somewhere else, it is as far as I know (please correct me if I should me misinformed here) not possible to export the comments and discussions in issues and pull requests in any meaningful way to some other hosting platform, which creates a strong vendor-lock-in once a project starts using the github issue and pull-request facilities. With the traditional mailinglist-based workflow on the other hand, moving everything to another hosting platform is trivial, so vendor-lock-in is not a problem there. Another problem that I see in the github workflow is that it requires being online all the time while the mailinglist-based workflow makes it easy to read and comment on patches while being offline. I am sure that many people will now think "everybody is online all day nowadays", but that's not true everywhere. I for example travel a lot by train and use the time on the train for catching up with current developments and for reviewing things. Where I live, for most practical purposes being on the train effectively means being offline as far as modern web applications are concerned. Availability of mobile internet access is spotty at best, and if one has internet connectivity inside the train at all, it is often so slow that using it for interactive work on a web interface is not feasible. Receiving, writing and sending emails on the other hand works without problems even with spotty and slow internet connectivity. Regards, Karsten -- Hiermit widerspreche ich ausdrücklich der Nutzung sowie der Weitergabe meiner personenbezogenen Daten für Zwecke der Werbung sowie der Markt- oder Meinungsforschung.
