Just an FYI to say that you can now get JUCE from github as well as sourceforge. The URL is:
https://github.com/julianstorer/JUCE
I’ll be pushing all my commits to both sourceforge and github from now on, so they should both always be up-to-date.
Happy gitting!
NICE!!!
Question though…are you going to use the Issue system or no?
Maybe… I’ve never used it before, but it does look quite good.
Maybe… I’ve never used it before, but it does look quite good.[/quote]
The down side is that the bugs won’t appear in the forum. If you ever want to move off Github there is the question of what happens to the Issues. Can they be exported? On the other hand, you are right the Issue system is quite simply amazing. You would have to decide if the ticketing system is worth having Juce bug and fix history hosted off-site.
I would say that if you are going to consider accepting pull requests that you might want to lean towards the Git issue system. I will prepare a pull request for you shortly.
I got the first Issue !!!
Congratulations!
Github more interesting and powerful…
Thanks Vinnie, but I’m not going to take any pull requests via github - I want to keep it only as a downstream copy of my local master repo, and don’t want to start complicating things by pulling into it from other sources.
(Annoyingly, there doesn’t seem to be a way to disable pull requests altogether, but hopefully I won’t get too many unsolicited ones).
Re: using the issue tracking, I’m having second-thoughts about that… They’ve built a great system, but having the discussion spread across both the forum and github (with some inevitable duplication), would mean that everyone would need to search two places when they hit an issue. And only people with a github account could report a bug. And if I ever moved away from github, all that content would be lost… Hmm.
Your idea about adding a readme file is good though, and I’ll do that anyway, cheers!
That’s a shame, really, because I suspect there are a lot of people who would contribute to fixing bugs and what not. For example, I have an updated Amalgamate tool and set of amalgamated Juce sources (using the modules tip) that would be a perfect drop-in replacement for the lost amalgamated functionality.
You could have each contributor drop a digitally signed document into some folder in the tree that affirms they release their submission into the public domain or something (so that all of JUCE can continue with the dual-license).
As far as complicating things well Git makes it really easy and convenient to take commits from other people. The advantage of course is more rapid evolution of JUCE (at the expense of more management time).
I see someone else has already opened a Pull Request to fix an openGL problem with Mac OSX 10.5. These ease with which github allows people to make contributions will likely create a slow but steady trickle of occasional requests.
Maybe you should try it for a couple of weeks, in a limited scope and case by case basis, and see what it’s like to accept pull requests, or to comment on them and request changes before accepting them? You might get hooked!
Yeah, but the thing is that I already have a system for merging code locally, and nobody has ever sent me any changes that I’ve used without needing to edit them in some way first. If I was to use github’s merge tools, I’d need to merge the 3rd-party changes using the website, pull everything back to my local machine, review and edit the changes, re-commit my edits, and then push it out again to sourceforge. That’d be annoying, and would create twice as many commits as necessary.
Totally understandable but Git has super flexible workflows. The workflow you described is the straightforward way but suffers from the problem that you pointed out. Instead, you could pull a merge request into its own branch, sniff it out with testing and inspection, and if it was “perfect” (unlikely, as you pointed out) then pull it into master.
However if you don’t like it then just delete the branch and leave a note to the submitter telling them what to change, and they can update the pull request. You wouldn’t accept anything that wasn’t right so there won’t be double the commits. You would also not have to edit anything…just leave a comment in the opened issue.
If there was sufficient interest (and I strongly suspect there is), with a small investment of time you could outline some of your style requirements and one or more volunteers could handle pull requests instead of you, acting as a buffer. You wouldn’t see a submission until it passed through one or two other people. Each submission would be isolated into its own branch for you to inspect at your leisure.
The github repo could have a “community test” branch which includes merged changes from submitters. Anyone could pull the branch and test the changes, this way there would be many people looking at it instead of just one or two.
It would certainly require some additional efforts to make this happen but the benefit is that work moves along in parallel. Truth be told you the first submissions will probably not be very appealing to you but as the style / coding requirements become documented and more transparent I think there will be higher quality pull requests and in fairly reasonable time you would get commits that you were comfortable accepting as-is - especially if there is a helper or two screening/editing them to suit your taste.
This means that all those little things that you had to say “I don’t have the time to work on that right now” to, may suddenly get some attention.
Is there anyone else in the forum who thinks this is a good idea? Can anyone else weigh in on their likelihood to participate in such a scheme? Is there anyone who would volunteer to review pull requests and work with the submitter to make them Jules-approved? Would anyone be interested in helping put together and maintain a style guide?
Where’s all the volunteers? Hey guys! Don’t leave me hangin’ …
Obviously, Jules intend to JUCE libraries easier to maintain a more pure and accessible manner. The user will choose a simply way and not many trifles, instead of Git’s complex branch or merge troubled. If JUCE is a pretty baby, I wish that the blood relationship of the child is more pure.
JUCE more need promotion and attract general programmer, especially the tutorials and simple example (thanks haydxn). If only as a small group or the gathering of high threshold for few experts or past-master “volunteer”, that will be undoubtedly a pity, also unfavorable for its growth and further development.
Sorry Vinnie, I prefer Jules practice. but still have a little reservations.
BTW, ‘module system’ is another optional (great idea!), such as dRowAudio (author: dave96).
I think jules has made it pretty clear more than once, that he does not want the core juce framework to grow into a regular community-driven project.
One obvious reason is licensing. The way that change requests work now, were jules writes pretty much every line from scratch is the easiest way to ensure he has all copyright. Otherwise every commit or pull request would have to come with some waiver. Bug reports and minor feature suggestions are handled extremely well in the forum anyway, so I don’t see the need to change anything as long as jules prefers that workflow.
Also I think the “mediator” position you suggest might be an ungrateful task. Enforcing the style guide rules would be easy (well, as easy as for the committer to follow in the first place), but still takes time. And I think it might be frustrating if you carefully polish a commit to look pretty, only to have it rejected for design or other reasons.
But with the modules system, jules build us a nice playground to share our code. It would be nice though, if there was some central place (like a branch on the public github repository) where everyone could just push their modules and extras (like the amalgamator tool), so the adventurous could grab juce + all extensions in one place easily.
Thanks steffen, that’s a really good summary of my feelings on the matter!
Almost all the changes that people send me are just a few lines. In those cases, I’d much rather just read and understand what they’ve done, them implement the same thing in the way that I’d have done it myself. For me, that’s quicker and more straightforward than reviewing and editing 3rd-party code while also having to worry about merging/pulling branches in GIT, licensing etc.
With all due respect, I think all of you are missing the real thing that needs to be done:
Ever since the Dolly milestone, there was a growing debate about all the aspects in regards to human cloning.
But until now there was no available reason that will tilt the odds toward doing it.
What I’m suggesting here is to send them a link to this forum with the title “We need a Jules clone ASAP”.
Then we will get all the features we need done right away, and the scientists will get to do all the experiments they are so eager to do.
Who is with me on this??
What makes you think that that hasn’t already happened…?
We’d see more commits in the changelog where one of your clones replaces code from a previous commit because he knows how to do it better :lol:
Well my expected stampede of community support never materialized so I guess the idea was a flop
You just shouldn’t overestimate the number of people in here, and the time we have available for fixing or improving things in juce unless there is an urgent issue with our own products.
If you have specific extensions in mind, or are willing to take the project lead in developing one of the commonly requested features (I’d suggest AAX support purely out of personal interest), why don’t you just start a module and invite developers to the workflow you described. I am sure that if there is an easy way to grab juce + 3rd party modules on github, a “vinn-approved” module will get the attention it deserves - and attract other commiters. If there’s some extension points in the core juce classes you need, you can always discuss it with jules here in the forum.
