hi all.
i would really like to have the diffs back in the pd-cvs mails.
as i see it, the current pd-cvs is only useful if you want to track build-fails of the auto-build machines. it has rather little to do with repository commits (any more). i would like to get the old behaviour back.
if nobody objects (with plausible reasons), i will change the settings to the original ones in a few days.
fgasdr, IOhannes
The occasional >1meg emails from big commits are kind of a pain, like when doing an import or merge. It was nice to have immediate access to scan the diffs for sure. But the web interface to the diffs is a lot more useful. Ideally, there would be a size cutoff for the diffs, like 50k or something.
If you really want it, I can deal with it again...
.hc
On May 11, 2009, at 7:12 AM, IOhannes m zmoelnig wrote:
hi all.
i would really like to have the diffs back in the pd-cvs mails.
as i see it, the current pd-cvs is only useful if you want to track build-fails of the auto-build machines. it has rather little to do with repository commits (any more). i would like to get the old behaviour back.
if nobody objects (with plausible reasons), i will change the settings to the original ones in a few days.
fgasdr, IOhannes _______________________________________________ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
----------------------------------------------------------------------------
"[W]e have invented the technology to eliminate scarcity, but we are deliberately throwing it away to benefit those who profit from scarcity." -John Gilmore
Hans-Christoph Steiner wrote:
The occasional >1meg emails from big commits are kind of a pain, like when doing an import or merge. It was nice to have immediate access to scan the diffs for sure. But the web interface to the diffs is a lot more useful. Ideally, there would be a size cutoff for the diffs, like 50k or something.
If you really want it, I can deal with it again...
no problem, i can deal with it as well :-)
as for the sizes: i guess i have pointed out in an earlier mail, that i personally think, that source-files should not contain (excessive) data. e.g. HRTFs (this was the main reason, wasn't it?) are _much_ better stored in soundfiles than in header-files. inappropriate use should not keep use from having features.
as for the pain: no one is obliged to subscribing to pd-cvs. those who want to stay up-to-date on a short notice, can use IRC for that (i guess there are some filtering options, where you can tell your client to just display the cia-bot messages)
finally, if you opt to receive pd-cvs in non-digest mode, you can select whether you want to receive emails of all topics, or only of topic "autobuild" or only of topic "CVS". since i don't know of anybody using this feature (iirc, it was a feature request by tim), i don't know whether it actually works, so take care :-)
fmga,.sdr IOhannes
On May 12, 2009, at 5:19 AM, IOhannes m zmoelnig wrote:
Hans-Christoph Steiner wrote:
The occasional >1meg emails from big commits are kind of a pain, like when doing an import or merge. It was nice to have immediate access to scan the diffs for sure. But the web interface to the diffs is a lot more useful. Ideally, there would be a size cutoff for the diffs, like 50k or something. If you really want it, I can deal with it again...
no problem, i can deal with it as well :-)
as for the sizes: i guess i have pointed out in an earlier mail, that i personally think, that source-files should not contain (excessive) data. e.g. HRTFs (this was the main reason, wasn't it?) are _much_ better stored in soundfiles than in header-files. inappropriate use should not keep use from having features.
If I import code into the 'sources' tree (for Windows), then all of that code will be sent to pd-cvs. I think the same goes for a merge. That's a lot of email.
.hc
as for the pain: no one is obliged to subscribing to pd-cvs. those who want to stay up-to-date on a short notice, can use IRC for that (i guess there are some filtering options, where you can tell your client to just display the cia-bot messages)
finally, if you opt to receive pd-cvs in non-digest mode, you can select whether you want to receive emails of all topics, or only of topic "autobuild" or only of topic "CVS". since i don't know of anybody using this feature (iirc, it was a feature request by tim), i don't know whether it actually works, so take care :-)
fmga,.sdr IOhannes
----------------------------------------------------------------------------
You can't steal a gift. Bird gave the world his music, and if you can hear it, you can have it. - Dizzy Gillespie
Hans-Christoph Steiner wrote:
better stored in soundfiles than in header-files. inappropriate use should not keep use from having features.
If I import code into the 'sources' tree (for Windows), then all of that code will be sent to pd-cvs.
well, how many packages do you plan to import in the next few years? apart from that, in theory i could setup a filter in the mailing-list that will not let through commits to /sources
I think the same goes for a merge. That's a lot of email.
which merges are you talking about? i cannot think of one that will generate "a lot of email" now.
mfga.sr IOhannes
On May 12, 2009, at 12:50 PM, IOhannes m zmoelnig wrote:
Hans-Christoph Steiner wrote:
better stored in soundfiles than in header-files. inappropriate use should not keep use from having features.
If I import code into the 'sources' tree (for Windows), then all of that code will be sent to pd-cvs.
well, how many packages do you plan to import in the next few years? apart from that, in theory i could setup a filter in the mailing- list that will not let through commits to /sources
August and I have been working to get gavl and gmerlin-avdecoder and all the relevant libs building on Windows so that readanysf~ and Gem can use them on all platforms. That means these libs still need to be imported:
ffmpeg faac faad2 gmerlin-avdecoder gavl
There are probably others that I am forgetting. By the way, this turns out to be a pretty big task. We have made some substantial progress, and August has gotten mingw fixes checked in for gavl and gmerlin-avdec. But its too big for the two of us right now. If we could get some help, then this is much more likely to happen. readanysf~ is really working well now on Mac OS X, where all the libs are in Fink now. Debian still lacks gmerlin-avdec, I haven't checked Fedora.
I think the same goes for a merge. That's a lot of email.
which merges are you talking about? i cannot think of one that will generate "a lot of email" now.
Like merging Pd-extended 0.41.4 and Pd-vanilla 0.42.5
.hc
mfga.sr IOhannes
----------------------------------------------------------------------------
If nature has made any one thing less susceptible than all others of exclusive property, it is the action of the thinking power called an idea, which an individual may exclusively possess as long as he keeps it to himself; but the moment it is divulged, it forces itself into the possession of everyone, and the receiver cannot dispossess himself of it. - Thomas Jefferson
Hans-Christoph Steiner wrote:
I think the same goes for a merge. That's a lot of email.
which merges are you talking about? i cannot think of one that will generate "a lot of email" now.
Like merging Pd-extended 0.41.4 and Pd-vanilla 0.42.5
i don't think this is more than a "pretty active" developer would generate.
fgamsdr IOhannes
-
Hans-Christoph Steiner -
IOhannes m zmoelnig