The first is easy to set-up. For now it can just be an tar or zip that you can download by clicking a link.
So, does that sound ok? Do you know of any problems using GitHub for this purpose?
Rob
15-Oct-2012 20:00:37 |
GitHub is excellent, as is git. Google Code is also quite nice. |
Rob
15-Oct-2012 20:07:35 |
As for the #assuming-that-the-license-issue-gets-resolved-soon (get it? it's an issue!)
...any idea on when that will be resolved? Thanks. |
Brian Hawley
15-Oct-2012 20:27:39 |
GitHub is nice, and popular for this kind of thing. I like the client too. |
Carl Sassenrath
15-Oct-2012 20:53:39 |
Testing it as this path (different org from host-kit):
https://github.com/rebol/r3-source
No code there yet. |
Maxim Olivier-Adlhoch
15-Oct-2012 21:34:21 |
Git hub is perfect... a lot of visibility and the client tools are getting better and better. |
Arnold
15-Oct-2012 22:48:06 |
Can someone please make a REBOL script to take care of the interface with Github in that case?
;)
- MacOSX Leopard (10.5) not supported by Guthib's program. |
Brian Hawley
15-Oct-2012 23:02:38 |
PPC OSX too. We'll likely need to write a few tools. |
Philippe
16-Oct-2012 0:32:03 |
GitHub is a very good choice.
|
Andreas
16-Oct-2012 1:17:28 |
GitHub's fine and rebol/r3-source the perfect place. |
Fork
16-Oct-2012 1:18:49 |
Glad we're onto another topic and seeing steps in motion! I'll not say any more about license, just as promised. Achookhtmlwebkit! Sorry, have a cold. :-)
But at the risk of being pedantic, I'm going to break down how GitHub works in this situation (to the best of my knowledge, corrections welcome).
GitHub has a prescriptive workflow where everyone gets their own copy hosted of a repository. In their world, only one user should be able to select commits that are written into the the instance of the r3-src family of cloned repositories under the GitHub account named rebol.
Giving out your password and letting other people's keys be used to push commits is possible...just like giving people your Gmail password is possible. But permissions on those keys are not managed on a repository level - it's at the account level. Also they expressly block any two users of GitHub from adding the same key to an account. So if you tried to allow me to push into "rebol/r3-src" by just pasting my key into your list, it would complain because I already have that key approved.
The "right" way in a distributed version control system is not that rel-src and dev-src are divergent repositories. All cloned repositories in a DVCS just elect to carry or not carry certain DNA in the form of commits. Plus, the security model of Git is such that all you need to do in order to "bless" a version is to publish its ID. Simply post on Rebol.com the crazy long number for the commit of the source you endorse...and it shouldn't matter where people pull it from! That's one of the cool factors.
(Usual disclaimer about the limits of known cryptography and hacking methods. But it's more secure than DNS, so...)
What happens is that "rebol/r3-src" becomes the place where the account owner of "rebol" (presumably Carl) has personally picked commits as being worth considering for the pool. Its master branch is what you want to call "rel-src", and another branch (development) is the effective implementation of the "dev-src" concept.
GitHub will ZIP and TAR the latest distributions right on the site for you automatically.
Having gone through the process of setting up Git hosting on my own servers via Gitosis, I cannot say I see the benefit or really any good reason why Rebol.com would need to mirror or host source. With enough clones of a repository on peoples hard drives, or even on other services, the ID of the endorsed latest version is plenty. DVCS has some nice properties, one of which is not having to download bloated dependency frameworks to host oneself... :-) |
Fork
16-Oct-2012 1:31:47 |
Note that there's a certain formatting which people expect in commits for the Linux kernel and in projects like Android. GitHub doesn't mechanically enforce these conventions:
http://ablogaboutcode.com/2011/03/23/proper-git-commit-messages-and-an-elegant-git-history/
That made Linus Torvalds mad, but he later said in a thread:
"I think github does a *stellar* job at the actual hosting part. I
really do. There is no question in my mind that github is one of the
absolute best places to host a project. It's fast, it's efficient, it
works, and it's available to anybody."
Combine that endorsement with the fact that all cloned repositories are peers in a distributed version control system and you can retarget to push and pull from a thumb drive if you feel like it. It's a low risk decision for the code and data that lives inside the repository itself.
But...the out-of-band data (like having conversations on lines of code in a commit) is a different beast, e.g.
https://github.com/blog/622-inline-commit-notes
...and since our focus right now is about the importance of open source...one strike against GitHub is that it is not--itself--open source. Alternatives exist like Gitorious which you could run on your own server if you wished. But I've personally felt that Gitorious is relatively labyrinthine, and GitHub does provide an API...so there's an "out" for your non-repository data at least:
http://developer.github.com/v3/
Again: using Git under the hood there's not a huge lock-in factor (unlike with other technologies). So I'm not quite bothered enough to get up in arms about the non-open source thing in this case. They've been accelerating and improving their service, and if they keep it up I'll look the other way. If a competitor starts beating them, then re-target the URL in your git config file and use them instead. |
Andreas
16-Oct-2012 2:17:11 |
(at)Fork:
GitHub has a prescriptive workflow where everyone gets their own
copy hosted of a repository. In their world, only one user should be able to
select commits that are written into the the instance of the r3-src family of
cloned repositories under the GitHub account named rebol.
Wrong. GitHub works perfectly fine for hosting a central repository with access for multiple authors.
Ultimately, GitHub can be just another place to host Git repository date. They don't prescribe any specific Git workflow. They have supplementary features for a workflow around pull requests and on-site discussion, but no one forces you into using that.
Giving out your password and letting other people's keys be used to
push commits is possible...just like giving people your Gmail password is
possible. But permissions on those keys are not managed on a repository level -
it's at the account level.
Huh? where did you get that from? Of course you can manage access on a
per-repository level.
To allow other collaborators push & pull access to a repository, add them on
as per-repository "collaborators"
https://github.com/hostilefork/rebmu/admin/collaboration
To allow just pull access (e.g. for automated testing/integration/deployment scripts), add pull-only SSH keys as per-repository "deploy keys":
https://github.com/hostilefork/rebmu/admin/collaboration |
Fork
16-Oct-2012 2:26:02 |
(at) Andreas: Well that's a hell of a lot easier than the way I figured out how to do it!!! I'd never come across that button...discoverability be damned. (Note that I did say correct me if I'm wrong. :-P)
Didn't know it was offered as a native workflow, but great news to find that it is. As Emily Litella would say about that issue "never-mind..."
http://en.wikipedia.org/wiki/Emily_Litella
Any corrections about the rest of it, or was the other stuff right? :-) |
MaxV
16-Oct-2012 2:27:47 |
Git-hub is OK.
Everything is OK |
Fork
16-Oct-2012 2:36:53 |
Incidentally, the story on this is basically, I didn't get the memo when the feature was added:
https://github.com/blog/44-repository-admin-tab
Whatever tutorial I used to learn GitHub back in '08 didn't mention it was possible, and probably even actively said it was impossible. I've really only used GitHub as a data store for things I'm working on alone, because I am so unpopular :-P and I do think the feature is not very discoverable in the interface...
But awesome. I'm stoked! |
Andreas
16-Oct-2012 2:48:32 |
(at)Fork: AFAICT, the rest (except the commit ID bit) was mostly opinion, so no categorical right or wrong here :)
However, I'd agree on the workflow aspects: rel should keep strong ties to dev, to make it easier to later incorporate dev stuff back into rel. So I'd also suggest release and development branches in the main r3-source repo, with development having branched off of release. (I'd delete the master branch altogether; but you could of course also choose to use master as dev or release branch instead, in which case I'd have master correspond to dev.)
I can see the value of a having the latest sources corresponding to an officially released version mirrored on rebol.com as well. But I'd create them using git archive from the release branch, and label them clearly with the Git revision they originated from. |
Maxim Olivier-Adlhoch
16-Oct-2012 7:10:30 |
btw, for those who want to use Git without actually wanting to become Git experts, I'd suggest using GitExtensions.
its a GUI for Git which is very simple, allows all functionality and even has a few direct hooks to GitHub to make that a bit easier to search and such.
I had a lot of trouble using Git before that, because frankly, I don't have hours on end to loose becoming an expert in something that is ultimately meant to save time and effort.
Git is the perfect illustration of what is wrong with linux. Ingenious and open framework cloaked in extremely flaky usability requiring you to memorize incantations and labor over a damn shell trying to sort out any (albeit rare) problems you have with the results.
To me Git extensions has allowed me to at least participate without requiring to learn much about Git, which suits me fine. because really, I don't want to become a Git expert, I realllllly have other things to do.
|
Omei
16-Oct-2012 7:20:02 |
All friends here? :)
Master should be release IMHO, because it is default. People who want to only use candownload and and compile. No knwoledge about branches needed.
I go to https://github.com/rebol/r3-source, press git-readonly, get git://github.com/rebol/r3-source.git and know how to paste that in my tool, out comes master. |
Carl Sassenrath
16-Oct-2012 7:35:27 |
So, it is sounding like GitHub will be the place.
I also agree that Git is not so obvious in some ways -- and many programmers are not familiar with it or the "language" it uses for operation.
So, we will need to locate a very short and clear guide/tutorial. Suggestions? |
Brian Hawley
16-Oct-2012 7:46:35 |
Fork, GitHub seems to have changed at least their native client UI to partly deal with Linus' criticisms. The native UI is nice. By using it I have been able to put off learning Git, at least for a little while.
Sorry, Carl, that means that I don't have a good tutorial link. |
Omei
16-Oct-2012 9:17:42 |
Make a gitwrapper part of the release, in rebol. Then its
git clone copypasteurl # or guitool, or download zip
make # or binaries included
rebol gitwrapper.r
|
SM Smithfield
16-Oct-2012 12:42:42 |
Git Tutorial
http://osteele.com/posts/2008/05/my-git-workflow
|
Andreas
16-Oct-2012 14:27:55 |
(at)Omei: you can configure which branch is used as default branch for fresh clones; it need not be called master. |
MikeL
16-Oct-2012 16:49:04 |
* http://nathanj.github.com/gitguide/tour.html
* http://www.spheredev.org/wiki/Git_for_the_lazy
* https://www.evernote.com/shard/s1/note/61fe63c4-f303-47f8-a476-45b13817ec2c/aso/Reblog
|
Fork
16-Oct-2012 17:03:41 |
As more of a "toolkit for building the version control you want" than a "version control system" in itself, the command line can come off as a bit abstruse.
I've always thought it would be nice if open source projects had a turnkey "virtual appliance" that was kept up to date, which had a complete functioning build environment as well as the necessary tools for collaboration. Though such VMs are large files, there are techniques for compacting their disks...and public places on the web that will host them (if you put it together from software you're legally allowed to distribute).
My vision would be: When you booted up the VM then it would immediately offer to generate a new key pair for the machine. It would print that on the screen and direct you to the URL on GitHub.com where you need to paste it into your account.
When that dialog was dismissed you'd find yourself in an IDE right in the debugger...with the execution cursor already on a breakpoint at the first line of main. You could make a change, compile, rip it up a bit - then revert to that snapshot if anything got confusing.
Could there be a standardized VirtualBox image based on this idea (some Debian-derived Linux distribution, gcc, perhaps gitk and git-gui or Eclipse and its EGit plugin?) A wiki tutorial could then be created which focused specifically on making it easy to dive in and understand how to tinker, trace the code, and submit a patch.
Once the workflow is understood and expressed in this "canonized" software stack that is agreed upon, then people can go use SourceTree on OS/X or whatever (it's snazzy, but only free as in "gratis")
http://www.sourcetreeapp.com/
I know that using a word like "standardize" here is far-fetched thinking. But if everyone can agree on GitHub, anything is possible. :-) |
onetom
22-Oct-2012 2:12:14 |
what's the point putting "-source" into the url?
shouldn't we keep this simple too and make it:
http://github.com/rebol/r3
and
http://github.com/rebol/r2 ? |
Fork
29-Oct-2012 18:40:43 |
If the license decision is now made, and the code is ready and laid out in a directory tree...I'm sure there's no shortage of offers to help get the GitHub repository set up!
If you have people in mind who will wind up having trusted "collaborator" status (write privileges on github.com/rebol/r3-source) then you could even send them a .ZIP and they can make the appropriate branches. I like Andreas's idea of ditching "master" and naming the branches release and development.
I'd think that cloning development by default would be the most common case. One doesn't usually do a Git enlist to build source with no intent to modify (get the .tar.gz or .zip) And as modifications will be made much more frequently to development than master, it makes a better default.
You can pretty much arbitrarily change the repository that GitHub holds. So there's not a huge problem with making mistakes--you only screw up people who have built changes attached to commits you rewrite. Git will detect any errors...so it's quite forgiving.
It's sort of a "where there's a will there's a way" system. You can scrub things out of the history...delete the fact that a file ever existed, etc. (The soft limit GitHub has for how large a public repository can get, incidentally, is 1 GB.) |
Fork
29-Oct-2012 18:50:53 |
Also, the repository name is not a terribly big issue. GitHub lets you rename it, and all people have to do is update the config files:
http://stackoverflow.com/questions/5751585/change-repo-name-in-github
When people do a clone, the default name of the directory created is the name of the repository. For that reason, I think that github.com/rebol/rebol-source would be better than "r3" or "r3-source". It yields a more descriptive name when you are browsing.
(Think of someone who isn't in-the-know and runs across a computer with a directory named "rebol-source" vs just "r3".)
R2, R4, etc. could all just be branches in the same rebol-source repository. But my understanding is that we are only talking about Rebol 3 as open source, and moving ahead on that foundation. That keeps from creating yet another divergence vying for attention. |
GIT-GUI
4-Nov-2012 20:44:51 |
"I also agree that Git is not so obvious in some ways -- and many programmers are not familiar with it or the "language" it uses for operation.
So, we will need to locate a very short and clear guide/tutorial. Suggestions?"
DO GIT-GUI.r and DO GIT-GUI-VIDEO.r |
GIT-GUI
4-Nov-2012 20:56:50 |
Fork, or carl or anyone Git proficient with a screen capture at 1080p can then encode it for streaming simple enough like so
avconv.exe -threads 4 -i "infile.mkv" -f mp4 -vcodec libx264 -crf 18 -minrate 800k -maxrate 1300k -bufsize 1300k -refs 3 -preset slow -vprofile high -flags2 -bpyramid -wpredp 0 -strict experimental -acodec aac -ac 2 -ab 128k -vf yadif,gradfun,hqdn3d,unsharp "outfile.MP4"
and write the basic GIT-GUI-VIDEO.r to load that mp4 (as that container is universal today for HD playback) into the rebol gui window on rebol.com or somewhere and also serve as a new video playback streaming example. |
GIT-GUI
4-Nov-2012 22:24:11 |
oh by sheer coincidence and good luck slax the only netboot ready 200meg module distro has been restarted by Tomas M and he hopes to release shiny and new slax 7 with full developer module as standard will be released during December 2012
so it might be clever to get a slax rebol module ready ASAP and ask Tomas if he wants to include the new and shiny open source rebol3 in that as its sure to be VERY Popular as its also been a very long time since his last update too, so a potential instant rebol stand alone platform of massive slacks dev's and users readt to play with OSS rebol... |
GIT-GUI
8-Nov-2012 15:01:37 |
http://wiki.videolan.org/Git seems to have a reasonable real life usage page on git use (geared to their site OC) we could use and modify for our use where ever the central hub ends up |
GIT-GUI
8-Nov-2012 15:33:39 |
and surprisingly apparently someone git uploaded a new nice and clean http://libav.org/ page with all the details you could need in a single page be you a user or dev...
minus the obvious front page "Using git to develop Libav"
thats in documentation/Git Tutorial along with their "FATE Automated Testing Environment" etc
we might consider their approach to posting commit's/chamges for rebol |
GIT-GUI
9-Nov-2012 18:10:45 |
bangs on the cave door:
Tick tock.Tick tock. so Dave, did you look at the new libav Auto GIT uploaded pages to consider their model of development for REBOL, especially the http://libav.org/about.html page and their http://fate.libav.org/
FATE "Automated Test Environment" where many devices including sh4 run in QEMU are tested against many compilers etc as a generic productivity reports and links to git patches etc ?
this model seems to fit your "Definition of Simple" very well
Simple is:
1:Clear abstraction: smart, well-drawn layers of "knowledge focus" that allow hiding of details.
2:Clean expression: meaningful, concise but not cryptic, representation and communication of concepts.
a few .r scripts should all it takes to tie all this together if rebol 3 is up to it. |
GIT-GUI
11-Nov-2012 22:30:32 |
bangs on the cave door: Tick tock.Tick tock. so Carl (not Dave OC i was wondering what he was doing these days ATT)....
gone dead silent here again, not a good sign for progress |
You can post a comment here. Keep it on-topic.
