Hi,
quick question: I'd like to add some newer list-abstractions to pd-extended (don't worry: they are very stable), but I'm not sure what was the branch again I need to add them to: Is it "branched-v0-39-2-extended"? And for future use: Is there some webpage to check out which branch is the branch to add to?
Ciao
"branched-v0-39-2-extended" is the tag of the point where the branch was made. "branch-v0-39-2-extended" (minus "ed) is the branch itself.
For future reference, it's generally not a good idea to add code to a release candidate. It's not just about the stability of the objects themselves, but of the whole package and any possible interactions. I am ok with you adding this stuff now, as long as you are willing to test them on all three platforms, or have people test them.
Otherwise, the Pd-0.40.2-extended builds are a good place for just checking stuff in since those builds will get tested as it nears closer to release.
Last thing, I'd really like to see the release cycle be much quicker, but there would need to be more contributions for that to happen.
.hc
On May 27, 2007, at 3:06 PM, Frank Barknecht wrote:
Hi,
quick question: I'd like to add some newer list-abstractions to pd-extended (don't worry: they are very stable), but I'm not sure what was the branch again I need to add them to: Is it "branched-v0-39-2-extended"? And for future use: Is there some webpage to check out which branch is the branch to add to?
Ciao
Frank Barknecht _ ______footils.org_ __goto10.org__
PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
------------------------------------------------------------------------ ----
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
Hallo, Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote:
"branched-v0-39-2-extended" is the tag of the point where the branch was made. "branch-v0-39-2-extended" (minus "ed) is the branch itself.
For future reference, it's generally not a good idea to add code to a release candidate. It's not just about the stability of the objects themselves, but of the whole package and any possible interactions. I am ok with you adding this stuff now, as long as you are willing to test them on all three platforms, or have people test them.
I'm not able to test them, but it's just some abstractions (though it's 30 files, half of them help-files). It's okay to leave the newer objects out, but I also found, that some bugfixes I made to [list]-abs or RTC-lib are missing. I suppose similar things may also occur in other libraries. (Maybe it would be good to think about splitting pd-extended into smaller packages e.g. one for Pd itself, one for extensions, but of course that's a debatable issue.)
Otherwise, the Pd-0.40.2-extended builds are a good place for just checking stuff in since those builds will get tested as it nears closer to release.
Aren't the autobuilds automatically build from HEAD? Then there would be no need for checking stuff in explicitly.
Ciao
On May 27, 2007, at 6:26 PM, Frank Barknecht wrote:
Hallo, Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote:
"branched-v0-39-2-extended" is the tag of the point where the branch was made. "branch-v0-39-2-extended" (minus "ed) is the branch itself.
For future reference, it's generally not a good idea to add code to a release candidate. It's not just about the stability of the objects themselves, but of the whole package and any possible interactions. I am ok with you adding this stuff now, as long as you are willing to test them on all three platforms, or have people test them.
I'm not able to test them, but it's just some abstractions (though it's 30 files, half of them help-files). It's okay to leave the newer objects out, but I also found, that some bugfixes I made to [list]-abs or RTC-lib are missing. I suppose similar things may also occur in other libraries. (Maybe it would be good to think about splitting pd-extended into smaller packages e.g. one for Pd itself, one for extensions, but of course that's a debatable issue.)
Bug fixes are good right now in the release candidate, new features are not. As far as I know that is the definition of "release candidate", it seems to be standard practice, and it sounds like a good idea to me.
I think it would be a good idea to have most people distribute their libs separately, kind of like how Eclipse plugins are distributed. But there isn't the infrastructure in place yet to do that. The funny thing is that originally, Eclipse plugins were all expected to be distributed separately. But now, there are starting to be Eclipse distros that include lots of plugins that are all tested together as a package.
Otherwise, the Pd-0.40.2-extended builds are a good place for just checking stuff in since those builds will get tested as it nears closer to release.
Aren't the autobuilds automatically build from HEAD? Then there would be no need for checking stuff in explicitly.
The auto-builds are built from the HEAD of MAIN and the head of the release branch everynight. But just because it builds doesn't mean that everything works. Testing is still very much necessary. For example, Gem builds fine on Mac OS X, but currently there is no font/ text support. I consider that a bug that should be fixed.
.hc
Ciao
Frank Barknecht _ ______footils.org_ __goto10.org__
PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
------------------------------------------------------------------------ ----
Man has survived hitherto because he was too ignorant to know how to realize his wishes. Now that he can realize them, he must either change them, or perish. -William Carlos Williams
Hallo, Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote:
On May 27, 2007, at 6:26 PM, Frank Barknecht wrote:
Aren't the autobuilds automatically build from HEAD? Then there would be no need for checking stuff in explicitly.
The auto-builds are built from the HEAD of MAIN and the head of the release branch everynight. But just because it builds doesn't mean that everything works. Testing is still very much necessary.
Of course. I meant that I don't need to do anything special branch/tagg things on the CVS side for the 0.40 autobuilds.
Ciao
On May 28, 2007, at 4:47 AM, Frank Barknecht wrote:
Hallo, Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote:
On May 27, 2007, at 6:26 PM, Frank Barknecht wrote:
Aren't the autobuilds automatically build from HEAD? Then there would be no need for checking stuff in explicitly.
The auto-builds are built from the HEAD of MAIN and the head of the release branch everynight. But just because it builds doesn't mean that everything works. Testing is still very much necessary.
Of course. I meant that I don't need to do anything special branch/tagg things on the CVS side for the 0.40 autobuilds.
Right. For the 0.40.2 autobuilds, only the "pd" section uses a branch (v0-40-2, IIRC). The rest use the MAIN branch (i.e. abstractions, doc, etc).
.hc
Ciao
Frank Barknecht _ ______footils.org_ __goto10.org__
PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
------------------------------------------------------------------------ ----
I spent 33 years and four months in active military service and during that period I spent most of my time as a high class muscle man for Big Business, for Wall Street and the bankers. - General Smedley Butler
Hallo, Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote:
Bug fixes are good right now in the release candidate, new features are not. As far as I know that is the definition of "release candidate", it seems to be standard practice, and it sounds like a good idea to me.
Personally I don't consider adding a couple of more abstractions in e.g. [list]-abs a new feature. As the Makefile-target to install abstractions just copies over files to a certain directory, it also seems impossible to that copying over some more files could break something, that wasn't broken before. (It's slightly different for RRADical.)
However I consider some of these new abstractions to be very important, so I will just add them.
Ciao
What sort of contributions would be needed? I agree that the release cycle should be quicker, and would like to help in any way that I can.
Is there an itinerary or task list that contributors could refer to? I think if there was a bit more of a public plan/itinerary, things could be scaled to more contributors more easily.
~Kyle
On 5/27/07, Hans-Christoph Steiner hans@eds.org wrote:
Last thing, I'd really like to see the release cycle be much quicker, but there would need to be more contributions for that to happen.
Basically, what needs to happen is to have the "Pd-extended" bugs in the tracker fixed. The two big ones that I can think of are FTGL/ Font support in Gem on Mac OS X, and the [sqrt~]/[delread~] bug on Mac OS X.
Testing then filing bugs, and writing/improving help patches is always helpful as well.
.hc
On May 28, 2007, at 3:36 PM, Kyle Klipowicz wrote:
What sort of contributions would be needed? I agree that the release cycle should be quicker, and would like to help in any way that I can.
Is there an itinerary or task list that contributors could refer to? I think if there was a bit more of a public plan/itinerary, things could be scaled to more contributors more easily.
~Kyle
On 5/27/07, Hans-Christoph Steiner hans@eds.org wrote:
Last thing, I'd really like to see the release cycle be much quicker, but there would need to be more contributions for that to happen.
--
------------------------------------------------------------------------ ----
¡El pueblo unido jamás será vencido!
Hey
On 29 May 2007, at 06:21, Hans-Christoph Steiner wrote:
Basically, what needs to happen is to have the "Pd-extended" bugs in the tracker fixed. The two big ones that I can think of are FTGL/ Font support in Gem on Mac OS X, and the [sqrt~]/[delread~] bug on Mac OS X. Testing then filing bugs, and writing/improving help patches is always helpful as well.
Ok managed to reply without reading this. Will start bughunting then, I guess. However, I still think having a more general roadmap could be useful...
David
On 28 May 2007, at 20:36, Kyle Klipowicz wrote:
What sort of contributions would be needed? I agree that the release cycle should be quicker, and would like to help in any way that I can.
Is there an itinerary or task list that contributors could refer to? I think if there was a bit more of a public plan/itinerary, things could be scaled to more contributors more easily.
I totally agree. It's hard to get a picture of outstanding tasks if you're not already in the thick of it, even if you look at the todo lists in there...
Are we supposed to use SF's tracker (bugs, features, patches, support) to track this? I think, as Kyle points out, even people like me (not experienced programmers/sysops/etc) would pitch in if there was a clearer roadmap.
David
On May 29, 2007, at 4:47 AM, David Plans Casal wrote:
On 28 May 2007, at 20:36, Kyle Klipowicz wrote:
What sort of contributions would be needed? I agree that the release cycle should be quicker, and would like to help in any way that I can.
Is there an itinerary or task list that contributors could refer to? I think if there was a bit more of a public plan/itinerary, things could be scaled to more contributors more easily.
I totally agree. It's hard to get a picture of outstanding tasks if you're not already in the thick of it, even if you look at the todo lists in there...
Are we supposed to use SF's tracker (bugs, features, patches, support) to track this? I think, as Kyle points out, even people like me (not experienced programmers/sysops/etc) would pitch in if there was a clearer roadmap.
I agree, a roadmap would be very useful. I'll try to contribute to such a thing when I get a chance. One method of contributing to Pd is to work on things that bug you, or that you want improved.
.hc
David
PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
------------------------------------------------------------------------ ----
¡El pueblo unido jamás será vencido!