X-Authentication-Warning: delorie.com: mail set sender to geda-user-bounces using -f X-Recipient: geda-user AT delorie DOT com Date: Wed, 29 Mar 2017 09:32:40 +0200 (CEST) X-X-Sender: igor2 AT igor2priv To: geda-user AT delorie DOT com X-Debug: to=geda-user AT delorie DOT com from="gedau AT igor2 DOT repo DOT hu" From: gedau AT igor2 DOT repo DOT hu Subject: Re: [geda-user] gedasymbols.org and EDAKrill - need your opinion In-Reply-To: Message-ID: References: User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Reply-To: geda-user AT delorie DOT com Errors-To: nobody AT delorie DOT com X-Mailing-List: geda-user AT delorie DOT com X-Unsubscribes-To: listserv AT delorie DOT com Precedence: bulk Hi gEDA users, gedasymbols.org has ~3k footprints and ~2.5k symbols. Progress on gedasymbols-to-edakrill import: 876 items (footprints and symbols) got imported; edakrill now has more than 1k items available. The bare minimal import process should be finished within a week or two. (Help wanted with the tagging.) Meanwhile, we have still only one vote on what should happen to gedasymbols after the import. It's probably worth voting now, before I finish the import: On Sat, 25 Mar 2017, gedau AT igor2 DOT repo DOT hu wrote: > Hi all, > > I plan to import the gedasymbols.org database to EDAkrill (please see my other > mail about what EDAkrill is). Any file with a distribution license permits > this is a potential subject. After the import, we'll have multiple choices > about how to run our services. > > After consulting DJ, the maintainer of gedasymbols, I see three possible ways > to proceed: > > 1. keep them separate services, EDAkrill imports data from gedasymbols.org > (and gedasymbols.org imports data from EDAkrill if someone programs it) > > 2. merge gedasymbols into EDAkrill, keep gedasymbols as is, but read-only > > 3. migrate gedasymbols to EDAkrill, shut down the CVS based service > > I think the community should decide: please vote for on of the above options, > especially if you are a contributor or user of gedasymbols.org. At the end I'd > like DJ to make the final word based on the community feedback/votes. > > For me any of these are fine. The import will happen in any case, > so if there's no decision we will probably end up with 1 implicitly. > > > Some technical details that may help the decision: > > - gedasymbols.org uses CVS; EDAkrill uses svn. If we go for 2. or 3., > CVS contributors will need to switch to svn or web uploads. Downloads with > svn should be similar to CVS, just slightly different command line > (and less commands) > > - please do NOT propose switching EDAkrill to git/hg/your-favorite-VCS. It > won't happen, and I won't enter flame wars about this; if svn is a blocker for > you, then don't use the service, vote accordingly, set up your own service > based on different tools, etc. > > - other than that I am open to any discussion and questions about EDAkrill or > its relation to gedasymbols > > - solution 1. is the least intrusive change, but it would be sort of > effort duplication (which is not necessarily bad) > > - in case of 2., we would keep gedasymbols.org for compatibility but we would > recommend using EDAkrill - there wouldn't be new uploads to gedasymbols.org, > but for example tools and users who got used to make a CVS checkout could go > on doing that (but they won't see the new files uploaded to EDAKrill) > > - in case of 3., we would probably redirect gedasymbols.org to EDAkrill, but > we wouldn't try to keep a compatible web page or CVS. > > - how integration is affected: as far as I know only pcb-rnd has gedasymbols > integration, and pcb-rnd will have EDAkrill integration too, so there won't be > a big change there. > > - stability of the service: repo.hu is hosted at a professional server hotel > in an air conditioned server room with redundant power (mains, UPS and AFAIK > even diesel). Network-wise it is very close to the Hungarian Internet > backbone. The international bandwidth is somewhat limited (for financial > reasons), but stability is excellent. > > > Regards, > > Igor2 >