On Sun, Nov 27, 2005 at 09:30:54PM -0500, Timothy Miller wrote:
> On 11/27/05, Jack Carroll <[EMAIL PROTECTED]> wrote:
>
> > OK, then. What I propose to do first is create a family definition
> > sheet for a family of generic 5% chip resistors. There are a lot of those
> > on the parts list, and hitting that family first will cover the most parts
> > for the least effort. I'll set up a stock number structure for them, and
> > show the relationship to the part number systems of the manufacturers Andy
> > selected, along with a reference to Digi-Key and Mouser. (I won't be able
> > to write an equivalence rule for the distributor numbers, since they don't
> > use rule-based numbering systems). Rather than trying to incorporate the
> > technical data sheets for the parts, I'll simply cite the URLs for the
> > manufacturers' PDFs.
> > It looks like OOo 2.0 is a good tool for creating this type of
> > document, but I'm not up to speed with it yet. So I'll do it with OOo in a
> > rough-and-ready way, and leave the formal title block layout for later.
> > Writing in OpenDoc format will protect the future maintainability of the
> > documents.
>
> Awesome. Thank you for doing this.
>
> > Will you do one thing to get this moving? Let me know where the
> > root number log is on line, or if it doesn't yet exist, set one up so that
> > we can all write in it (to assign new root numbers). It can be a Wiki or
> > whatever is easy to set up. I don't think we can wait for an elegant
> > solution before starting to assign numbers, but perhaps one of the other
> > project members with data base experience can develop something better, as
> > time permits. We've already discussed the requirements.
> >
> > The other thing I'll need is the location of the release archive,
> > where approved engineering documents go for distribution to project members
> > and vendors. Is that already set up? (For all practical purposes, a family
> > definition or a component data sheet is an engineering document with a
> > revision level, so it belongs where the design drawings are filed.)
>
> Ok, the three sites we have are gitk.com (where I have some FTP
> space), duskglow.com (where the wiki and list are), and suug.ch (where
> the SVN repository is stored).
>
> You could use the wiki, but if you want something different, we'll
> have to talk with one of the owners of one of those sites and see what
> they can help us with.
>
> How do you want to format the data online?
Well, you're the guy who will have to live with this thing, so I'd
say the final decision is yours. But here's how I see it.
The number log is a real simple text document. It could be either a
Wiki or a plain text file maintained in the SVN repository. We won't have
record locking, so anybody who takes a number should do it in a very short
session. Write one line in the Wiki file and close it again, so the the
entry shows up immediately. Or check out a copy of the number log, write an
entry in it, and immediately check it back in. That way we avoid duplicate
entries.
Formatting for the root number log...
Each entry has four tab-separated text fields: root number,
description, date, and designer's name. We might add other fields later,
but any number log has those four.
If we want a formatted listing, we'll import the raw file into an
application and print it out. But the log itself should be kept as plain
text, so that its format can't become obsolete.
For the actual documents, they'll be in their native formats,
whatever they happen to be. Plain text for source code, OOo for formatted
documents written in that format, PDF for most downloaded mfr data sheets,
DXF for mechanical drawings, and so on. We'll have to figure out a file
naming convention that relates to assigned document numbers. Now, where to
file the documents? I'd say, on the same server as the SVN data base. But
not in the SVN repository. I'd suggest 2 trees: "release" and "working".
Documents that are considered finished, and approved to make or procure
parts, go in the release tree. Work in progress that's meant to be visible
to people other than the author goes in the working tree. (Private copies
too immature to go in the working tree stay on the author's local drive.)
Possibly some documents that are fundamentally compatible with SVN,
such as plain text and maybe OOo (I'm not sure about the latter) might have
their working drafts in SVN. But their released versions should be in the
release tree. This makes it easier to identify which versions are released,
and protects the releases from modification. I don't have actual experience
with SVN, so you might have more to say on this.
I probably won't have time to get back to this for a week or so, but
I'll at least check my mail every couple of days.
Let's take it one step at a time. The first thing we need is the
number log.
_______________________________________________
Open-graphics mailing list
[email protected]
http://lists.duskglow.com/mailman/listinfo/open-graphics
List service provided by Duskglow Consulting, LLC (www.duskglow.com)
