There is a bunch of code in the 'externals' section of the CVS that is not maintain there (maxlib, motex, pdogg I think, etc.). So I was thinking that it would make sense to make that code read-only, then make a branch like "devel_0_37" for 'pd', maybe calling it just "devel" or whatever. But I think it would be good to have a standard branch for modification of such code.
This would make it easier to maintain code in the CVS when the creator doesn't want to maintain it in the CVS. Thoughts? Comments?
.hc
Hallo, Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote:
It depends. Sometimes this is one of the advantages of CVs: That someone else can quickly fix a small bug. This doesn't work for Thomas Grill's externals of course, which are overwritten every night, IIRC, but there read-only wouldn't make much sense anyways.
Of the examples you mentioned: I don't know, if maxlib for Pd is still maintained by Olaf.
In othr
Frank Barknecht wrote:
Does posting say anything about maintaining maxlib or any other library / external? - Or to put it the other way round: is 'silence' (i.e. not posting) a sign for not maintaining it? Sorry, I'm a bit confused but I thought it would be okay to just _use_ my code myself instead of trying to maintain something that seems to be working more or less. But maybe I just missed the last 100 bug reports. ;-)
Olaf
On Thursday, Mar 18, 2004, at 12:09 America/New_York, Frank Barknecht wrote:
flext is a great example actually. Say I wanted to do more than just a bug fix, but add a significant feature to a part of flext. I could commit my changes to the 'devel' branch, and still track Thomas' changes. Then when my new feature is implemented to Thomas' satisfaction, he could incorporate it into his CVS. This is what we are already doing with the pd source, so it should work. Since flext, etc. is changing quite a bit, that would mean more merging work, but for something like maxlib, it doesn't change much these days so a branch should be easy to maintain.
.hc
Hi Hans-Christoph, i like this idea very much. I don't think i'm going to implement new features to flext in the near future but rather optimize it and make it work better with Max/MSP (thread-safety, compatibility with overdrive mode, timing problems etc.) - i'd really like to calm down development and work towards a stable API with a shared flext library to allow for small and efficient externals. I'm grateful for any additional ideas (and significant new parts).
best greetings, Thomas