Thanks for your comments Neil. In fact the code for the portal is, as I have clearly stated before on this list, open source, it is published under the permissive MIT license. I am more than happy to provide a copy to anyone that asks at no cost and they are free to do whatever they want with it. The fact that I choose to develop and maintain the production code on a password protected subversion server is, I believe, what annoys Bryan. I don't really understand his objections though as anyone that wishes to collaborate will be given credentials to the server, as several people already have. Just because software is open source does not automatically mean that it has to be downloadable on a public web server. Chris > On 16 Sep 2017, at 23:04, Neil Johnson <neil.johnson(a)erudicon.com> wrote: > > Bryan, > > Who is "we"? I for one appreciate all the work that Chris has put into > building and maintaining the portal. > > I don't know what Chris' circumstances are or what his reasons for not > being able or willing to open source the portal code are, but I'd rather > not have someone with your attitude run off one of the few active > contributors to AMPRNet! > > Just throwing the the portal source code out on Github is not going solve > anything. There still has to be a process in place for reviewing and > accepting changes, testing them, and deploying them. I don't believe that > Chris or Brian K have the time to take that on, and I definitely don't want > someone your attitude involved. > > I've worked with Chris and Brian K. a couple of times and found them both > easy to work with. > > Finally, this is after all just hobby! We all are volunteers and have > other commitments that take priority. Attacking active contributors is not > the way to keep them around or set an example that encourages others to > step up and help. > > -Neil > >> On Sat, Sep 16, 2017 at 3:55 PM, Bryan Fields <Bryan(a)bryanfields.net> wrote: >> >>> On 9/16/17 4:44 PM, Chris wrote: >>> Ah that old chestnut, it's a shame you choose to continue to be rude and >>> obnoxious even though you know nothing about me or my circumstances. You >>> know if I thought I could actually trust you to have a private >> conversation >>> instead of broadcasting my private emails to a mailing list I would be >>> happy to answer all your questions. >> >> I cannot have a private conversation as a means to stifle debate on a >> subject >> which affects all members of 44net. >> >> The only option we will consider is to release the source code. To do >> anything else when claiming to be for openness is hypocrisy. >> >> You dangle a sword over all users of 44net and think we should be grateful >> for >> not dropping it upon us. You recognize the difference between leading >> through >> coercion and leading with better ideas, no? >> >> -- >> Bryan Fields >> >> 727-409-1194 - Voice >> http://bryanfields.net >> _________________________________________ >> 44Net mailing list >> 44Net(a)hamradio.ucsd.edu >> http://hamradio.ucsd.edu/mailman/listinfo/44net >> > > > > -- > Neil Johnson >

On Sat, Sep 16, 2017 at 3:24 PM, Chris via 44Net <44net(a)hamradio.ucsd.edu> wrote: Please share it with me. I believe what annoys Bryan is that many offers to help via this list have been ignored, yet you continue to say you're happy to give anyone access. I'm looking forward to helping. Tom KD7LXL

On Sun, Sep 17, 2017 at 1:15 PM, Chris via 44Net <44net(a)hamradio.ucsd.edu> wrote: It's come to my attention that a number of people (including myself) were given incorrect URLs for the repo. Here's the correct URL: http://www.comgw.net/svn/AMPRNet/ Tom KD7LXL

If this was put on GitHub, then contributers could fork and send pull requests. On Sep 17, 2017 14:49, "Jay Nugent" <jjn(a)nuge.com> wrote:

We have both 'git' and 'subversion' repositories at work, and of the two, I find subversion to be the one that is simpler and easier to install, manage, and use. Both work well. Incoming students and faculty seem to prefer git, while the folks who have been with us for a while typically choose subversion. I guess it's a matter of which nail you hit depends on the kind of hammer you're used to. - Brian On Sun, Sep 17, 2017 at 07:29:28PM -0500, Neil Johnson wrote:

Without any doubt Git is the tool we use on *Ops (Dev*/Sys*/Sec*) as it easily creates a repo in any computer and can commit and push/pull on demand with just a couple of commands. But every decision comes with a trade-off: is much easier to mess (and solve) a branch of code (or the whole git tree) in Git than in SVN, but Git is the ruling application right now for VCS (Version Control System), specially when workers are remote. Performance, mechanisms anti-corruption and protocol availability (HTTP & SSH) are another three good reasons over SVN (and even over CVS) to choose Git. Finally, many hams have repos(itories) in Git format (GitHub, GitLab, BitBucket, Gogs, Gitea, Coding, GitBucket, Kallithea, Bonobo, CodePlane, RocketGit, GForge……more…) and is quite easy to interact with the code and the documentation that the project can generate, normally in the form of Markup language (*.md files) or Wiki pages. A personal example: https://github.com/ea1het/minimal-flask-websockets <https://github.com/ea1het/minimal-flask-websockets> That is a microservice written in Python using Flask microframework. The code is prepared to interact with databases despite it is not using any at the time for being this just a boilerplate code. This code is later on containerized with Docker technology (lxc type containers) and run on a Rancher Labs cluster executing Kubernetes orchestration. This microservice generates a minimal endpoint structure to run a websocket between a client (a web browser normally running JavaScript) and a server (the Docker container) for a DX Spot project I have within my club to run our own DX Cluster spider during contest. Git is awesome :) BR, -- Vy73 de EA1HET, Jonathan > El 18 sept 2017, a las 18:19, K7VE - John &lt;k7ve(a)k7ve.org&gt; escribió: > > The reason I suggest a public github project is that the tools are readily > available to manage individual developers making contributions. > > I run a development group and we used subversion, which is a fine product > for tightly integrated teams. However, git has certain advantages for > distributed development teams (we switched a few years back). Github goes > a bit further in supporting independent developers working on an open > source project. > > The workflow would work like this: > > There is a master repository controlled by the project leader(s). Only > assigned contributors can update that repository. However, an independent > developer can fork the project and implement functionality on their own > copy. If the functionality proves useful and is well tested, then through > github they can submit a 'pull request' which allows the project leader(s) > to review the changes and merge them into the main project. > > Here is a project's pull requests for an amateur radio project -- > https://github.com/LX3JL/xlxd/pulls as an example. > > > On Sun, Sep 17, 2017 at 6:49 PM, Brian Kantor &lt;Brian(a)ucsd.edu&gt; wrote: > >> We have both 'git' and 'subversion' repositories at work, and of the two, >> I find subversion to be the one that is simpler and easier to install, >> manage, and use. Both work well. >> >> Incoming students and faculty seem to prefer git, while the folks who >> have been with us for a while typically choose subversion. >> >> I guess it's a matter of which nail you hit depends on the kind of hammer >> you're used to. >> - Brian >> > -- > > ------------------------------ > John D. Hays > K7VE > <http://k7ve.org/blog> <http://twitter.com/#!/john_hays> > <http://www.facebook.com/john.d.hays> >