Talk:The Case for Using Wiki Version History

Meta-Discussion

Major advantages on git - what are those advantages? What problem are we trying to solve?

Once we are clear on advantages, and problem we are solving - we have an answer.

The first question for you - what are those advantages of Git that our workflow can benefit from? What problem is a Git platform solving that is important to us, that is not addressed by the wiki versioning?

Major Advantages

1. SupportMediaWiki’s major target is Wikipedia. Wikipedia was not intended to be used as a development environment but rather as an encyclopedia. Support and for using it as a version control system is likely going to be limited.
2. Robustness - Git is well tested as a versioning system vs not many people use MediaWiki as a versioning tool. Counterargument: yes, robustness in software, but it is not robust for open hardware development. For example, it can't handle video.
3. Data Replication - With git every collaborator has a copy of the file, they could work even when the server is down. Should a problem with the server happen, every collaborator has a backup.
4. Versions have a hash key - In Git every commit has a unique hash key it can be referred to. A version can always be linked to by its unique hash - In Wikipedia on the other hand there is only a timestamp and the current version changes retains its link after a new version is added. Old versions can be accessed directly via their unique link.
5. Extensibility/Automation - Git servers usually have the ability to do certain tasks when a new version is uploaded. A continuous integration server can automatically check files for correctness and create preview images.
6. Access Control - In git, a part of the developers can be maintainers that first have to check changes before they make it into the official version.
7. Accidental Overwrites- In Wikipedia two people could submit a file at the same moment and not see that another person did the same, one of the commits would be overwritten - Git prohibits this behavior. That said, I can see that WikiMedia might just be good enough for now but I would also be open to doing a few demos on how git could be used as an alternative.

Is any one of the reasons important enough?

Discussion

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

1. You don't control the data with Gitlab
2. Visual Version History
3. Collaboration on a scale
4. 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

Q: 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.

A: Qeustion 3 implies that the problem statement is not reconciliation (commits). It's more about who puts up the effort to build. Yes, we can all collaborate on digital design and treat it like software - ie, someone takes the control of commits. Because you cannot pre-allocate the commit-control role, you cannot scale in the same way in hardware as in software.