putting the component reference as an alias is a band-aid for sure. but since we don't have the proper connection through boom yet, i think it's a nice idea. only takes a moment to remove when the "real thing" is there.

it shouldn't interfere with the workflow either ... you'd look up the data sheet with dsv while reading the schematics. so you ought to know what part you need. the data sheet just explains how the part(s) work(s).

lekernel_: you can also consider the option of dual licensing up to the point where you're no longer the only copyright holder. depending on how you see the process go, this may or may not be feasible.

the whole idea of "developing into a distro" is bogus. you can do that maybe for one, but even there, you're probably not at the edge for long (that is, unless you're an active maintainer of several packages)

(developing into a distro) basically distro-centric development. instead of just maintaining a "standard" build environment and letting someone whose day to day business is putting things into the distro take care of the integration

(debian/fped) oh, that was nice and it definitely accelerated things (and probably made the integration cleaner). but in the long run, xiangfu will probably run out of time for maintaining that link, because debian is probably only a very peripheral interest for him. then the package will age and eventually break. then someone else who is closer to debian will pick it up.

oh dear :-) not sure. there are a lot of dependencies those revision control systems don't know about. not that there wouldn't also be other used for having them understand such things a little, but oh the complexity ...

(e.g. our schematics diffs would benefit from having proper inter-project dependencies. some day, it'll be necessary to add some hits to this system, so that it can at least loosely synchronize related projects.)

the missing bit is then simply to make sure any changes also get reviewed. since boom can change "spontaneously" (e.g., when prices or distributor stock change), we need some mechanism to record what has already been "seen".

adamwang: (boom) the hard part are the interruptions it causes. you want to add something "simple" and then you realize that you should really add the whole class of parts. now, will you do it properly or not ? :) so the more short-tempered developers will need some cleaning after

so the higher the process technology is, the more expensive failure gets, and in consequence (let's say for business that don't want to go bankrupt), the amount of time that goes into review, testing, preparing for testing, goes up exponentially as well

so I will be going after every smallest difference to m1, try to understand it, and if I have the feeling nobody will support the software for that difference, we either switch to using the same part as on m1, or I will not produce the board