On Wednesday 09 October 2013 16:42:53 Robert Ellenberg did opine:

> Hi Gene,
> 
> I'm just getting started with LinuxCNC development, but I've used Github
> for a long time for other projects. I wholeheartedly agree with your
> suggestion , and I would even suggest a more drastic step: make github
> host the "main" repository. A few reasons I like:
> 
>    - *Built-in wiki and issue tracking:* I'm not sure how big a change
> this is from the current setup at sourceforge, but I've found github
> issues very easy to work with. You can reference commits, include
> people, use markup for test, include images, and many other nice
> features. All this makes it easier to discuss and document.
>    - *Painless forking: *It's easy to make your own fork of an official
>    repo, and submit pull requests to the maintainers to merge in
> patches.  A pull request also has its own comment thread, so that any
> discussion surrounding a merge is both public and searchable.
>    - *Organizations:* The "linuxcnc" name is still available to become
> an organization. This let's the admins choose who has push access,
> assemble teams, and assign people to work on issues.
> 
> I know that a lot of folks are invested in the current setup, and there
> are good reasons not to fix what ain't broke. I just want to throw in
> my two cents in support of a great system.
> 
> Best,
> Rob

Remember always Rob, that (I think) I am the lists official old fart, now 
79 and as such I row this ship of state with a toothpick for an oar.  Kent 
Reed, I don't believe is a decade behind me.

But I think the current setup was used because it was what was available at 
the time.  Now most are used to it, and I can't fuss that a better way 
might be better when its learning curve starts from zero, just like the 
present system did way back when.  And I'm just like the next one, I don't 
want to fix what isn't broken even if we have had to get out a tube of 
super glue very occasionally.

Right now, with the turmoil in the kernel tree that requires our coders to 
start from scratch with the real time patches for every newer kernel they 
build, switching repository systems is the last thing those folks need.  
When things quiet down and 3.04 or so is out in the wild & stable, it may 
happen, not up to me, just saying..

But I'm not sharpening my prodding stick either.  These folks have walked 
on an awful lot of water in the last 4 years as it is, so my hat gets 
tipped in their direction daily.  And to whomever is footing the bandwidth 
bill for what we are using.  Sherline I believe hosts these lists.

> On Wed, Oct 9, 2013 at 2:40 PM, Kent Reed <[email protected]> 
wrote:
> > Gentle persons:
> > 
> > Gene Heskett asked earlier this month on emc-users if "the" server
> > (presumably he meant git.linuxnc.org since he mentioned an update)
> > were under attack because he was getting ca 20kb/s transfer speeds
> > instead of his usual ca 380kb/s.
> > 
> > I wasn't interested in the abnormality (speed seems more or less back
> > to normal) but in Gene's "usual" 380kb/s. As it happens, I'm seeing
> > roughly 30 percent lower transfer speed, but...
> > 
> > I have crudely benchmarked git.linuxcnc.org against github.com by
> > cloning the linuxcnc repo from each.
> > 
> > Results:
> > 
> > git clone git://git.linuxcnc.org/git/linuxcnc: elapsed real time:
> > 5m22s
> > 
> >                     67.31MB transferred, 260KiB/s transfer speed
> > 
> > git clone https:github.com/jepler/linuxcnc-mirror: elapsed real time:
> > 43.5s
> > 
> >                     72.76MB transferred, 2.7MiB/s transfer speed
> > 
> > Leaving aside why Jeff's repo contains an additional 5MB, this 10-to-1
> > difference in transfer is substantial. It is true as well for other
> > linuxcnc mirrors on github.com (try "linuxcnc" in the github
> > searchbox). I presume the difference is mostly due to faster Internet
> > "pipes" into the data warehouse(s) which host github and not due to
> > differences in the servers themselves. Perhaps the use of different
> > transfer protocols---git versus https---plays a minor role but I
> > would naively expect the git protocol to be faster.
> > 
> > Have we considered setting up an "official" repository to github.com
> > which mirrors git.linuxcnc.org? I suggest there should be such and
> > that it should
> > be contained in a LinuxCNC account. (So far, no one seems to have
> > registered that user/organization name but there is nothing to prevent
> > anyone from grabbing it.)
> > 
> > I like this idea for several reasons:
> > 
> > 1) redundancy (by design rather than by happenstance)
> > 2) faster throughput for many of us users
> > 3) as well, this could lower the burden on the git.linuxcnc.org host
> > and its ISP but perhaps this does not matter.
> > 
> > I assume that the sizes of the different repos already on github
> > differ only because the different github users have added their own
> > branches while major branches like master, ja3,
> > unified-build-candidate-3 remain identical, but you know what they
> > say about "assume". Besides, non-developers using a repo as a
> > read-only resource should not have to assume or to dig through the
> > commits and/or directory trees to find out even if they have the
> > know-how. Hence my suggestion.
> > 
> > 
> > Regards,
> > Kent
> > 
> > ----------------------------------------------------------------------
> > -------- October Webinars: Code for Performance
> > Free Intel webinars can help you accelerate application performance.
> > Explore tips for MPI, OpenMP, advanced profiling, and more. Get the
> > most from
> > the latest Intel processors and coprocessors. See abstracts and
> > register >
> > http://pubads.g.doubleclick.net/gampad/clk?id=60134071&iu=/4140/ostg.
> > clktrk _______________________________________________
> > Emc-developers mailing list
> > [email protected]
> > https://lists.sourceforge.net/lists/listinfo/emc-developers
> 
> ------------------------------------------------------------------------
> ------ October Webinars: Code for Performance
> Free Intel webinars can help you accelerate application performance.
> Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most
> from the latest Intel processors and coprocessors. See abstracts and
> register >
> http://pubads.g.doubleclick.net/gampad/clk?id=60134071&iu=/4140/ostg.cl
> ktrk _______________________________________________
> Emc-developers mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/emc-developers


Cheers, Gene
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)

If things don't improve soon, you'd better ask them to stop helping you.
A pen in the hand of this president is far more
dangerous than 200 million guns in the hands of
         law-abiding citizens.

------------------------------------------------------------------------------
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from 
the latest Intel processors and coprocessors. See abstracts and register >
http://pubads.g.doubleclick.net/gampad/clk?id=60134071&iu=/4140/ostg.clktrk
_______________________________________________
Emc-developers mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/emc-developers

Reply via email to