<div dir="ltr"><div>Paul,</div><div><br></div><div>Honestly I personally wouldn't have separate repos for the outputs and source. I'd tend towards a single repo, with outputs being generated for each tagged release. I mentioned separate repos because many prefer to model hardware repos on software ones where build artifacts are pushed to a different channel. The complaint, as I understand it, is that at any point in development other than tagging a release, there is likely to be a mismatch between the source schematic document output documents. Seems to me the best way to resolve this is a well written readme; I think CI/CD is still a radical concept for board design, at least once you get away from multik$ tools which have scripting support for automated output generation.<br></div><div><br></div><div>One thing I'd change in the trans-ionospheric repo is the "outputs" directory. The gerbers, drc, BOM, etc are all there. Perhaps a directory structure for these would be in order, and one would be the pdf's of the source docs. Netlists would be a useful output.</div><div><br></div><div>John, <br></div><div><br></div><div>I completely agree with your comment about creating a project library. Some tools make that easy; the top tier Altium does, I don't know about the "Circuit Studio" I use or Kicad. While "source" a project library should be at a minimum updated with every tagged release. Other than the tool the project space should contain every source file someone would need to recreate and modify the gerbers, BOM, etc, with no surprise library dependencies. It also prevents issues with name collisions -- I've seen tools just default to using the first "SOT23" footprint it finds, and if there are different footprints that differ in pin ordering, bad things happen.<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Jul 28, 2020 at 9:36 AM Paul Williamson via Ground-Station <ground-station@lists.openresearch.institute> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="auto"><div dir="ltr"><blockquote type="cite">On Jul 28, 2020, at 7:53 AM, Keith Wheeler wrote:<br>This also opens the question of do we have a repo for source and another for tagged released outputs.</blockquote><br></div><div dir="ltr">I’m curious as to why it might be a good idea to have separate repos for work and outputs. At first glance it would seem to me that this is just asking for version skew confusion and extra work.</div><blockquote type="cite"><div dir="ltr"><div dir="ltr"><ol><li><p style="margin-bottom:0in;line-height:100%;background:transparent none repeat scroll 0% 0%">Not all parties interested in the schematic and
        layout source files will desire access to the tool. We should publish
        these in a more common format (pdf?), perhaps at every tagged release.</p></li></ol></div></div></blockquote>Yes, we absolutely should. Even people who do have access to the tools may find it quicker and easier to open a PDF for reference. The semantics of the special source file formats can have dependencies on library files that could become separated (or version skewed) from the design, or on features of specific tool versions. A stable, widely recognized, print-oriented format like PDF gives a valuable point of reference for what the thing is supposed to look like. Ancillary text-based outputs like netlists can also be helpful for people working with the hardware.<div><br></div><div>  -Paul KB5MU</div><div><br></div></div></blockquote></div>