On Feb 27, 2006, at 1:53 PM, Thomas Grill wrote:
Hi Hans-Christoph, i see. In fact, i turned off the automatic mirroring several months ago, so that the SF cvs is updated only when the respective project is under a buildable condition.
Whatever you want to call it, this is exactly what I am talking about. I didn't realize that you had stopped the mirroring. I'd just add that each time you send the files to the pure-data CVS, you increment the version in some fashion. Then it would be a release.
Mirroring releasing only doesn't seem too good to me, since i don't release very often due to the work that is connected to preparing the packages. Fixes made in the meantime wouldn't be available for users in this case.
I don't mean that everyone should mirror the release schedule of Pd- extended. I mean that they should import only stable releases once they are ready. Then Pd-extended will be build with whatever is there. That seems to be the most manageable solution for now.
.hc
greetings, Thomas
As far as I understand it, externals/grill is hosted in your repository, and then every night, it is mirrored to pure-data CVS. I am saying instead of this setup, it would make more sense to import the code from your repository only when you make a release. No one currently uses branches against externals/grill to track changes to that area, so I see now benefit to having it mirrored in pure-data CVS.
Instead, if stable releases were in external/grill, then we would not have to worry about various inevitable development hiccups when building Pd-extended. I think this would also work well with Gem, PDP, and GridFlow, which are also managed in other repositories.
.hc
As we enjoy great advantages from inventions of others, we should be glad of an opportunity to serve others by any invention of ours; and this we should do freely and generously. - Benjamin Franklin
-- Thomas Grill http://grrrr.org
________________________________________________________________________ ____
"Information wants to be free." -Stewart Brand