Re: [Discuss] Github/hardware (Was Re: discuss Digest, Vol 10, Issue 99)

[Bryan Bishop]

On Tue, Mar 26, 2013 at 5:46 PM, Donald Delmar Davis
<d...@suspectdevices.com> wrote:
> We use git for our hardware projects.
> While it might be nice to do visual diffs that is more a function of the cad program.

Actually, it is generating visual diffs is an easy task. I think it
would be neat to use iamwil's differ to just upload images to a
gh-pages branch, maybe throw on some javascript to view the different
revisions, and start from there.

Of course, something that natively supports visual diffs would be
better. Thingiverse had some potential here when it started out, but
they never bothered to do git integration (probably because of how
busy on other priorities they were).

But yeah, I often just throw everything into git anyway.

- Bryan
http://heybryan.org/
1 512 203 0507

[Bryan Bishop]

From: Windell H. Oskay <win...@oskay.net>
Date: Tue, Mar 26, 2013 at 5:42 PM
Subject: [Discuss] Github/hardware  (Was Re:  discuss Digest, Vol 10, Issue 99)
To: The Open Source Hardware Association Discussion List <dis...@lists.oshwa.org>

On Mar 26, 2013, at 3:17 PM, Matt Maier <blueb...@gmail.com> wrote:

> Git was created by software engineers, for software engineers. Github naturally grew out of that, but we are all aware of the fact that Github cannot handle the complexity of hardware projects.

I don't think that your generalization is quite valid; many of us on the mailing list are actually using Github for hardware projects.

Can you please explain, what it is exactly about the complexity of hardware projects that you think Github cannot handle?

-Windell


Windell H. Oskay, Ph.D.
Co-Founder and Chief Scientist
Evil Mad Scientist Laboratories
175 San Lazaro Ave, STE 150
Sunnyvale CA 94086
http://www.evilmadscientist.com/

_______________________________________________
discuss mailing list
dis...@lists.oshwa.org
http://lists.oshwa.org/listinfo/discuss


--

[Bryan Bishop]

On Tue, Mar 26, 2013 at 5:49 PM, Cameron Adamez
<cam...@suspectdevices.com> wrote:
> I've had issues pulling change requests for my projects. As there's no way for me to cherry-pick
> changes and since I haven't started writing a diff program for Eagle files, I've had my board
> accidentally clobbered or mangled via pull requests. I found the correct settings for
> binary files for Eagle 5, but pull requests were still arduous after that.

Have you considered not using a binary file format? What about
something that is composed from multiple files that get combined? For
instance, I think even simple netlists could handle that. Another
thought that comes to mind is that automated testing could help your
contributors not commit terrible things that break everything.

[Bryan Bishop]

From: Matt Maier <blueb...@gmail.com>
Date: Tue, Mar 26, 2013 at 5:17 PM
Subject: Re: [Discuss] discuss Digest, Vol 10, Issue 99
To: dis...@lists.oshwa.org


First I'd like to clarify that I support the "bazaar" style of open source development. Anyone should be able to do anything, anytime (with a few obvious caveats).

If someone thinks they understand a problem, and that the right way to address it is to use their own personal expertise, then they should do so. Unless their approach is somehow actively harmful the worst treatment it should get from the community is indifference.

A software developer can address a problem by writing a piece of software.

Not everyone is a software developer, and the people in open hardware are less likely to have software expertise. Open source software was able to grow its own tools because the people who wanted to use the software also knew how to write software.

Git was created by software engineers, for software engineers. Github naturally grew out of that, but we are all aware of the fact that Github cannot handle the complexity of hardware projects. There are software tools that are great for hardware projects, but they are proprietary secrets that demand a great deal of time and money.

The problem, then, is that open hardware needs software tools but the people capturing the benefits are not software engineers. The open hardware community has to approach software problems as customers.

Since we're customers, it makes perfect sense to clarify our priorities, build a requirements document, and then establish a basic relationship between the work required and the number of people who will benefit.

I can't build software, but my personal expertise does cover things like building consensus around technical subjects. So that's what I'll try to do. That requires collaborating with people other than myself; preferably as many stakeholders as possible. Thus, a committee with outreach access to as much of the relevant community as possible.

No one will stand in the way of small, individually-produced patches, but personally I'm going to agitate for a more comprehensive solution.


>
> I think in some cases [individuals solving small problems] has been successful, like
> thingdoc, which successfully solves a small piece of the puzzle, but
> needs all the other tools everyone keeps talking about.
>
> [...]
>
> > At any rate, the discussion has to happen before any implementation makes
> > sense.
>
> How do you explain- for example- thingdoc, then? There was very little
> (or no) discussion, and yet it makes a lot of sense and works pretty
> well for its intended purpose, and is a positive contribution to
> packaging within that area of the open source hardware community..

>
> - Bryan
> http://heybryan.org/
> 1 512 203 0507

_______________________________________________
discuss mailing list
dis...@lists.oshwa.org
http://lists.oshwa.org/listinfo/discuss



--

[John Griessen]

On 03/26/2013 05:50 PM, Bryan Bishop wrote:
something that natively supports visual diffs would be
> better. Thingiverse had some potential here when it started out, but
> they never bothered to do git integration (probably because of how
> busy on other priorities they were).
>
> But yeah, I often just throw everything into git anyway.

Fossil is another version control software to consider. It has less features
than git, but is easier to use for me, and has the concept of keeping all
history in each repository, no rebase, each time you do a merge, sender and receiver get
updated. It has a nice visual timeline and web interface and diff can be an external tool,
so visual diffs would be easy, maybe even run 2D viewers to do an XOR diff on image and vector drawing files...

Keeping all and never rewriting history with rebase could let mistakes bloat the size of the repository...
but I believe you can rewind and replay history to create new repositories if you had to get rid of some
accident that burned 1/2 a GB.