github

[glinty]

Has any thought been given to placing lich and associated ruby scripts into github?
I've been managing most of my scripts in my own local git repo, with symlinks from lich/scripts. This works but does have a few drawbacks, namely


I don't know of a way to check when lich scripts are updated, thus requiring periodic ;repo downloads just to make sure that I have the latest version.
Perhaps the latest fix changed functionality, and I would like that functionality back. In the current setup (to my knowledge) there is no way to see the prior version of a given scrip (unless I've already got it committed in my local git repo).


Which is why I suggest using some public git repo host like github in order to manage this stuff.
Advantages include..


Easy to contribute to existing code
Clarity about who wrote what, and when
No more wondering if script X is out of date
Better overview of existing scripts
Fork and self maintenance if desired, pulling in fixes as they are created
FREE


If it hasn't been done due to a lack of knowledge or time, I would be happy to help out with this. If there is another reason why this hasn't been done, I'd like to hear why.

Cheers,
Glinty

[masterdtwin]

I support this about 95%

The remaining 5% is only due to a lack of knowledge about capabilities. For example... If a script has not been updated in say 6 months, can we remove it from the list so people don't download inferior scripts. An alternative option would be to flag it as inactive and simply have a separate repository for scripts not actively being monitored.

I know I certainly support this - I have made several corrections to scripts that I use (sloot4 comes to mind as one I've made quite a few changes to), and would love to be able to submit them for revision updates.

On a side-note, if anyone would like some assistance with scripts (most specifically debugging) I'd be happy to assist. Creating scripts from scratch is not my thing, but I am an excellent debugger.

[Whirlin]

My knowledge of GitHub is limited to the times I came across it while auditing.

While GitHub is an open source source code management console, and it's free to obtain an instance of it, I thought that was limited to the deployment of GitHub on your own infrastructure, and that cloud based GitHub hostings would involve some sort of amazon-esque hosting fee.

The problem with having an open hosting of GitHub is security-side, and interfacing it with the lnet repo.

Someone would need to function as the user administrator of GitHub to ensure that it's not just open to the world... otherwise, it'd be an easy target to get wiped out.

Additionally, I'm not sure how it would interface, or if it could interface with the lnet repo. It would require Tilman's buy-in to keep one system of record for all active scripts. If users can still submit scripts directly to the lnet repo, the GitHub code could easily become outdated, or need to be constantly reconciled before working on anything... and if that's the point, there's not substantial gains to support it...

I haven't had my coffee yet, but does that make sense?

[masterdtwin]

Yes, that does make sense.

Security - Github Security Information (https://help.github.com/articles/github-security) - This is pretty standard and does not pose any exceptional security risks. Additionally, because of the way lich is coded the risk associated to your Play.net account is almost negligable because the two accounts are separate and distinct. Honestly I would say the only real issue would be adding a verification that any saved account information is compared between your play.net and github account to ensure they are in fact different (at least ensuring the passwords are different).

Interfacing with lnet repo - Github allows access to the code repository through smart https, SSH, and Git Protocol. Yes, it would require a re-write of the lnet code, but it would not in fact cause

Administration - This is probably the real big issue more than anything else. Someone would have to be an active administrator for it, ensuring only certain people have access to varying levels of code modification. It would however allow code managers to allow other users to view and modify their code with permission. Yes, Lnet does this currently (of sorts) - but you would need someone dedicated to ensuring this is monitored.

Cost - I don't know how much people donate to lichnet, but I would be willing to bet the cost of using a managed server to host lnet is more expensive than the monthly cost of a github repository. That being said, Tillmen may very well use his server for several other things and not just lich.

Users - This is where the real problem would occur. Currently you don't have to do anything at all to create, update, download, scripts onto the lnet repository. With the administration involved, everyone who wanted to work on scripts would require an account. Downloading of the scripts could certainly be set as available to everyone, so only those who want to be involved in scripting itself would require accounts.

Just my 2 cents.

[glinty]

Whirlin, to clear up some confusion about what github could provide

A free account would allow the code owner (tillmen) to have a repo hosted for free (as long as it's public). The repo owner can give collaborator's rights to as few or as many people as he wishes. Collaborator's have read/write access to all code in the repo. The public at large has only read access, though github has a great facility that allows the public to fork (copy) a repo, make changes to it in their own repo, then send a request back to the code owner/collaborator's to integrate the change.

[glinty]

masterdtwin,

Regarding your security fears, I don't really follow your line of thought, it seems as though you think that the code will run on github? A repo is merely a place to store the code. If you want to download the latest lich.rb file, just clone it and run it locally as it always has been done.

The solutions I suggest require hardly any changes to the lich.rb script and 0 changes to any other script
In fact it could make the lich.rb script even simpler. There would no longer be any need for the ;repo download ;repo list commands if everyone stuck their own lich scripts in their own repo. Want the latest Tgo01 lockpicking script? Just git clone it, or pull it if already checked out (assuming Tgo01 puts it into a public repo!)

As I see it, it would be as simple as the following

Solution #1
0 collaborators
Dump lich.rb, go2.lic, useherb.lic, xml files (i.e. the existing base scripts along with whatever is already in lich's repo) into a github repo.
Let people who want to make a bugfix/change simply fork the repo, make their changes, and send a pull request back to tillmen.
Advantages: Simple, 0 risk to code integrity as only the code owner (tillmen) has write access to the repo
Disadvantages: Depending on the amount of pull requests generated, could be some work for tillmen integrating code. I suspect that this won't be much, though perhaps tillmen could comment on how frequently he receives a patch from someone for a given script?

Solution #2
A few collaborators
Dump lich.rb, go2.lic, useherb.lic, xml files (i.e. the existing base scripts along with whatever is already in lich's repo) into a github repo.
Let people who want to make a bugfix/change simply fork the repo, make their changes, and send a pull request back to code owner & collaborators.
Advantages : Less work for tillmen as code merging could be shared across collaborators.
Disadvantages : Need to be able to trust collaborators, so that they don't do something malicious with the code.

[glinty]

Yes, that does make sense.

Security - Github Security Information (https://help.github.com/articles/github-security) - This is pretty standard and does not pose any exceptional security risks. Additionally, because of the way lich is coded the risk associated to your Play.net account is almost negligable because the two accounts are separate and distinct. Honestly I would say the only real issue would be adding a verification that any saved account information is compared between your play.net and github account to ensure they are in fact different (at least ensuring the passwords are different).

See my above post, either I misunderstand you or you think that the code will be run on github's servers. This is not the case, the code will still be run on your local machine. I don't see any security implications.



Interfacing with lnet repo - Github allows access to the code repository through smart https, SSH, and Git Protocol. Yes, it would require a re-write of the lnet code, but it would not in fact cause


The solutions I suggest above require no changes to the lnet code (well maybe a tiny tiny one about directory structure in order to support cloning of repos into the scripts directory to support 3rd party scripts).



Administration - This is probably the real big issue more than anything else. Someone would have to be an active administrator for it, ensuring only certain people have access to varying levels of code modification. It would however allow code managers to allow other users to view and modify their code with permission. Yes, Lnet does this currently (of sorts) - but you would need someone dedicated to ensuring this is monitored.


As stated above, by default everyone has only read access to the repo. Code owner can add "collaborators" if he wishes. Collaborators would have write access. Code owner has write access. Yes the trade off would be more or less work for tillmen depending on how frequently people make bug fixes/code changes to scripts in the "base scripts" collection (lich/go2/useherbs etc.). My prediction is that not too many people will be doing this but it's only a guess.



Cost - I don't know how much people donate to lichnet, but I would be willing to bet the cost of using a managed server to host lnet is more expensive than the monthly cost of a github repository. That being said, Tillmen may very well use his server for several other things and not just lich.

Cost is free.



Users - This is where the real problem would occur. Currently you don't have to do anything at all to create, update, download, scripts onto the lnet repository. With the administration involved, everyone who wanted to work on scripts would require an account. Downloading of the scripts could certainly be set as available to everyone, so only those who want to be involved in scripting itself would require accounts.


No problem here. If a regular user (not a collaborator or owner) wants to make a change, he just forks the existing repo. Makes his change, and sends a pull request when he's done. Owner and collaborators will get a notice that someone wants merge in some code. Owner and collabs can discuss it, and decide if and what parts of a pull request will get merged into the trunk.

[Whirlin]

So basically... a lot more administrative time that Tilman or a Tilman delegate (have you met Rozy? Do you REALLY want another Rozy?) needs to spend to maintain a separate repository, because you don't know which scripts to use?

I don't think there's adequate return, given the amounts of additional oversight and workload required to administer from a user provisioning standpoint, as well as from an individual script standpoint.

What you failed to take into account is turnover and colloquial playstyle of some of the userbase. People don't always pay attention to all venues of communication. Hell, to make it personal, you've had your players corner forum profile since February of this year, and posted about once every other month til June, where you spiked and had 6 entries, and then silence for four weeks, and now new spikes.

This is a typical activity level for an average player. What if this player was the owner of a script? What mechanism would there be for automatic approval after X days? Would you want automatic approval? Is Tilman supposed to step in, and verify the script before pushing it out to the repo? Why would I want to bother spend my time posting my script changes to GitHub if it won't be actually pushed out for potentially months?

There's a lot of additional work associated with it, but the big benefit that I see is not needing to ask a simple question or two over Lnet, or reading about the scripts that people most commonly use in the "What scripts do you regularly use" thread.

[masterdtwin]

I'm honestly with Whirlin.

There are far too many issues to jump over in order to gain the benefits of the collaborative effort. IF Gemstone had a larger player base, it would certainly be possible. Currently you have on average 20-30 people actually working on scripts. That's probably a bit of an over-estimate all things considered.

In order to effectively transition to use the collaborative benefits of github, you would simply need more people to support it. But as it stands you would still run into the same exact issue that you have now. If someone takes a 2-3 month vacation, nothing is going to get changed unless you have an admin release ownership of a script.

Don't want to wait for someone else to release it to be modified? on github you're forking it over to somewhere else - but that's not actually going into the repository, and you'd have to wait for an admin to approve it. On Lnet currently, you can at least just fix it, name it something else, and then upload it as soon as you're done. It's actually EASIER now than it would be on github.

The only real issues that I have with the current set-up could very easily be fixed with some changes to the repository script. If I get really bored I might take a look at what can be done about it. Then again, I've also seen a few issues with ;go2 that I'd like fixed (which I already told tillmen about).

[glinty]

So basically... a lot more administrative time that Tilman or a Tilman delegate (have you met Rozy? Do you REALLY want another Rozy?) needs to spend to maintain a separate repository, because you don't know which scripts to use?

No. Wrong. The idea is that it's the only repository. There is no other repository to maintain. The only extra maintenance work for tillmen would be merging in submitted changes from other users, which is absolutely no different from the current model (except that in the current model the merging process is invisible, and no history (at least not publicly) is kept).
My feeling about the current model is not that "I don't know what script to use". My gripe is that there are better methods available for maintaining a public code base that encourage people to contribute/fix existing code.



I don't think there's adequate return, given the amounts of additional oversight and workload required to administer from a user provisioning standpoint, as well as from an individual script standpoint.


Considering you don't know what it would cost to implement this change, it surprises me that you think you know what the return should be in order to offset it. Granted, there would be some work to do. I'm curious to know what tillmen thinks.



What you failed to take into account is turnover and colloquial playstyle of some of the userbase. People don't always pay attention to all venues of communication. Hell, to make it personal, you've had your players corner forum profile since February of this year, and posted about once every other month til June, where you spiked and had 6 entries, and then silence for four weeks, and now new spikes.

This is a typical activity level for an average player. What if this player was the owner of a script? What mechanism would there be for automatic approval after X days? Would you want automatic approval? Is Tilman supposed to step in, and verify the script before pushing it out to the repo? Why would I want to bother spend my time posting my script changes to GitHub if it won't be actually pushed out for potentially months?


Some good concerns in this paragraph. I don't know how it's currently handled in lich. Does tillmen have to approve every script uploaded via ;repo upload? Is there an automatic approval after x days mechanism? These are some questions I hope to learn the answer to in the course of this discussion. I was under the impression that the person that uploads a script via ;repo upload is the only one who can edit that script. If indeed that is the case, your concern about the code owner disappearing and not updating his code anymore is just as valid with the current system. I thought that's why we have nonsense like ;sloot, ;sloot2 ;sloot3 ;sloot53243

Anyhow, one idea for the 'big bang' of this transition would be to snapshot all the 3rd party scripts as they stand now. Uploaders would be given the chance to become the code owner of their script. If they didn't want it it would default to tillmen, and he could simply not accept any merges on it for the rest of time.



There's a lot of additional work associated with it, but the big benefit that I see is not needing to ask a simple question or two over Lnet, or reading about the scripts that people most commonly use in the "What scripts do you regularly use" thread.

Agree there would be some work to do, yet I disagree with your benefit. The key benefits are to allow interested parties to see the history over time of scripts, and easier submission of code updates/bug fixes.

[glinty]

I'm honestly with Whirlin.

There are far too many issues to jump over in order to gain the benefits of the collaborative effort. IF Gemstone had a larger player base, it would certainly be possible. Currently you have on average 20-30 people actually working on scripts. That's probably a bit of an over-estimate all things considered.


Regarding the number of issues to jump over, I'd prefer to have tillmen's opinion on this instead of all of us speculating.



In order to effectively transition to use the collaborative benefits of github, you would simply need more people to support it. But as it stands you would still run into the same exact issue that you have now. If someone takes a 2-3 month vacation, nothing is going to get changed unless you have an admin release ownership of a script.


As you say, the same issue that we have now. Moving lich into a git repo doesn't have to address this (though I agree it should be addressed in some form or another). The benefits of a transition are transparency, code overview, easier patch submission.


I
Don't want to wait for someone else to release it to be modified? on github you're forking it over to somewhere else - but that's not actually going into the repository, and you'd have to wait for an admin to approve it. On Lnet currently, you can at least just fix it, name it something else, and then upload it as soon as you're done. It's actually EASIER now than it would be on github.


I disagree about the "easier" bit. Fixing it and starting a new a repo for said script is also trivial.


I
The only real issues that I have with the current set-up could very easily be fixed with some changes to the repository script. If I get really bored I might take a look at what can be done about it. Then again, I've also seen a few issues with ;go2 that I'd like fixed (which I already told tillmen about).
What are your issues with the current repo system? Have you tried to fix go2 and submitted a patch to whoever is the owner of go2 (I guess tillmen)?

[masterdtwin]

Regarding the number of issues to jump over, I'd prefer to have tillmen's opinion on this instead of all of us speculating.

You missed my point on this. It was not about the issues to jump over, it was about the community support. In order to perform this transition you will have to have more community support, in the form of someone (or multiple people) having access to collaboration administration. This would essentially add a larger tasking on Tillmen, OR it would force him into finding someone else to manage the administration.

Not to mention, suppose you suddenly have 5 people who are wannabe coders submitting change requests. Now, even though they are potentially written - Tillmen would have to go through each and every single one of them in order to determine if he wants to make those changes. Someone may very well have a great idea, but could be a terrible coder, thus causing Tillmen to take more time sifting through crap compared to something he could have simply modified himself just as easily. And note - this applies to anyone who is the owner of a script, Tillmen is just the defacto example.


As you say, the same issue that we have now. Moving lich into a git repo doesn't have to address this (though I agree it should be addressed in some form or another). The benefits of a transition are transparency, code overview, easier patch submission.

Okay, first things first... Transparency? I mean, what are you gaining here. Currently, you download the script, and you can see the entire code. I'm honestly not sure what kind of transparency you are gaining here. Code Overview - Everyone who downloads the script can look at it and modify it as they choose. You are still not gaining anything here. Easier patch submission - Yes, this is absolutely true. However if you read my previous comment you'll see that I'm not entirely certain that's actually a good thing.


I disagree about the "easier" bit. Fixing it and starting a new a repo for said script is also trivial.

My view of easier was overall work involved. For the person submitting a change, it is pretty much the same amount of work. In a collaborative effort however, someone has to review every submission and decide if they want to merge the code or not. That back-end effort is saved by simply posting a new version via ;repo. On the side of repo - The community of users can actually decide whether new code is worth using or not, as you essentially have free beta testers - all in all less work on the primary owner.


What are your issues with the current repo system? Have you tried to fix go2 and submitted a patch to whoever is the owner of go2 (I guess tillmen)?

Repo - I don't like the fact that there are scripts listed that have not been updated in 3 years or more. Now, making them available for archival purposes - that is a phenomenal idea. What I would much rather like to see is, all scripts updated within the past 6 months are essentially your primary scripts. If you want to view all available scripts, then you can select a different option to view archived scripts (or anything past 6 months). This change itself would require only a few new lines of code since all of backend requirements are already met.

The other change on repo I would like to see is some form of tracker on the server to determine how many people download a particular script. The entire purpose of this would be to add another option onto the repo list, allowing you to pick say the top 20 favorites or most downloaded as it were. This would require a bit more effort than the latter change.

Go2 issues - I actually came across this sometime last week. Go2 has targets set up so you can just type ';go2 bank' and arrive at the nearest bank. Additionally, you can create aliases for your own personal targets to make it easier. The problem occurs when you create an alias with the same name as a target. Whatever alias you created has a higher priority than the target you listed.

Why does this cause a conflict? Many scripts do not use specific room calls, but instead use targets to perform town related actions. So, let's say you created an alias called bank and its target was the landing bank. You run over to Ta'Illistim, and use a script that uses the target 'bank' as part of its ;go2 call. Suddenly and inexplicably you find yourself climbing over mountains trying to travel all the way to the landing. Sure, you can just tell people - Hey idiot, don't make an alias called bank. But the reality is, you could also create a simple check in the creation of aliases that prevents using words designated for targets. I have already sent an explanation of that to Tillmen, but I honestly haven't a clue as to whether it will come to fruition.

Why haven't I looked at and submitted these changes for review? I started playing again about 3 weeks ago, after being on hiatus for 2 years. I fully plan on looking into it, but I have other more important things to take care of first.

[glinty]

You missed my point on this. It was not about the issues to jump over, it was about the community support. In order to perform this transition you will have to have more community support, in the form of someone (or multiple people) having access to collaboration administration. This would essentially add a larger tasking on Tillmen, OR it would force him into finding someone else to manage the administration.


Ah, thanks for clarifying. If the '0 collaborator' approach was pursued, then the situation you describe would not exist. The maintenance workload for tillmen would be exactly as it is now.



Not to mention, suppose you suddenly have 5 people who are wannabe coders submitting change requests. Now, even though they are potentially written - Tillmen would have to go through each and every single one of them in order to determine if he wants to make those changes. Someone may very well have a great idea, but could be a terrible coder, thus causing Tillmen to take more time sifting through crap compared to something he could have simply modified himself just as easily. And note - this applies to anyone who is the owner of a script, Tillmen is just the defacto example.


Yes, beware the dreaded wannabe coders. :)
What you write is exactly correct, however it is also exactly the case now, so I don't see this as a reason on why a transition shouldn't be made.



Okay, first things first... Transparency? I mean, what are you gaining here. Currently, you download the script, and you can see the entire code. I'm honestly not sure what kind of transparency you are gaining here.


Transparency is seeing why a given change was made, who made it, and when. This benefit is inherent to modern versioning systems (svn, git, mercurial?)


Code Overview - Everyone who downloads the script can look at it and modify it as they choose. You are still not gaining anything here.


The gain here is that you get to see the entire history of the script if you wish, compared with the current system which only lets you see the current version.



Easier patch submission - Yes, this is absolutely true. However if you read my previous comment you'll see that I'm not entirely certain that's actually a good thing.


I don't really see this as having a downside. If you don't want to accept patches from other developers then don't accept patches from other developers. Couldn't be simpler.



My view of easier was overall work involved. For the person submitting a change, it is pretty much the same amount of work. In a collaborative effort however, someone has to review every submission and decide if they want to merge the code or not. That back-end effort is saved by simply posting a new version via ;repo. On the side of repo - The community of users can actually decide whether new code is worth using or not, as you essentially have free beta testers - all in all less work on the primary owner.

Ah, I see your point. Let me paint a picture here and see if I'm describing your scenario.

Current system
I ;repo download masterdtwinloot (some loot script)
I notice a bug.
I make a patch for the bug, send it to masterdtwinloot.
Alas he is no longer playing the game and has no interest in updating his script.
I copy masterdtwinloot.lic to glintyloot.lic
Apply my patch
;repo upload glintyloot.lic
Voila, problem solved?


github based system
git clone http://blah/masterdtwinloot.lic
I notice a bug.
I fork masterdtwinloot.lic
fix bug
send pull request
Alas he is no longer playing the game and has no interest in updating his script.
However the forked repo already has the fix in it, anyone that wants it can just clone my forked repo
Voila, problem solved?

I don't follow your bit about the free beta testers, that holds with the github based approach. Both scenarios have the same disadvantages, namely the slootX syndrome

[Whirlin]

Agree there would be some work to do, yet I disagree with your benefit. The key benefits are to allow interested parties to see the history over time of scripts, and easier submission of code updates/bug fixes.
I think this target demographic of interested people is much smaller than you think. We're talking about maybe 10-20 serious lich coders, of which, all are fine with the way things are currently working, which is why the community hasn't sought a more rigorous structure.

In your final example in the potentially right above post... Who makes the new 'forked' version the release version available in the in game repo? If administrative, again, that requires time and management. If automated, can I just upload a 'butts' comment between every line of a script and add it as a new fork? Who is on the other end of the pull request, if it's automated, you just got 1000 butts in your new alchemy script! Incredibly efficient!




Is your main problem the sloot scripts? It's coming across like you're having a few, minor problems with particular scripts, and by trying to move to the root cause of the issue rather than dealing with the specific conditions, the result is trying to do surgery with a shotgun rather than scalpel.

[Tillmen]

I don't know of a way to check when lich scripts are updated, thus requiring periodic ;repo downloads just to make sure that I have the latest version.
You can use the updater script to download any script on the repository when there's an update.
;updater add <scriptname>


Does tillmen have to approve every script uploaded via ;repo upload?
No.


I was under the impression that the person that uploads a script via ;repo upload is the only one who can edit that script.
That's right.

[masterdtwin]

github based system
git clone http://blah/masterdtwinloot.lic
I notice a bug.
I fork masterdtwinloot.lic
fix bug
send pull request
Alas he is no longer playing the game and has no interest in updating his script.
However the forked repo already has the fix in it, anyone that wants it can just clone my forked repo
Voila, problem solved?

no, that is not how it would work. You are failing to see how the repo system works currently. It connects to one location that lists all of the hosted files (in your example github). This is how it would really work:

github based system
git clone http://blah/masterdtwinloot.lic
I notice a bug.
I fork masterdtwinloot.lic
fix bug
send pull request
Alas he is no longer playing the game and has no interest in updating his script.
However the forked repo already has the fix in it.
I submit a request to the administrator to update and ask it to be merged or overwrite the original script.
Anyone that wants it either has to wait for the controlled collaboration group to be updated by the administrator, or search it out and manually download the script
Administrator doesn't like you or is lazy and a month goes by before he decides to let you update it.
Reality sets in and it pisses you off, so you decide it's just not worth updating scripts for other people.

Once you fork a script it is going to be separate from the primary repository, thus not able to be downloaded through the repo command. Until the files are merged, someone would have to manually locate the new script.

Current:

Repo
|
+ Sloot -> sloot2 -> sloot3 -> sloot4

All of them are visible...

Github:

Repo
|
+ Sloot {wait a month} <-- Sloot2 joins {wait a month} <-- Sloot3 joins
|
+
Sloot Fork:
|
+ sloot -> sloot2

Sloot2 Fork:
|
+ sloot2 -> sloot3

etc...

[masterdtwin]

You can use the updater script to download any script on the repository when there's an update.
;updater add <scriptname>

No.

That's right.

Efficient! I approve!

[Tillmen]

So.. um.. I guess there's a few ways to do this...

1. All scripts go into github and the repo script is changed to download scripts from github instead of the lich server.

I think this is no good, because a person is either able to edit no scripts, or is able to edit all scripts, or there's a fork/pull request and I suddenly have to maintain 200 scripts which means... screw you guys, you don't need scripts anymore.



2. Each script owner has his own github repository that contains all their scripts, and the repo script keeps a list of all the github repositories and can download from them.

Each script owner can allow whoever they want to edit their scripts. The repo script will be slowed down some.

A possible problem with both of these methods is that the latest code available for a script may be a work in progress and not function. This may not be an issue, because I remember seeing something about making release versions and whatnot in github, but I don't really know much about git.



3. Each script owner has his own github repository that contains all their scripts, the repo script remains unchanged, and the script owner puts a link to their github repository in their script comments.

This method allows the computer illiterate users to continue to upload and download scripts like they're used to (change is scary), with the option to easily find a github repository when available and contribute. There's also added benefit that I don't have to do anything... except for the core scripts.

This method gives the extra step of uploading to the repo after changes are made in github, and I think that's probably a good thing. Collaboration is great, but I don't want anyone downloading code with my name on it unless I've checked it to make sure it's not malicious. Trust is a weird thing. If someone trusts me to give them non-malicious code, and I trust someone to edit my code, and perhaps that person trusts someone else, the first person has unwittingly trusted someone he's never heard of. That's generally when bad things happen. If someone trusts me, I don't think it's right to cause them to trust someone else through the commutative property of trust, even if I truly trust that person.

The security concerns I've read in this thread are confusing. So here's what you should be concerned about: any Lich script is capable of getting your character banned or rerolling him. A trusted Lich script is (probably) capable of stealing all information on your hard drive, downloading and installing trojans and viruses, and destroying everything on your hard drive. I've given up on trying to convince people that the vast majority of scripts run fine untrusted, and that trusting and running every script they can find without reading it is a bad thing. If you trust a script, that means you trust it. That's good enough, right?

There's a number of things I'd like to do to the repo script: download count, rating, categories, perhaps drop the key system for uploads and use a password protected lnet login for the script owner, and a decent GUI for it all. I wouldn't hold my breath though, since I started a complete rewrite of lich.rb and then my computer broke.

Also, here's the github for Lich and ProfanityFE:
github.com/matt-lowe/Lich
github.com/matt-lowe/ProfanityFE

[SpiffyJr]

Go with #2. You can just have your repo script pull from a branch that everyone decides on (master is generally for stable code, develop for development). ANything in master is assumed stable and latest. Also, GitHub has web hooks available that could push to your server and tell you when to update each script.

*EDIT* As far as security. Fuck em. Ignorant people are generally too lazy to remove that ignorance. If they don't understand the consequences of using ;trust after it's been told to them time and time again it's their own fault.

[Buckwheet]

What broke on your computer?

[m444w]

#3

You may maintain a github repo for dev, for a gem, but you still have to push it to rubygems when it works

You may maintain a github repo for an NPM package but you still have to publish it to npmjs.org when it's ready.

Some Lich scripts are becoming very complicated/large and it might be more useful to look into enabling a project structure for them.

For small scripts they could still be:

small_script.lic

But a larger project might decide to use:

warmode/
-warmode.spec
-lib/
-lib/warmode.lic
-lib/casting_logic.lic
-lib/melee.lic
-lib/archery.lic

I hope that isn't formatted in a terrible manner, I'm on my phone.

I would love a password protected upload function, because I have a couple of scripts I uploaded from a computer that I don't have access to anymore and I haven't figured out a good way around that.

[Tillmen]

What broke on your computer?

Cat hair.

[glinty]

Ah tillmen, thanks for your response.

Great to know that lich is already in github. By the way I have to say I'm very pleased with profanity, been using it as my client for a few weeks now without major issues.

What I had in mind is your second solution. It would require some work in the repo script as you said to interface with external git repos, but in the end I think it's the most elegant solution.

Regarding your doubt about broken code being the latest commit in a repo, it is true, it might be broken, however is this any worse than the current system? Do you run some unit tests on ;repo uploaded scripts before accepting them? As spiffyjr said, it's common practice for the master branch to always be in a stable state, and as long as this is adhered to well, problems can be mitigated. Another solution would instead be to have the repo script look at tags instead of branches, as tags were designed for this very purpose (to snapshot a known working version for reference/release). It could be that tagging might be a bit too formal for what these scripts are needed for though.

If you are interested in pursuing this idea, as I said I'm happy to contribute.
I'm curious about the changes you have planned for lich.rb. Could you explain a bit?

[glinty]

#3

You may maintain a github repo for dev, for a gem, but you still have to push it to rubygems when it works

You may maintain a github repo for an NPM package but you still have to publish it to npmjs.org when it's ready.


Doesn't have to be that way, many people use github as a direct release platform.

Agreed regarding 'projects'. Perhaps a better name is module?

[Tillmen]

I'm curious about the changes you have planned for lich.rb. Could you explain a bit?

I'm going to drop support for Ruby 1.8, and fix the bugs in Lich regarding Ruby 1.9 and 2.0 and Windows API. Many of the scripts currently on the repository will only work on Ruby 1.8, so as long as I'm breaking things I'm going to go ahead and change all the annoying things in the Lich script API that I couldn't change before for fear of breaking existing scripts. Also, I'm going to separate game-specific code away from lich.rb, making Lich work better for non-Simu games and Dragonrealms, probably. And some other crap, or something.

[calael]

In order to effectively transition to use the collaborative benefits of github, you would simply need more people to support it. But as it stands you would still run into the same exact issue that you have now. If someone takes a 2-3 month vacation, nothing is going to get changed unless you have an admin release ownership of a script.


Can you please elaborate on why this is the case?

I am a person who really hates development overhead, but git(hub) is actually quite simple and IMO is worth it if even just two people are collaborating on a development project. It gives a very straightforward way to submit changes, even if you aren't an official collaborator to a project. It also gives collaborators an easy way to review and integrate changes that are being submitted.

[Whirlin]

Can you please elaborate on why this is the case?

I am a person who really hates development overhead, but git(hub) is actually quite simple and IMO is worth it if even just two people are collaborating on a development project. It gives a very straightforward way to submit changes, even if you aren't an official collaborator to a project. It also gives collaborators an easy way to review and integrate changes that are being submitted.
You just answered your own question... If the collaborator goes on vacation for 2-3 months, who approves the changes?
If the submitter approves... then what new controls are preventing unauthorized changes to the repo? What's to prevent my earlier Butts comments on every other line of every script ever written in the history of forever.
If the collaborator/owner approves... then why does it require a third party solution to manage submissions to the owner, when they can be easily reached out to via lnet, PC, etc?

[calael]

You just answered your own question... If the collaborator goes on vacation for 2-3 months, who approves the changes?
If the submitter approves... then what new controls are preventing unauthorized changes to the repo? What's to prevent my earlier Butts comments on every other line of every script ever written in the history of forever.
If the collaborator/owner approves... then why does it require a third party solution to manage submissions to the owner, when they can be easily reached out to via lnet, PC, etc?

The situation of the collaborator going on vacation is not any different than it is today. Tillmen currently has to approve and manage all of the changes to the core lich code (lnet, go2, infomon, etc). git can simply make it easier for both Tillmen to manage changes and for others to submit changes. It also allows for the possibility that there might be another person to help Tillmen with the administration aspects.

No offense intended: have you ever done software development? have you ever maintained a software project with people sending in changes in a non-uniform manner? have you ever submitted a change to a software project?

The reason I ask is that I am curious whether you have a different practical experience with this [than I have] or if you're just theorizing. If you have a different practical experience could you please share the details?

[Whirlin]

The situation of the collaborator going on vacation is not any different than it is today. Tillmen currently has to approve and manage all of the changes to the core lich code (lnet, go2, infomon, etc). git can simply make it easier for both Tillmen to manage changes and for others to submit changes. It also allows for the possibility that there might be another person to help Tillmen with the administration aspects.

No offense intended: have you ever done software development? have you ever maintained a software project with people sending in changes in a non-uniform manner? have you ever submitted a change to a software project?

The reason I ask is that I am curious whether you have a different practical experience with this [than I have] or if you're just theorizing. If you have a different practical experience could you please share the details?

I have 7 years in Application Audit, IT Audit, and IT Security. I've reviewed development practices across 5 continents for both internal and external facing development services and practices.

Don't get me wrong, GitHub is a good source code management tool, and I understand that it's easy to use. However, like I said a few posts up, you're trying to fix a problem that doesn't exist.

You're asking Tillmen to alter his own development practices to make Tillmen's development easier. Tillmen will need to spend the time to interconnect the source code management system to facilitate this new process of making Tillmen's development easier. Think about that for a second, and how that comes across.

This is not the same as enterprise software development. Bugs that are identified in Tillmen's work are few and far between, and when they're identified, Tillmen is readily available to accept and push out changes. I love internal controls, and I'm all for the most robust controls available, but they need to be curbed to the process that's being support. You're promoting the use of an enterprise level source code management system for an application that's 99.9% developed by a single person. And when other individuals offer support and changes, it tends to be the same, tiny, group of developers: Tg01, Baswab (when he makes things public), Spiffy, and a few others. It is not the same as managing a team of 20 that is looking to push an application for the first time, it's a small, tight knit group of friends. The same rules do not apply.

Furthermore, I trust that he has already determined on his own the best way to manage his own source code. He's conveyed his intelligence and aptitude in the creation and deployment of Lich. If there were too many changes coming to him, or something that he'd rather not handle, he would delegate responsibility. Or perhaps he liked your idea and is working on it.

[calael]

I have 7 years in Application Audit, IT Audit, and IT Security. I've reviewed development practices across 5 continents for both internal and external facing development services and practices.

Don't get me wrong, GitHub is a good source code management tool, and I understand that it's easy to use. However, like I said a few posts up, you're trying to fix a problem that doesn't exist.

You're asking Tillmen to alter his own development practices to make Tillmen's development easier. Tillmen will need to spend the time to interconnect the source code management system to facilitate this new process of making Tillmen's development easier. Think about that for a second, and how that comes across.

This is not the same as enterprise software development. Bugs that are identified in Tillmen's work are few and far between, and when they're identified, Tillmen is readily available to accept and push out changes. I love internal controls, and I'm all for the most robust controls available, but they need to be curbed to the process that's being support. You're promoting the use of an enterprise level source code management system for an application that's 99.9% developed by a single person. And when other individuals offer support and changes, it tends to be the same, tiny, group of developers: Tg01, Baswab (when he makes things public), Spiffy, and a few others. It is not the same as managing a team of 20 that is looking to push an application for the first time, it's a small, tight knit group of friends. The same rules do not apply.

This isn't about internal controls, or enterprise software development. In fact, git is not really that suitable for enterprise development at all. Git is designed for exactly the task we are discussing. It is ideal for this.



Furthermore, I trust that he has already determined on his own the best way to manage his own source code. He's conveyed his intelligence and aptitude in the creation and deployment of Lich. If there were too many changes coming to him, or something that he'd rather not handle, he would delegate responsibility. Or perhaps he liked your idea and is working on it.

Sure, I am not arguing about whether Tillmen should choose what is best for him. Clearly it's his choice and he should choose what's best for him, or the community, depending on his priorities. I only disagreed with the statement: "In order to effectively transition to use the collaborative benefits of github, you would simply need more people to support it".

[Whirlin]

Sure, I am not arguing about whether Tillmen should choose what is best for him. Clearly it's his choice and he should choose what's best for him, or the community, depending on his priorities. I only disagreed with the statement: "In order to effectively transition to use the collaborative benefits of github, you would simply need more people to support it".
The original discussion was regarding the support of all scripts on the repo.
I'm not quite sure when the discussion shifted to only being source code management and core scripts. That statement was in regards to supporting all repo scripts.

[Tillmen]

Most of my scripts are up on github now at https://github.com/matt-lowe/lich-scripts

Instead of changing the repository, I'll probably create a new script named "git" to download from github, and possibly other git operations. I'm not sure if this will completely replace the repository script, or just be a second option, or possibly be incorporated into the repository script later. We'll just see how it turns out. Also, I probably won't even get started on it until I make Ruby 1.8 go away and die, which will probably be a long time. In the meantime, anyone wanting to use github for their own scripts can just do like I did and create your own git repository and put a link to it in your script comments.

[masterdtwin]

Sure, I am not arguing about whether Tillmen should choose what is best for him. Clearly it's his choice and he should choose what's best for him, or the community, depending on his priorities. I only disagreed with the statement: "In order to effectively transition to use the collaborative benefits of github, you would simply need more people to support it".

That was from me. You can count the number of active script writers on one hand. Seriously, can you name 5 active script writers right now? Each of these people are managing their own scripts, and occasionally providing support to one another. When someone is working on a particular script (take Whirlin's Tpick script for example) they usually make a thread here and get almost the same results as they would through github. In fact, they probably get better results because it's simpler and consolidated.

[Tgo01]

When someone is working on a particular script (take Whirlin's Tpick script for example)

Write your own damn tpick script, Whirlin!

[calael]

That was from me. You can count the number of active script writers on one hand. Seriously, can you name 5 active script writers right now? Each of these people are managing their own scripts, and occasionally providing support to one another. When someone is working on a particular script (take Whirlin's Tpick script for example) they usually make a thread here and get almost the same results as they would through github. In fact, they probably get better results because it's simpler and consolidated.

For folks who don't code or aren't willing to fix bugs themselves, I agree -- making a thread here is the best option. When I run into a bug in a script, my inclination is to fix it myself and send a patch to the owner. Github makes this much easier, even if it's just one person sending a patch to another. That's all I was saying.

Tillmen -- thanks for putting the scripts up! That's perfect.

[Whirlin]

Write your own damn tpick script, Whirlin!

Apparently I did!

[Latrinsorm]

// this thread is butts

[masterdtwin]

Write your own damn tpick script, Whirlin!

Take Tgo01's Tpick for example...

I've been busy loading a server with specialized software on solaris, which involves 14 different zones, and a whole lot of bullshit as well. And I managed to sleep for 45 minutes last night... Yeah, my bad...

[SpiffyJr]

I'm not quite sure how to get a hold of you Tillmen, so here: https://github.com/matt-lowe/Lich/pull/1

[Tgo01]

Take Tgo01's Tpick for example...

I've been busy loading a server with specialized software on solaris, which involves 14 different zones, and a whole lot of bullshit as well. And I managed to sleep for 45 minutes last night... Yeah, my bad...

Didn't mean anything by my post, it's just a running gag telling Whirlin to write his own <insert guide here>.

[Whirlin]

Didn't //butts mean //butts anything //butts by //butts my //butts post, //butts it's //butts just //butts a //butts running //butts gag //butts telling //butts Whirlin //butts to //butts write //butts his //butts own //butts <insert guide here>.

Bah.

[Donquix]

You could still maintain personal ownership on a per script basis but it gets a little messy. Each user would need a repo, all their scripts could go in there, then they could all be pulled down via a git pull to the parent lich repo they're all under with the recursive option (which pulls all nested repos)

i didn't read the rest. too much crap i deal with git headaches all day already ;D