Menu
▾
▴
jsynthlib-devel
|
From: Joe E. <jo...@em...> - 2011-09-02 00:55:03
|
Okay, I think I understand Subversion enough to be dangerous. I'll need to make a branch to upload my refactored version to. All of the branches seem to be named after version numbers, but my understanding is that we can name them anything (like "my_cool_branch"). Should I name it some step forward in version number (like 0.3, perhaps), or name it something like "refactor"? What does the group think is the best way to go on this? Personally, I'd prefer the version number because, 1) I consider this to be a rather significant step forward in the "sorting out" of the mess of classes that is the main JSL codebase (hence, my desire to call it something like v0.3), and 2) it's more in keeping with the current naming convention in the branch folder... so it'll be easier for people to see where it fits in with the rest of the versions. - Joe |
|
From: Vladimir A. <vl...@gm...> - 2011-09-02 01:06:16
|
On 09/01/2011 07:54 PM, Joe Emenaker wrote: > > Okay, I think I understand Subversion enough to be dangerous. > > I'll need to make a branch to upload my refactored version to. All of > the branches seem to be named after version numbers, but my > understanding is that we can name them anything (like "my_cool_branch"). > > Should I name it some step forward in version number (like 0.3, > perhaps), or name it something like "refactor"? What does the group > think is the best way to go on this? Personally, I'd prefer the version > number because, 1) I consider this to be a rather significant step > forward in the "sorting out" of the mess of classes that is the main JSL > codebase (hence, my desire to call it something like v0.3), and 2) it's > more in keeping with the current naming convention in the branch > folder... so it'll be easier for people to see where it fits in with the > rest of the versions. > I like naming branches in more descriptive way, so if someone would browse repository he could get general idea right from top view. Naming towards release is not very descriptive, and the plans for next release are not documented anywhere. I would also suggest somewhat further structuring of branches directory. You can create subdirectories there based on the purpose of branches inside. I could think of three directories: fixes, features, users. Fixes would be for involved bug resolutions. Features for development extensive changes. Users for developers to fiddle with whatever staff the prefer to work at the moment. In such scheme of things you changes would go into features probably. Just my 2 cents Regards, Vladimir |
|
From: frankster <jsy...@te...> - 2011-09-02 12:22:52
|
On 09/02/11 02:06, Vladimir Avdonin wrote: > On 09/01/2011 07:54 PM, Joe Emenaker wrote: >> Okay, I think I understand Subversion enough to be dangerous. >> >> I'll need to make a branch to upload my refactored version to. All of >> the branches seem to be named after version numbers, but my >> understanding is that we can name them anything (like "my_cool_branch"). >> >> Should I name it some step forward in version number (like 0.3, >> perhaps), or name it something like "refactor"? What does the group >> think is the best way to go on this? Personally, I'd prefer the version >> number because, 1) I consider this to be a rather significant step >> forward in the "sorting out" of the mess of classes that is the main JSL >> codebase (hence, my desire to call it something like v0.3), and 2) it's >> more in keeping with the current naming convention in the branch >> folder... so it'll be easier for people to see where it fits in with the >> rest of the versions. >> > I like naming branches in more descriptive way, so if someone would > browse repository he could get general idea right from top view. > > Naming towards release is not very descriptive, and the plans for next > release are not documented anywhere. > > I would also suggest somewhat further structuring of branches directory. > You can create subdirectories there based on the purpose of branches > inside. I could think of three directories: fixes, features, users. > > Fixes would be for involved bug resolutions. > > Features for development extensive changes. > > Users for developers to fiddle with whatever staff the prefer to work at > the moment. > > In such scheme of things you changes would go into features probably. > > Just my 2 cents > > Regards, > Vladimir > > ------------------------------------------------------------------------------ > Special Offer -- Download ArcSight Logger for FREE! > Finally, a world-class log management solution at an even better > price-free! And you'll get a free "Love Thy Logs" t-shirt when you > download Logger. Secure your free ArcSight Logger TODAY! > http://p.sf.net/sfu/arcsisghtdev2dev > _______________________________________________ > Jsynthlib-devel mailing list > Jsy...@li... > https://lists.sourceforge.net/lists/listinfo/jsynthlib-devel I agree with Vladimir that without a release plan there's no point naming your branch after a release! But when we do decide to do a release, normally that's the point at which we will probably be taking a copy of the trunk into a branch named after the release. Then typically you might let that stabilise for a bit and fix any bugs before making it publicly available. Vladimir's suggestion of creating a "users" subdirectory of branches is a good one and that directory can contain branches for any old stuff that people are working on, or want to share with others before it gets committed into the trunk. Generally it will be tidier if the historic release branches are stored in a separate place to any short term branches that people might be working on. But on the subject of release plans, how have releases been decided in the past? What triggers them? Who has done them? How is it decided when they're ready? It seems to me that as there are several extra synths supported since version 0.20, it would be worth getting some kind of release out (perhaps alpha quality / unstable version), so that people can make use of the work people have done over the last 6 years! And you never know, it might attract a bit more interest in the project as well. frankie |
|
From: Joachim <li...@sd...> - 2011-09-02 16:25:19
|
Hi, > I could think of three directories: fixes, features, users. Normally branches are made for different releases. I don't see a benefit in these three suggested branches as bug fixes have to be merged with new features anyway. The users branch is a concept I didn't get. trunk is the somehow the main branch. If we would develop a 0.3 release this would normally happen in the trunk. If we decide to make bugfixes for 0.20 a bugfix branch should created from the trunk before the development for 0.3 begins. It could e.g. be named rel_0_20_patches/. A new 0.20 release with bugfixes would then be called 0.20.1 and tagged rel_0_20_1. This tagged release can then be found in the tags folder. So branches are there to be able to work parallel on two different releases. Or to experiment. If the experiment is successful it can then be merged with the trunk. An experimental refactoring branch could eg be called 'refactoring_for_0_3' so that the purpose is clear. Remember that you can always jump back to a specific revision so a refactoring can also directly be done in the main branch aka trunk. Cheers Joachim Am 02.09.2011 14:22, schrieb frankster: > > On 09/02/11 02:06, Vladimir Avdonin wrote: >> On 09/01/2011 07:54 PM, Joe Emenaker wrote: >>> Okay, I think I understand Subversion enough to be dangerous. >>> >>> I'll need to make a branch to upload my refactored version to. All of >>> the branches seem to be named after version numbers, but my >>> understanding is that we can name them anything (like "my_cool_branch"). >>> >>> Should I name it some step forward in version number (like 0.3, >>> perhaps), or name it something like "refactor"? What does the group >>> think is the best way to go on this? Personally, I'd prefer the version >>> number because, 1) I consider this to be a rather significant step >>> forward in the "sorting out" of the mess of classes that is the main JSL >>> codebase (hence, my desire to call it something like v0.3), and 2) it's >>> more in keeping with the current naming convention in the branch >>> folder... so it'll be easier for people to see where it fits in with the >>> rest of the versions. >>> >> I like naming branches in more descriptive way, so if someone would >> browse repository he could get general idea right from top view. >> >> Naming towards release is not very descriptive, and the plans for next >> release are not documented anywhere. >> >> I would also suggest somewhat further structuring of branches directory. >> You can create subdirectories there based on the purpose of branches >> inside. I could think of three directories: fixes, features, users. >> >> Fixes would be for involved bug resolutions. >> >> Features for development extensive changes. >> >> Users for developers to fiddle with whatever staff the prefer to work at >> the moment. >> >> In such scheme of things you changes would go into features probably. >> >> Just my 2 cents >> >> Regards, >> Vladimir >> >> ------------------------------------------------------------------------------ >> Special Offer -- Download ArcSight Logger for FREE! >> Finally, a world-class log management solution at an even better >> price-free! And you'll get a free "Love Thy Logs" t-shirt when you >> download Logger. Secure your free ArcSight Logger TODAY! >> http://p.sf.net/sfu/arcsisghtdev2dev >> _______________________________________________ >> Jsynthlib-devel mailing list >> Jsy...@li... >> https://lists.sourceforge.net/lists/listinfo/jsynthlib-devel > > I agree with Vladimir that without a release plan there's no point > naming your branch after a release! But when we do decide to do a > release, normally that's the point at which we will probably be taking a > copy of the trunk into a branch named after the release. Then typically > you might let that stabilise for a bit and fix any bugs before making it > publicly available. > > Vladimir's suggestion of creating a "users" subdirectory of branches is > a good one and that directory can contain branches for any old stuff > that people are working on, or want to share with others before it gets > committed into the trunk. Generally it will be tidier if the historic > release branches are stored in a separate place to any short term > branches that people might be working on. > > But on the subject of release plans, how have releases been decided in > the past? What triggers them? Who has done them? How is it decided when > they're ready? > > It seems to me that as there are several extra synths supported since > version 0.20, it would be worth getting some kind of release out > (perhaps alpha quality / unstable version), so that people can make use > of the work people have done over the last 6 years! And you never know, > it might attract a bit more interest in the project as well. > > frankie > > ------------------------------------------------------------------------------ > Special Offer -- Download ArcSight Logger for FREE! > Finally, a world-class log management solution at an even better > price-free! And you'll get a free "Love Thy Logs" t-shirt when you > download Logger. Secure your free ArcSight Logger TODAY! > http://p.sf.net/sfu/arcsisghtdev2dev > _______________________________________________ > Jsynthlib-devel mailing list > Jsy...@li... > https://lists.sourceforge.net/lists/listinfo/jsynthlib-devel > |
|
From: Vladimir A. <vl...@gm...> - 2011-09-02 16:43:46
|
On 09/02/2011 11:25 AM, Joachim wrote: > Hi, > > > I could think of three directories: fixes, features, users. > > Normally branches are made for different releases. I don't see > a benefit in these three suggested branches as bug fixes have to > be merged with new features anyway. The users branch is a concept > I didn't get. > Oh, those are not branches themselves, those would be just directories to organize branches of similar purpose together. Probably use examples would help to justify. Fixes is easy one - each branch in there could be for an accepted bug in bug tracker. It would leave there until the fix is tested and accepted at which point changes merge to trunk and branch is deleted. Feature is also more or less clear. Say a major feature effort is undertaken, like adding visual themes for example. Several people would work on that, and it might be not clear at start towards what release it will be targeted, or even when it would be completed. And at the beginning it probably would break everything in the project. It will eventually be implemented at which point it would merge to either trunk, or pre-release brunch, and changes will be deleted. For users I would illustrate it like this - suppose I got some stupid idea that i am not even sure it make sense, but I want to try it anyway. Like, say, adding sequencer. It would not fit in features in my view, because not everyone would agree that the project needs such feature at all. The features would have only agreed lines of development. Users are free to put anything in their personal branches. The advantage would be capturing any potentially useful development. Anyway, this all is just suggestion. I would not insist on any -- Vladimir |
|
From: Joachim <li...@sd...> - 2011-09-02 16:57:31
|
Ah, I don't think it makes sense to make a branch for every bug. > and it might be not clear at start towards what release it > will be targeted The target release is not a problem if the development takes place in the trunk. > it probably would break everything in the project Remember: We can always go back and only working code should be checked in, so the mess up shouldn't be too much anyway. I don't see a big danger there. > suppose I got some stupid > idea that i am not even sure it make sense Develop it lokally and ask the list if it shall be added or not. I would ask prior to putting any effort in it. ;) Such a concept would only complicate the development process in my eyes and I still don't see a benefit. Cheers Joachim Am 02.09.2011 18:43, schrieb Vladimir Avdonin: > On 09/02/2011 11:25 AM, Joachim wrote: >> Hi, >> >> > I could think of three directories: fixes, features, users. >> >> Normally branches are made for different releases. I don't see >> a benefit in these three suggested branches as bug fixes have to >> be merged with new features anyway. The users branch is a concept >> I didn't get. >> > > Oh, those are not branches themselves, those would be just directories > to organize branches of similar purpose together. > > Probably use examples would help to justify. > > Fixes is easy one - each branch in there could be for an accepted bug in > bug tracker. It would leave there until the fix is tested and accepted > at which point changes merge to trunk and branch is deleted. > > Feature is also more or less clear. Say a major feature effort is > undertaken, like adding visual themes for example. Several people would > work on that, and it might be not clear at start towards what release it > will be targeted, or even when it would be completed. And at the > beginning it probably would break everything in the project. It will > eventually be implemented at which point it would merge to either trunk, > or pre-release brunch, and changes will be deleted. > > For users I would illustrate it like this - suppose I got some stupid > idea that i am not even sure it make sense, but I want to try it anyway. > Like, say, adding sequencer. It would not fit in features in my view, > because not everyone would agree that the project needs such feature at > all. The features would have only agreed lines of development. Users are > free to put anything in their personal branches. The advantage would be > capturing any potentially useful development. > > Anyway, this all is just suggestion. I would not insist on any > |
|
From: Vladimir A. <vl...@gm...> - 2011-09-02 17:13:22
|
On 09/02/2011 11:57 AM, Joachim wrote: > Ah, I don't think it makes sense to make a branch for every bug. Not every bug, just complicated ones, involving non-obvious changes and requiring extensive testing > > > and it might be not clear at start towards what release it > > will be targeted > > The target release is not a problem if the development takes place > in the trunk. Well, I have different phylosophy - I believe no development shall happen trunk, it shall stay clean and functional at any moment. The only commits that shall go there should be from tested working branch. This way any parallel developments that happen on branches will not break each others during syncing with trunk. > > > it probably would break everything in the project > > Remember: We can always go back and only working code should be > checked in, so the mess up shouldn't be too much anyway. > I don't see a big danger there. What if we do not want to go back? Breaking up things is inevitable in process of changing. And broken period can take extended time. > > > suppose I got some stupid > > idea that i am not even sure it make sense > > Develop it lokally and ask the list if it shall be added or not. > I would ask prior to putting any effort in it.;) And like is said, what if there will be no common agreement in the list? Start voting? I do not think we should limit peoples creativity with democracy > > Such a concept would only complicate the development process in my eyes > and I still don't see a benefit. I think I would rest my case here. Whatever goes -- Vladimir |
|
From: Joachim <li...@sd...> - 2011-09-02 17:55:59
|
> it shall stay clean and functional at any moment. If only clean stuff is commited this would still be possible. > What if we do not want to go back? Breaking up things is inevitable in > process of changing. And broken period can take extended time. We could still use a refactoring branch. > And like is said, what if there will be no common agreement in the list? > Start voting? I do not think we should limit peoples creativity with > democracy If that is the case we can still think about a solution like yours. Anyway: How would you fit this into the project. > I think I would rest my case here. I'm just expressing my opinion like you are. I'm not the dictator of JSynthLib or something like that. Cheers Joachim Am 02.09.2011 19:13, schrieb Vladimir Avdonin: > On 09/02/2011 11:57 AM, Joachim wrote: >> Ah, I don't think it makes sense to make a branch for every bug. > > Not every bug, just complicated ones, involving non-obvious changes and > requiring extensive testing > >> >> > and it might be not clear at start towards what release it >> > will be targeted >> >> The target release is not a problem if the development takes place >> in the trunk. > > Well, I have different phylosophy - I believe no development shall > happen trunk, it shall stay clean and functional at any moment. The only > commits that shall go there should be from tested working branch. > > This way any parallel developments that happen on branches will not > break each others during syncing with trunk. > >> >> > it probably would break everything in the project >> >> Remember: We can always go back and only working code should be >> checked in, so the mess up shouldn't be too much anyway. >> I don't see a big danger there. > > What if we do not want to go back? Breaking up things is inevitable in > process of changing. And broken period can take extended time. > >> >> > suppose I got some stupid >> > idea that i am not even sure it make sense >> >> Develop it lokally and ask the list if it shall be added or not. >> I would ask prior to putting any effort in it.;) > > And like is said, what if there will be no common agreement in the list? > Start voting? I do not think we should limit peoples creativity with > democracy > >> >> Such a concept would only complicate the development process in my eyes >> and I still don't see a benefit. > > I think I would rest my case here. Whatever goes > |
|
From: William Z. <wrz...@po...> - 2011-09-02 21:06:10
|
On Fri, Sep 2, 2011 at 10:13 AM, Vladimir Avdonin <vl...@gm...> wrote: > Well, I have different phylosophy - I believe no development shall > happen trunk, it shall stay clean and functional at any moment. The only > commits that shall go there should be from tested working branch. > ... > What if we do not want to go back? Breaking up things is inevitable in > process of changing. And broken period can take extended time. > Your suggestions are good for a large and highly active project staffed with professional engineers. But many of the people contributing to JSL are amateurs, and only contribute for a short period of time before moving on. We want a system that maximizes *their* productivity, and ensures their changes make it into trunk. Also bear in mind, I believe that this current burst of activity will fade to nothing. It always happened in the past, so I must assume it will happen again. With that in mind, I want a system that maximizes the productivity of this current group of contributors before they leave, and also leaves JSL in a clear and obvious state for the next group when they pick it up in a year or two. Thus I believe the simplest solution is the best for JSL. And the simplest solution is to simply encourage everyone to contribute directly to trunk. This will increase the chances that someone will damage the code, but I believe the risk of damage is insignificant to the advantages of getting everyone's code into trunk where it is immediately useable. -Bill Zwicky |
|
From: Joe E. <jo...@em...> - 2011-09-02 14:39:06
|
On 9/2/2011 5:22 AM, frankster wrote: > It seems to me that as there are several extra synths supported since > version 0.20, it would be worth getting some kind of release out > (perhaps alpha quality / unstable version), so that people can make use > of the work people have done over the last 6 years! And you never know, > it might attract a bit more interest in the project as well. Once I finish this refactor, the next thing I want to set to work on is making it so that drivers can be loaded as plugins. This will allow us to *not* have to make a new release of JSL in order to get a new driver out to the world. This brings up two questions: 1 - Will we want to manage the source for JSL and the drivers *separately* at that point? Would we have a branch for every driver, or have a branch for *all* of the drivers? Or is there a better way to do this than to use branches? 2 - How do we want to *distribute* the drivers? What I'm getting at here is that I think Brian still has control over jsynthlib.org, but he's hardly ever here, so I think there's little chance of us being able to store the drivers on his server. Do we want to store them on SourceForge? Do we want to store them on my server or someone else's? If we store it on someone's server, do we want to use some descriptive domain name (like jsldrivers.org or something)? - Joe |
|
From: Vladimir A. <vl...@gm...> - 2011-09-02 14:59:37
|
On 09/02/2011 09:38 AM, Joe Emenaker wrote: > 1 - Will we want to manage the source for JSL and the drivers > *separately* at that point? Would we have a branch for every driver, or > have a branch for*all* of the drivers? Or is there a better way to do > this than to use branches? I would think synthdrivers would move to the top level of repository and each driver will get its own build.xml. Whether to use branches in development would be up to maintainer of each driver. I just took a look at jedit repository structure, they actually have trunk, branches and tags inside each individual plugin folder. That probably make much sense, as each plugin can be project on its own, can be taken straight to different repository, or brought to SF repo from outside > 2 - How do we want to*distribute* the drivers? What I'm getting at here > is that I think Brian still has control over jsynthlib.org, but he's > hardly ever here, so I think there's little chance of us being able to > store the drivers on his server. Do we want to store them on > SourceForge? Do we want to store them on my server or someone else's? If > we store it on someone's server, do we want to use some descriptive > domain name (like jsldrivers.org or something)? I would think in the application itself that shall be made user configurable through preferences. That way independent developers would be able to publish their drivers on their own websites. As for how to handle the projects repository, I donno, maybe that is too early to ask this question. Hey, please do not hide you development. The branch does not need to be tidy and compilable. You could dump your work in progress freely on it. This way other developers would be able to plug in early. I for one is looking forward to get into this development. Looks exciting -- Vladimir |
|
From: William Z. <wrz...@po...> - 2011-09-03 00:26:41
|
On Fri, Sep 2, 2011 at 7:59 AM, Vladimir Avdonin <vl...@gm...> wrote: > Hey, please do not hide you development. The branch does not need to be > tidy and compilable. You could dump your work in progress freely on it. > This way other developers would be able to plug in early. I for one is > looking forward to get into this development. Looks exciting > When you put it that way, it makes excellent sense. In fact, I'm now having trouble figuring out the value of checking the new JSynthLib into trunk on top of the old one. If that much stuff has changed, maybe you should just put it under trunk/JSynthLib3, and we'll flag the old one as deprecated. Also, my pet peeve is having all the source code directly under the root directory. I prefer to keep my source under a "src" sub-dir. How much longer will it take to make the new version ready for checkin? If it'll be a while, could you shoot me a copy to look at? -Bill Zwicky |
|
From: Joe E. <jo...@em...> - 2011-09-03 01:24:00
|
On 09/02/2011 10:13 AM, Vladimir Avdonin wrote: > Well, I have different phylosophy - I believe no development shall > happen trunk, it shall stay clean and functional at any moment. That sounds like you're saying that, at all times, checking out from trunk should give you a release. That's different from how I've heard revision-control systems described in the past. Basically, the story I usually hear is: 1 - Trunk is dynamic, and always in flux. *Most* of the time, compiling from trunk will give you an application with bugs or half-implemented features. But trunk *should* compile without errors, generally. Bugs, where things in the successfully-compiled application don't work quite right, those are okay. 2 - When a release is coming up on a quiet or small project (let's call it 2.0), the devs can issue a feature-freeze and focus only on bug fixes in trunk until a release is made. Then, a tag is created for that release, and then work can begin on the new round of features in the next version (3.0). This method doesn't allow for issuing bug fixes for older versions, however. If an end user wants a bug fixed, they have to wait for the next release. Fine for small projects. 3 - If there's the need to issue bug fixes for past releases, then you need to branch, and you've got two options: 3a) Branch off 2.0 and let bug-fixing happen there while new features and development toward 3.0 happen in trunk. 3b) Branch off a copy of trunk for work on 3.0, while the bug fixes for 2.0 happen in trunk. When 2.0 is released, a tag is made for the current state of trunk, and then the 3.0 branch is merged back into trunk, and then the 3.0 branch can be deleted. I think 3a is a much better way to go than 3b, for the following reasons: - With 3b, all of the devs need to be told (and they have to remember) when the purpose of trunk changes. For example, when there's a feature-freeze, they all need to be told "bug fixes only in trunk until further notice". Then, when 2.0 gets released, they must be told that new features can now be introduced into trunk again. 3a avoids this; trunk always is the place for new features and bug-fixes which aren't version-specific. - 3a doesn't require any merging of branches. Merging always brings the possibility of conflicts, so it's nice when they can be avoided. - 3b doesn't really allow for bug fixes to previous versions. If you merge the 3.0 code back into trunk and then want to make a 2.01, what do you do? If you branch off the 2.0 revision of trunk to work on it separately, then you're basically doing the 3a method, so why not just start off that way? So, if it were up to me, I'd branch releases (and only if there were going to be bug-fix work on old releases. If not, just make tags) and keep trunk "cutting edge". The only other time I'd make a branch is when there's some major development to be done which is going to make things *not compile* properly. If that happens in trunk, then other devs can't test their changes, so that needs to be avoided. - Joe |
|
From: William Z. <wrz...@po...> - 2011-09-03 03:14:34
|
On Fri, Sep 2, 2011 at 6:23 PM, Joe Emenaker <jo...@em...> wrote: > 3a) Branch off 2.0 and let bug-fixing happen there while new features > and development toward 3.0 happen in trunk. > 3b) Branch off a copy of trunk for work on 3.0, while the bug fixes > for 2.0 happen in trunk. When 2.0 is released, a tag is made for the > current state of trunk, and then the 3.0 branch is merged back into > trunk, and then the 3.0 branch can be deleted. > Nice thing about Subversion is that there is no difference between "tags" and "branches". Each is a copy of the repository as of some point in time. Or more precisely, *a* repository, since you can make branches off of other branches. Or branches from tags. Or tags from branches. You can check out a tag, then commit changes as if it was a branch. Because it *is* a branch. So /trunk is nothing more than the "blessed branch". And the difference between /tags and /branches is entirely political, and not at all technical. In general, /tags is mean to hold *past* states of the system (i.e. we branch /trunk to form /tags/release_20, then continue development on /trunk). And /branches is mean to hold *future* states of the system (i.e. we continue updating drivers under /trunk, while Joe builds his new version under /branches/emenaker_refactor). And 3a is the best simply because one should stay away from merging wherever possible. And it's pretty much free, since it's always good to create a tag for every version that is released. -Bill Zwicky |
|
From: frankster <jsy...@te...> - 2011-09-03 13:55:51
|
On 09/03/11 04:14, William Zwicky wrote: > > And 3a is the best simply because one should stay away from merging wherever > possible. And it's pretty much free, since it's always good to create a tag > for every version that is released. > Or use mercurial/git because they do a slightly better job of merging ;) frankie |
|
From: William Z. <wrz...@po...> - 2011-09-03 09:16:59
|
On Fri, Sep 2, 2011 at 6:55 PM, Joe Emenaker <jo...@em...> wrote: > Well, it seems a little silly to me that we would need to make a new > release number any time someone makes a new driver. > Really? It's seems silly to me to make the user rummage around either SourceForge or a custom GUI for what amounts to a tiny download, and then they need to do this repeatedly if they have several synths. With an integrated download, they get the latest core, and ALL the latest synths at once. > Also, I just looked at the disk usage for my latest checkout of trunk, > and the "core" package takes about 1MB while "synthdrivers" takes almost > 6MB. So, most of the space and compile-time is going into the > synthdrivers, and most users only need one or two of those. Just seems > like a lot of waste. > Well then it's time to upgrade your 486. 6MB is not worth worrying about, even on an SSD. User time is more precious than disk space. > But at this point, we have much bigger fish to > > fry. > > Like? Do you mean bug-reports and feature-requests in the tracker, or do > you have other stuff in mind? > I'll admit, the list is pretty short. * Release 0.21. * Sweep up outstanding bugs and patches. * Release 0.22. * Emenaker's Grand Refactoring. * Release 0.30. I view all of those as more important than the plugin system. -Bill Zwicky |
|
From: Vladimir A. <vl...@gm...> - 2011-09-03 12:37:37
|
On 09/03/2011 04:16 AM, William Zwicky wrote: >> Well, it seems a little silly to me that we would need to make a new >> > release number any time someone makes a new driver. >> > > Really? It's seems silly to me to make the user rummage around either > SourceForge or a custom GUI for what amounts to a tiny download, and then > they need to do this repeatedly if they have several synths. With an > integrated download, they get the latest core, and ALL the latest synths at > once. > > This would allow anyone outside the project release drivers to public easily. This would allow any user that can not or does not want to build himself to use binary drivers from any source. This would allow anyone to use any version of driver with any version of application, without being forced to upgrade everything when wanting to upgrade just one. It is all about freedom of choice really. -- Vladimir |
|
From: frankster <jsy...@te...> - 2011-09-03 13:56:10
|
On 09/03/11 10:16, William Zwicky wrote: > > I'll admit, the list is pretty short. > * Release 0.21. > * Sweep up outstanding bugs and patches. > * Release 0.22. > * Emenaker's Grand Refactoring. > * Release 0.30. This "Release Plan" sounds goods to me. frankie |
|
From: Joe E. <jo...@em...> - 2011-09-03 14:39:10
|
On 9/3/2011 2:16 AM, William Zwicky wrote: > On Fri, Sep 2, 2011 at 6:55 PM, Joe Emenaker<jo...@em...> wrote: >> Well, it seems a little silly to me that we would need to make a new >> release number any time someone makes a new driver. > Really? It's seems silly to me to make the user rummage around either > SourceForge or a custom GUI for what amounts to a tiny download, and then > they need to do this repeatedly if they have several synths. With an > integrated download, they get the latest core, and ALL the latest synths at > once. Well, that's a fair concern. I don't necessarily think we should release the core *without* any drivers. I just think we should be able to release new drivers without having to do another release. I'm thinking kind of how MIDI Quest does it, where a large part of the driver set is included, but they're always adding more to the website. Also, they don't necessarily have to go rummaging, either. With the MIDI inquiry feature, we could have JSL query a synth, get an ID string back, and then magically grab that over the net for the user. >> Also, I just looked at the disk usage for my latest checkout of trunk, >> and the "core" package takes about 1MB while "synthdrivers" takes almost >> 6MB. So, most of the space and compile-time is going into the >> synthdrivers, and most users only need one or two of those. Just seems >> like a lot of waste. >> > Well then it's time to upgrade your 486. 6MB is not worth worrying about, > even on an SSD. User time is more precious than disk space. Well, I was using the space as quantifiable evidence that the codebase is so heavily skewed toward synthdrivers... by a factor of about 6:1. So, svn checkouts take 7x as long, making an archive of the code takes 7x as long... etc. Every time I zip, unzip, or checkout a copy of the code, "core" goes by pretty fast, and then I get to watch this endless string of synths where I'm thinking "Wow... look at all of these synths that I've never owned, never *will* own, and don't even know what they look like... good thing I've got drivers for 'em...". And this lopsidedness is just going to get more-lopsided. Also, it just irks me that we have to generate a synthdrivers.properties file any time a driver is added. The ".properties" system is just so... yucky. JSL should be able to quickly and dynamically find all of its drivers by itself. - Joe |
|
From: frankster <jsy...@te...> - 2011-09-04 11:24:20
|
On 09/03/11 15:38, Joe Emenaker wrote: > Well, I was using the space as quantifiable evidence that the codebase > is so heavily skewed toward synthdrivers... by a factor of about 6:1. > So, svn checkouts take 7x as long, making an archive of the code takes > 7x as long... etc. Every time I zip, unzip, or checkout a copy of the > code, "core" goes by pretty fast, and then I get to watch this endless > string of synths where I'm thinking "Wow... look at all of these synths > that I've never owned, never *will* own, and don't even know what they > look like... good thing I've got drivers for 'em...". And this > lopsidedness is just going to get more-lopsided. Although in the jar that people download its about 1.5Mb for groovy and a few hundred k for JSL including all drivers IIRC. so wierdly its lopsided in the other direction as far as users are concerned. > > Also, it just irks me that we have to generate a synthdrivers.properties > file any time a driver is added. The ".properties" system is just so... > yucky. JSL should be able to quickly and dynamically find all of its > drivers by itself. Yeah you could imagine a nice web service which accepts a device query string and then provides a list of one or more drivers that claim to support it. Although the downside on this is that it would require that a server was maintained, and I notice that the patch upload website's search box doesn't work. So relying on a web service possibly isn't something that this project has historically been good at? |
|
From: William Z. <wrz...@po...> - 2011-09-03 00:18:20
|
On Fri, Sep 2, 2011 at 7:38 AM, Joe Emenaker <jo...@em...> wrote: > Once I finish this refactor, the next thing I want to set to work on is > making it so that drivers can be loaded as plugins. This will allow us > to *not* have to make a new release of JSL in order to get a new driver > out to the world. > Who would such a thing serve? The core JSL group doesn't need it, since we can post a new release with the changes. Outside developers probably won't use it, because we're still version 0.x, and serious developers will need to overhaul the core to meet their needs. That said, a plugin system is not a *bad* thing; it will get us thinking about stabilizing the API. But at this point, we have much bigger fish to fry. > 1 - Will we want to manage the source for JSL and the drivers > *separately* at that point? Would we have a branch for every driver, or > have a branch for *all* of the drivers? Or is there a better way to do > this than to use branches? > We already have trunk/JSynthLib, so: trunk/drivers/default would build a single plugin containing the current set of drivers. trunk/drivers/* would be for developers who have access to JSL's subversion, but want to maintain their driver separately. For external developers, they can keep their source wherever they want. > 2 - How do we want to *distribute* the drivers? What I'm getting at here > is that I think Brian still has control over jsynthlib.org, but he's > hardly ever here, so I think there's little chance of us being able to > store the drivers on his server. Do we want to store them on > SourceForge? Do we want to store them on my server or someone else's? If > we store it on someone's server, do we want to use some descriptive > domain name (like jsldrivers.org or something)? > Primary distribution point will be SourceForge for our drivers. For external drivers, the external devs will need to arrange hosting initially. If JSL becomes big and popular, then we can consider building a "3rd Party Drivers" page on jsynthlib.org. If we (or Brian) can't update jsynthlib.org, then we'd be better off with a new product name and domain rather than something silly like jsldrivers.org. -Bill Zwicky |
|
From: Joe E. <jo...@em...> - 2011-09-03 01:55:58
|
On 09/02/2011 05:18 PM, William Zwicky wrote: > On Fri, Sep 2, 2011 at 7:38 AM, Joe Emenaker<jo...@em...> wrote: >> Once I finish this refactor, the next thing I want to set to work on is >> making it so that drivers can be loaded as plugins. This will allow us >> to *not* have to make a new release of JSL in order to get a new driver >> out to the world > Who would such a thing serve? The core JSL group doesn't need it, since we > can post a new release with the changes. Well, it seems a little silly to me that we would need to make a new release number any time someone makes a new driver. Also, I just looked at the disk usage for my latest checkout of trunk, and the "core" package takes about 1MB while "synthdrivers" takes almost 6MB. So, most of the space and compile-time is going into the synthdrivers, and most users only need one or two of those. Just seems like a lot of waste. > That said, a plugin system is not a *bad* thing; it will get us thinking > about stabilizing the API. But at this point, we have much bigger fish to > fry. Like? Do you mean bug-reports and feature-requests in the tracker, or do you have other stuff in mind? - Joe |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X