5 ms·

> But this decision is a dumb one. What is it with this obsession with telling people how to get sh't done? If they write their code on used kleenex using wax

> But this decision is a dumb one. What is it with this obsession with telling people how to get sh't done? If they write their code on used kleenex using wax crayons and share that using carrier pigeons, I don't give a sh't as long as the finished product is fine.

deleted 12y ago
[deleted]
danielweber 12y ago
It's a perfect example of bike-shedding. Most readers have no way of evaluating their crypto primitives, or their nuclear power plant, or a zillion other things. But we can evaluate their source control!
- EdwardDiego 12y ago
  That bike shed would be way more robust if you used FP to paint it.
orblivion 12y ago
That's fine, but if (and I have no idea if this is the case here) their reason for not wanting to switch to a new source control system is mere stubbornness, they might find that switching to a more efficient source control system frees them up to write even more good code, fix more bugs, etc.
- stsp 12y ago
  It is not mere stubbornness. The main reason is that CVS works well enough for our purposes. Most of the diff sharing and discussion happens over email anyway. That's where all the action is. The main use case is that CVS distributes OK'd patches and allows us to revert them if they are later found to cause problems. Everyone works on the head branch so there are never any surprises caused by delayed integration. Instead of using branches, the workflow switches between development mode and release mode when the time is right. Release branches receive only a handful of patches (usually less than 10) for the most critical issues discovered during their 1 year maintenance period. Again, CVS is entirely adequate for that. It's not like there was no usage of git at all. Some devs actually use git in private and even mail git-generated diffs around. If those diffs fail to apply to the CVS tree the burden is on them to fix that. Since x.org runs git, all the X11 and other graphics code is ported to OpenBSD in git branches by our X maintainers and committed to the main CVS tree once it's ready to go live. This can be cumbersome but there's always a price to pay when integrating code from third parties that use different tooling.

deleted 12y ago

[deleted]

danielweber 12y ago

It's a perfect example of bike-shedding. Most readers have no way of evaluating their crypto primitives, or their nuclear power plant, or a zillion other things. But we can evaluate their source control!

EdwardDiego 12y ago
That bike shed would be way more robust if you used FP to paint it.

orblivion 12y ago

That's fine, but if (and I have no idea if this is the case here) their reason for not wanting to switch to a new source control system is mere stubbornness, they might find that switching to a more efficient source control system frees them up to write even more good code, fix more bugs, etc.

stsp 12y ago
It is not mere stubbornness. The main reason is that CVS works well enough for our purposes. Most of the diff sharing and discussion happens over email anyway. That's where all the action is. The main use case is that CVS distributes OK'd patches and allows us to revert them if they are later found to cause problems. Everyone works on the head branch so there are never any surprises caused by delayed integration. Instead of using branches, the workflow switches between development mode and release mode when the time is right. Release branches receive only a handful of patches (usually less than 10) for the most critical issues discovered during their 1 year maintenance period. Again, CVS is entirely adequate for that. It's not like there was no usage of git at all. Some devs actually use git in private and even mail git-generated diffs around. If those diffs fail to apply to the CVS tree the burden is on them to fix that. Since x.org runs git, all the X11 and other graphics code is ported to OpenBSD in git branches by our X maintainers and committed to the main CVS tree once it's ready to go live. This can be cumbersome but there's always a price to pay when integrating code from third parties that use different tooling.