Originally posted by mdedetrich
View Post
Section 11-13 out of the processes the Linux kernel runs by. Sign off does not mean approved to merge in Linux kernel procedures. Its extra meta data process. First person to sign off is the person who wrote the patch or modify the patch.
Concept of assign reviewer that is not the Linux kernel works section 13. Anyone who wishes to review can review a patch and resubmit patch to mailing list with a Reviewed-by: statement.
None of these different sign off means the patch will be merged.
Originally posted by mdedetrich
View Post
Originally posted by mdedetrich
View Post
Git repos for the way the Linux kernel mailing list need to operate to get around different filters is far to strict. Remember lag tolerance. Mailing list archives can insert newly arrived messages into the archive before entries that had already arrived because those have been delayed in transport somewhere.
Originally posted by mdedetrich
View Post
This is not a easy problem.
Originally posted by mdedetrich
View Post
[QUOTE=mdedetrich;n1201485]Also I am pretty sure there isn't going to be a problem for anyone in the world to access a website. Github is accessible in places like China for example (hilariously China tried to ban Github but failed when there was a massive outcry of developers being unable to do their work).
China has not given up filtering Github neither has other countries. So isn't going to be a problem is really putting you head in sand with current state of play. Projects on github can be not accessable to different users around the world.
Current state of play requires a solution more durable than what a single hosted location can provide. Git of Linux gets mirrored and the mailing lists get archived in many different countries and if maintainer thinks someone who should have responded with the email system around mailing lists has not responded they can email them directly.
This is all about creating as many routes to connect to individual contributors/reviews as possible. Mailing list archives don't require database servers and have tolerance to be slightly out of sync. Tolerance to be slightly out of sync is required to deal with global filtering.
Originally posted by mdedetrich
View Post
Some hosted github instance is not going to cut it. You need multi instances of something like gitlab able to remain somewhat in sync when countries deciding to cause communication disruptions. Preferable with something with mailing list archive level of out of sync tolerance.
Thing here the Linux kernel mailing lists show you don't need 100 percent perfect sync for all the information about kernel development as long the information in the mailing lists into sync in few days. As in email messages in mailing list if they are delayed by 2 to 3 days getting to developers the effect to Linux kernel productivity is minor. This gives time to work around any forms of country filtering or the possibility that the country just quits doing it.
This is a way higher bar to get over. I would like to see a gitlab like item with this level of tolerance to disruptions. Its really easy to overlook that the git and mailing list Linux kernel development is using is highly tolerant to government disruptions. There is a old saying don't throw the baby out with the bath water. There is something really good about the Linux kernel development setup that alternatives do need to be equal to and that is the tolerance level to disruption it has .
Comment