Talk:The Case for Using Wiki Version History: Difference between revisions
| Line 24: | Line 24: | ||
== 3. Collaboration at a scale == | == 3. Collaboration at a scale == | ||
I think there is a case that the access privileges are much better with Git. I believe that pull requests are probably necessary on a very large scale collaboration. | Q: I think there is a case that the access privileges are much better with Git. I believe that pull requests are probably necessary on a very large scale collaboration. | ||
A: That is specific to software workflows. In hardware workflows, authority is more distributed. The builder has ultimate authority. A software platform of Git relies on commits and commit control. A hardware platform needs to rely on 'non-commits'. I mean that every design is valid until it is tested. Because there is no uniform compiler in hardware, or it is more expensive to 'compile' or build - much work by default remains non-reconciled or 'un-committed' - as a potential viable fork. So in summary, hardware by its nature requires no access privileges - as decision-making (on commits or reconciliatiuon) is much more distributed in hardware. Ie, the guy in Africa, North Pole, Europe, and rural american town all need equal access - and whoever builds, decides. So permissions are simple: all source is open, and any build is an effective fork. So it seems that the workflow from software is the general idea, but in practice - the practices are subtly different. Specifically: you don't need access privileges - default is all open and the builder is the actual committer. You can't assign roles and privileges in hardware - it doesn't make sense. | |||
== 4. It is currently used for a large set of parts == | == 4. It is currently used for a large set of parts == | ||
I think this point is very strong and that the transition could be a lot of work. But I still think that it could be worth it, and it should be tried out. | I think this point is very strong and that the transition could be a lot of work. But I still think that it could be worth it, and it should be tried out. | ||
Revision as of 02:08, 8 February 2021
I agree that given that you are using a wiki as a repository you would want to just upload a new version of a file and use it. I just think that MediaWiki was not intended to be used as a repository.
If I understand correctly the reason you gave for not using Git are
- You don't control the data with Gitlab
- Visual Version History
- Collaboration on a scale
- It is currently used for a large set of parts (this was not included originally but I think it is important)
I still think Git has major advantages and want to give counterpoints to the arguments above
1. You don't control the data with Gitlab
Q: I don't understand this, why don't you own the data, you can host it on your server.
A: Then why not just use our server? This means that we're hosting the data in 2 places, so why not just host it on our servers? And if Gitlab decides to end service, we have to have a local backup. Or if it changes its interface or usage terms, we may have to rework significant parts of our workflow. We need absolute control of our data as we are a long-term project.
2. Visual Version History
Q. I think that Visual Version History should not be a problem, you can either just continue using the wiki and then link to the git files. Even better, the visual version history could be automatically created as a commit hook and on GitLab.
A. Could be created: a visual gallery like in the wiki, but it already exists in Mediawiki so why reinvent the wheel? The wiki already has all the formatting to make this easy. And we don't want to require people understanding how to use Git platforms, which is a higher learning curve than a wiki.
3. Collaboration at a scale
Q: I think there is a case that the access privileges are much better with Git. I believe that pull requests are probably necessary on a very large scale collaboration.
A: That is specific to software workflows. In hardware workflows, authority is more distributed. The builder has ultimate authority. A software platform of Git relies on commits and commit control. A hardware platform needs to rely on 'non-commits'. I mean that every design is valid until it is tested. Because there is no uniform compiler in hardware, or it is more expensive to 'compile' or build - much work by default remains non-reconciled or 'un-committed' - as a potential viable fork. So in summary, hardware by its nature requires no access privileges - as decision-making (on commits or reconciliatiuon) is much more distributed in hardware. Ie, the guy in Africa, North Pole, Europe, and rural american town all need equal access - and whoever builds, decides. So permissions are simple: all source is open, and any build is an effective fork. So it seems that the workflow from software is the general idea, but in practice - the practices are subtly different. Specifically: you don't need access privileges - default is all open and the builder is the actual committer. You can't assign roles and privileges in hardware - it doesn't make sense.
4. It is currently used for a large set of parts
I think this point is very strong and that the transition could be a lot of work. But I still think that it could be worth it, and it should be tried out.