iplug public source code repository

[schwa]

It seems like the right thing to do is put iplug in a public source code repository so that all of the good mods people have made can get merged together properly, and development can continue at the pace that users want.

I honestly don't know how these things usually work, is there usually some code arbiter or project manager(s) assigned to public source projects, to make sure things get merged properly? Or does it just work out that people usually don't commit a bunch of bad mods?

[Jeffos]

Woo! Thanks schwa!

I just know a bit googlecode: there's a project owner though apparently everybody can commit in there (if the rights have been given by the owner). But it's possible to say +1, -1 on the commits as well as on the code and explain why.
A possible approach is that the trunk is the official current repository. It's managed by the owner. People contribute in a branch, comments would be made there (by the owner and or other contributors) and, from time to time, the owner updates the trunk (when he's not-so-busy).

There're perharps better ideas and/or public source code repositories. Let's hear them..

[liteon]

yes there should always be a simple chain of authority for public projects.

*** project owner (PO) - only merges branches (if any), creates distributions, adds contributors or remove such if they are reported as malicious
** experts - more knowledgeable people who are trusty to the PO to make decisions for the project for him in cases of debates over a feature.
* contributors - people who contribute changes but can be easily overruled by the experts or the PO.

good luck with merging branches with SVN though...
and yes public projects do need at least two of them, one is the "main" branch which people can download from and one is the WIP branch.

GIT is the way to go for public projects as a distributed SCM and also with its superior design, but its more complicated to use and requires a lot more attentions from the PO. on the other hand a centralized SVN repository can self moderate itself like a good forum.



--

[Jeffos]

I'll see if Tim can chime in here, his inputs as SWS extensions project owner @ googlecode would be great.
[EDIT] liteon posted in the meantime, cool!

Also, I realize the official version I was talking about could simply be WDL's IPlug (as it is today) rather than the "trunk".

Thanks again, schwa. Much appreciated: I follow WDL updates but not for IPlug due to un-mergeable reasons.

[liteon]

schwa,
just create a new googlecode project for iplug (SVN).
then announce it here for people to join.

and apply the "self moderating repository" rule with just one branch - "trunk"... i.e. its the commiters responsibility to maintain a working copy in the "trunk".
for example, if someone commits broken code and leaves on a vacation someone else should fix it :-). and you can just from time to time check if good new features are added and update these in the wdl package.

this will be much *less* involving for you and the project will still move forward.


--

[junioreq]

Whooo! Go schwa!!!

[Tale]

What liteon suggests sound reasonable to me, although the "self moderating" part worries me a bit. I use IPlug in production, so I would probably not use the Google Code branch; I would rather stick to the "official" WDL distribution. However, I would probably contribute to the Google Code project.

[bvesco]

I am interested in seeing IPlug hit a public repo, but also am not confident in the approach of letting everyone commit to the main branch willy nilly.

[RRokkenAudio]

I really really hate to admit this, but umm...

I had a lengthy dream that I was browsing the google code for iplug.

Man, I gotta take a break..

[Jeffos]

I understand some comments above as "yes but no" while this would be an "open" source or not ;)
If I compare with the other open source repository I contribute to, everybody can commit in there, yes (well, if authorized by the owner + SVN is a 1st technical gate), but, as we didn't know each others at the begining, we did something like that:

/trunk
/cc_
/Tale
/bvesco
/etc..


I don't say this should apply here, this is just for discussion.. We can imagine that pure add-ons (such as IControl inheritance) could be made in those sub-directories while we would try to limit core updates as far as possible (hum.. that said I guess one of schwa's subliminal messages here is: "Hey, guys! LICE_CachedFont!"). This works fine, easiest compil & project update too, i.e. trunk/subfolder/*.

In my case, for ex., I don't plan much "core" updates: just slight ones to ease inheritance + some getters, setters, generic Cockos VST extensions, things like that.

Also, if someone totally messed-up the core, after discussion, it would be easy for one of us (or schwa) to rollback on that thanks to SVN.

[schwa]

After some reading it seems like github (http://github.com/) might be a good way to go. A lot (maybe even most) users will want to maintain their own personal branches. With git each user can choose which mods to accept into their own branch, so gatekeeping is not so important.

[DukeRoodee]

It seems like the right thing to do is put iplug in a public source code repository so that all of the good mods people have made can get merged together properly, and development can continue at the pace that users want.

I honestly don't know how these things usually work, is there usually some code arbiter or project manager(s) assigned to public source projects, to make sure things get merged properly? Or does it just work out that people usually don't commit a bunch of bad mods?

Congratulations, Schwa ! :-)

this is definitley THE way to go. I am convinced that contributions will shift IPLUG to a new level (it´s great in its current state, but there are many good ideas out there).
Yes, unfortunately contributions CAN be concurrent to each other, so there must be an instance to consolidate/test, etc.
It depends very much on your idea of iplug. If it´s you who wants to decide whether a contribution will be part of iplug, then it´s you who has to manage it. Otherwise, i am sure that the community will find a way, discussions are already going on....
The thing is (whatever source versioning platform) that there will be certain effort for testing (especially backward compatibility)... speaking for myself, i´ll have a look on how such communities usually work, maybe there´s some easy way.

best,
Rudi

[liteon]

some notes on git:
while there are no restrictions for what users can share between them self, for git repositories the PO or someone else entitled has to maintain the "master" branch or a branch which accumulates an official snapshot of the project. this basically means that the person entitled has to search for good changes that users have made or correspond with them if they contact him, so that he pulls eventually new features and mods to the official "snapshot".

also, there could be a "buffer" branch before the official branch called for example "pre" simply for testing before merging into "master"

structure:


( PO pulls from contributor. )
[master] <----- [pre] <== [ C1 ]
/ <== [ C2 ]
/ <== [ C3 ]
testing happens <== [ C4 ]
here


just some ideas and reasons that i differentiate the amount of involvement here.

ps: also i'm not sure but i think github and other free services do not provide user restrictions. which means that any contributor can push to "master", which imho will result in the same politics as a SVN repository. (i.e. you are *not allowed* to commit to the "master" or "pre").

--

[schwa]

imho will result in the same politics as a SVN repository

I don't think there's any avoiding the politics question -- whether through specific design or lack of it, the repo will have some political structure, somewhere between benevolent dictatorship/junta and anarchy.

The advantage of git seems to be more on the user side: individual users of iplug could periodically cherry-pick which master changes they want to merge in, instead of having to continually hand-merge back into their own svn branches (or just ignoring the svn trunk).

In any case, after looking into this, I got interested in switching to git for Cockos' own source repository. The current expectation is that we will switch internally to git sometime in the next couple of months, and after that, place iplug in a public git repository.

[RRokkenAudio]

What do you think about a dsp section. We can add some dsp modules there, obviously simple ones,more complex, if you wanna share ;)

~RR.

[Tale]

The current expectation is that we will switch internally to git sometime in the next couple of months, and after that, place iplug in a public git repository.
Well, that "couple of months" sure went fast. :D
63517

[schwa]

It's not yet a public read/write repository, but if you're an iplug user, it's definitely a good idea to start using it. Soonish we will probably put the iplug part of wdl in a public read/write repository, which will be nearly transparent to you if you are already using the read-only one.