fixed four instances of a bug having to do with mistaken priorities of && and || operators that caused strcmp to be called on an uninitialized value.
If Miller wants it, it's in devel_0_39.
____________________________________________________________________ Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju Freelance Digital Arts Engineer, Montréal QC Canada
Hallo, Mathieu Bouchard hat gesagt: // Mathieu Bouchard wrote:
fixed four instances of a bug having to do with mistaken priorities of && and || operators that caused strcmp to be called on an uninitialized value.
If Miller wants it, it's in devel_0_39.
If normal users want it: Is there a patch available, too?
Ciao
On Fri, 30 Sep 2005, Frank Barknecht wrote:
Mathieu Bouchard hat gesagt: // Mathieu Bouchard wrote:
fixed four instances of a bug having to do with mistaken priorities of && and || operators that caused strcmp to be called on an uninitialized value. If Miller wants it, it's in devel_0_39.
If normal users want it: Is there a patch available, too?
"Normal users" often don't compile their own pd so they don't apply source diffs either.
What's the purpose of providing a diff if everyone who wants the feature can also get devel-pd with very little additional effort ?
____________________________________________________________________ Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju Freelance Digital Arts Engineer, Montréal QC Canada
Hallo, Mathieu Bouchard hat gesagt: // Mathieu Bouchard wrote:
What's the purpose of providing a diff if everyone who wants the feature can also get devel-pd with very little additional effort ?
The reason for providing patches/diffs was discussed a lot on pd~convention: It makes it much easier to get bugfixes etc. into the most used version of Pd, that is MSP Pd - both for Miller and for users who for whatever reason don't want to or can switch to devel_039, DesireData, PureEvil or so.
I understand that for the big changes in the various branches, like threading or the GUI reworking you are doing, patches are not possible. But your changes for uninitialized values sound like a simple bugfix, where a patch would be possible and a nice thing to do.
Ciao
On Fri, 30 Sep 2005, Frank Barknecht wrote:
Mathieu Bouchard hat gesagt: // Mathieu Bouchard wrote:
What's the purpose of providing a diff if everyone who wants the feature can also get devel-pd with very little additional effort ?
The reason for providing patches/diffs was discussed a lot on pd~convention: It makes it much easier to get bugfixes etc. into the most used version of Pd, that is MSP Pd - both for Miller and for users who for whatever reason don't want to or can switch to devel_039, DesireData, PureEvil or so.
I have a few questions for everybody.
What's my incentive to serve those users?
What were the assumptions underlying the discussion at PureData Convention? Are those assumptions valid?
Why shouldn't more users use devel_0_39 ?
Why should I make efforts to contribute to a branch I don't plan to continue to use, and that I wish gets replaced by devel_0_39 in day-to-day use?
But your changes for uninitialized values sound like a simple bugfix, where a patch would be possible and a nice thing to do.
That's cool, it means that you just found one nice thing that you could do for Miller and normal users who have a compiler but don't want to check out devel_0_39 and enjoy applying diffs that Miller hasn't applied himself.
____________________________________________________________________ Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju Freelance Digital Arts Engineer, Montréal QC Canada
Hallo, Mathieu Bouchard hat gesagt: // Mathieu Bouchard wrote:
I have a few questions for everybody.
What's my incentive to serve those users?
I don't know your incentives. And if you don't want to do it, nobody will force you.
What were the assumptions underlying the discussion at PureData Convention? Are those assumptions valid?
Well, one assumption I remember was to make it easier for Miller to get developments in devel into MAIN-Pd. Am I reading what you are saying here and below correctly as a kind of declaration, that you are not interested in supporting the mainstream Pd anymore and that your are trying to get devel/evil/desire to become the mainstream Pd? And that there will be no bugtracker-reports or diffs or so from you against MAIN anymore (maybe because that would make people still use "MAIN" instead of "devel_0XX")? I would be very sad about that, but of course it is your freedom to do so.
Why shouldn't more users use devel_0_39 ?
Why are you asking me this?
Why should I make efforts to contribute to a branch I don't plan to continue to use, and that I wish gets replaced by devel_0_39 in day-to-day use?
But your changes for uninitialized values sound like a simple bugfix, where a patch would be possible and a nice thing to do.
That's cool, it means that you just found one nice thing that you could do for Miller and normal users who have a compiler but don't want to check out devel_0_39 and enjoy applying diffs that Miller hasn't applied himself.
Well, Miller has applied a lot of the patches that are in the SF bugtracker into Pd 0.39. You can search this lists archive for his bug squashing sessions. A good example is the way, the ALSA-seq support found its way into pd-0.39. I know, that a lot of diffs and suggestions are still waiting for inclusion, some for a time that is much too long even in my conservative opinion.
However: While speed may not be Miller's first virtue ;), constancy is: I can trust on the fact, that every year at or after ICMC since almost a decade now a new, improved and generally stable version of Pd will be released. It will not have all features I wished for, but it will be able to run my old patches (most of them), they will look and sound the same (almost) and that is an important thing for me and it is important for other users.
I really like the work you and Tim and Thomas and Carmen etc. are doing on the various branches of Pd, I check them regularly, however I'm reluctant to fully rely on the various non-MAIN versions. (And yes, the year-long sleep/death of Impure Data didn't really make me more willing to immediatly jump on a non-MSP Pd version.)
I think, collecting bugfixes in the bugtracker is a good and easy thing to let everyone benefit from the knowledge, the Pd core developers have collected. Of course I could do it myself, but it always is much easier for the person to do who wrote the fix.
Ciao
On Sep 30, 2005, at 3:56 AM, Mathieu Bouchard wrote:
On Fri, 30 Sep 2005, Frank Barknecht wrote:
Mathieu Bouchard hat gesagt: // Mathieu Bouchard wrote:
What's the purpose of providing a diff if everyone who wants the feature can also get devel-pd with very little additional effort ?
The reason for providing patches/diffs was discussed a lot on pd~convention: It makes it much easier to get bugfixes etc. into the most used version of Pd, that is MSP Pd - both for Miller and for users who for whatever reason don't want to or can switch to devel_039, DesireData, PureEvil or so.
I have a few questions for everybody.
What's my incentive to serve those users?
What were the assumptions underlying the discussion at PureData Convention? Are those assumptions valid?
Why shouldn't more users use devel_0_39 ?
Why should I make efforts to contribute to a branch I don't plan to continue to use, and that I wish gets replaced by devel_0_39 in day-to-day use?
Many people here make contributions to aspects of Pd that they never use. That part of what makes it an great community. I have contributed a little to the devel branch and I have _never_ used it. But I figured it was easy enough for me to do, and it'd take someone else much longer, so I went ahead and did it.
But I can definitely tell you now that any interest I might have had in helping the devel/inpure/whatever branch is rapidly evaporating. You guys need to come down off your high horses, you are all using Miller's Pd. Most of the code in that branch was still written by Miller.
.hc
But your changes for uninitialized values sound like a simple bugfix, where a patch would be possible and a nice thing to do.
That's cool, it means that you just found one nice thing that you could do for Miller and normal users who have a compiler but don't want to check out devel_0_39 and enjoy applying diffs that Miller hasn't applied himself.
Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju Freelance Digital Arts Engineer, Montréal QC Canada
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
On 6 Oct 2005, at 05:44, Hans-Christoph Steiner wrote:
On Sep 30, 2005, at 3:56 AM, Mathieu Bouchard wrote:
Why should I make efforts to contribute to a branch I don't plan to continue to use, and that I wish gets replaced by devel_0_39 in day-to-day use?
But I can definitely tell you now that any interest I might have had in helping the devel/inpure/whatever branch is rapidly evaporating. You guys need to come down off your high horses, you are all using Miller's Pd. Most of the code in that branch was still written by Miller.
In any case you guys (main devs, contributors to core) need to sort it out, because what really isn't good is that little people like me, who might help and contribute what they can, are really confused as to where to apply their help. For an OSS community, that's suicide (in the long run, I mean).
I've never minded contributing patches to a main release manager as opposed to having totally direct access to source, and at the same time I can see the value of devel branch. Is there really no functional way the two can feed each other without trouble?
d
-- # David Plans Casal
problem.each { |day| assert_nil(spoon) }
On Thu, 6 Oct 2005, David Plans Casal wrote:
In any case you guys (main devs, contributors to core) need to sort it out,
it's exactly why I'm putting it on the table. If we just continue to pretend that there is no problem, then the problem will continue to cause harm and something will blow up at the wrong moment (that is, too late).
because what really isn't good is that little people like me, who might help and contribute what they can,
How are you little? Little as in not enough of a programmer? or little as in occasional contributor? If you wish to be more than an occasional contributor, there is a lot that can be done while not being a C programmer. A lot can be done on documentation, promotion, testing, organising, etc.
I've never minded contributing patches to a main release manager as opposed to having totally direct access to source, and at the same time I can see the value of devel branch. Is there really no functional way the two can feed each other without trouble?
There are contributions that many people want and that somehow Miller doesn't want. The number of those contributions is increasing. This causes the divergence. To stop the divergence, either Miller has to follow, or people have to stop coding things that Miller refuses to take. If Miller doesn't follow, then I don't know why I'd even try stopping devel from diverging.
____________________________________________________________________ Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju Freelance Digital Arts Engineer, Montréal QC Canada
On 7 Oct 2005, at 16:24, Mathieu Bouchard wrote:
because what really isn't good is that little people like me, who might help and contribute what they can,
How are you little? Little as in not enough of a programmer? or little as in occasional contributor? If you wish to be more than an occasional contributor, there is a lot that can be done while not being a C programmer. A lot can be done on documentation, promotion, testing, organising, etc.
True enough...I do enough testing right now to consider it a substantial contribution, actually ;-)
However, it still is difficult to ascertain where contributions should be made with such vitriolic discussions going on.
I only wish to point out my hopes that a successful resolution of conflict, and a tight integration process will happen, so it is clear to any level of contributor where things go, and where effort is needed.
There are contributions that many people want and that somehow Miller doesn't want. The number of those contributions is increasing. This causes the divergence. To stop the divergence, either Miller has to follow, or people have to stop coding things that Miller refuses to take. If Miller doesn't follow, then I don't know why I'd even try stopping devel from diverging.
Ok I see.
d
On Fri, 7 Oct 2005, Mathieu Bouchard wrote:
There are contributions that many people want and that somehow Miller doesn't want. The number of those contributions is increasing. This causes the divergence. To stop the divergence, either Miller has to follow, or people have to stop coding things that Miller refuses to take. If Miller doesn't follow, then I don't know why I'd even try stopping devel from diverging.
This is just not true. We have established a working way how contribution can go into Pd proper with the patches tracker. If you think that there are contributions that stay out without a good reason we can talk about thm. Talking about them might even convince Miller to change his mind, or we can find a more appealing solution together.
If you think it is too much work to get your proposals into Pd then propose a better way (for us all, including Miller, not just for you).
Just keep in mind that one thing is to code and the other thing is to make reliable releases. You just can not await from Miller that he lets you do the fun part (the coding) and he has to care for the integration and testing and above that change his ideas about where he wants to go.
If you want to check out how others get their code into PD, here is the link of the patches tracker: http://sourceforge.net/tracker/?group_id=55736&atid=478072
(Sorry it seems that all your contributions either got deleted or already accepted, or is it that .. no, no, I cant belive that :)
Guenter
On Fri, 7 Oct 2005, Guenter Geiger wrote:
If you want to check out how others get their code into PD, here is the link of the patches tracker: http://sourceforge.net/tracker/?group_id=55736&atid=478072 (Sorry it seems that all your contributions either got deleted or already accepted, or is it that .. no, no, I cant belive that :)
Well, to make sure it's worth submitting anything of mine, I thought I'd like to wait until Tim's FFTW patch gets accepted first. :-(
But, if you look at the patch tracker with the link you gave above, you will see that the FFTW patch has been submitted 11.5 months ago, that the first reaction to it (by _anyone_) waited till May when Miller said:
* I don't know what to do about this one. I don't use FFTW because it requires "configure" and I don't have a windows machine with CYGWIN, so wouldn't ever be able to test this. Perhaps it's for use with linux only? Rumor has it fftw is much faster than meyer, but I've never wanted to go to the hassle of learning how to install it.
and still nothing has been done about it.
And that's only one feature.
The patches tracker is not my only way of communicating with Miller. I have other ways of knowing that he wouldn't accept my patches.
____________________________________________________________________ Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju Freelance Digital Arts Engineer, Montréal QC Canada
ola,
Why should I make efforts to contribute to a branch I don't plan to continue to use, and that I wish gets replaced by devel_0_39 in day-to-day use?
But I can definitely tell you now that any interest I might have had in helping the devel/inpure/whatever branch is rapidly evaporating. You guys need to come down off your high horses, you are all using Miller's Pd. Most of the code in that branch was still written by Miller.
yes, i second that. furthermore, i regret the arrogant attitude of people who think they invented a brand new program because they changed the interface.. don't judge a book by the cover...
don't forget that Miller is very busy, that he is making good efforts to incorporate useful changes and that he is a philosopher and writer so he doesn't spend all his time on code.
i'm just interested in having a click-free pd, and i posted some patches for having a threaded soundfiler that 2 years ago, i still using these patches.
ciao, sevy
On Thu, 6 Oct 2005, Yves Degoyon wrote:
yes, i second that. furthermore, i regret the arrogant attitude of people who think they invented a brand new program because they changed the interface..
It's not all about the gooey. When is SIMD going into the real pd? When is your threaded soundfiler going into the real pd?
don't judge a book by the cover...
A GUI is not a cover. a splash-screen might be a cover...
Why the book metaphor ? The experience of using the software is much different from the one of using a book. Reading the source code is more like reading a book, but most people don't do that, and if it were only about the source code and not running it there would be little point in PureData.
i'm just interested in having a click-free pd, and i posted some patches for having a threaded soundfiler that 2 years ago, i still using these patches.
Tsk, tsk. True punks just enjoy the clicks.
____________________________________________________________________ Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju Freelance Digital Arts Engineer, Montréal QC Canada
I actually wanted to stay out of this discussion, but I have to support the opinions of hc. and yves.
The patches system works very well, and I think it is a model how collaboration can work out, if we follow the rules.
Guenter
On Thu, 6 Oct 2005, Mathieu Bouchard wrote:
On Thu, 6 Oct 2005, Yves Degoyon wrote:
yes, i second that. furthermore, i regret the arrogant attitude of people who think they invented a brand new program because they changed the interface..
It's not all about the gooey. When is SIMD going into the real pd? When is your threaded soundfiler going into the real pd?
don't judge a book by the cover...
A GUI is not a cover. a splash-screen might be a cover...
Why the book metaphor ? The experience of using the software is much different from the one of using a book. Reading the source code is more like reading a book, but most people don't do that, and if it were only about the source code and not running it there would be little point in PureData.
i'm just interested in having a click-free pd, and i posted some patches for having a threaded soundfiler that 2 years ago, i still using these patches.
Tsk, tsk. True punks just enjoy the clicks.
Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju Freelance Digital Arts Engineer, Montréal QC Canada
PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
ola,
i'm gonna answer more deeply to that shit ( ok, i'm drunk )
i was only asking a bit of respect for miller, when i saw the first "patcher·" version for mac OS with 5 objects, that was already inspiring ))
about being a punk, it's a compliment to me and to you, that's negative... don't forget that fucking the sound system is partly fucking the system but it's not enough )))
if i ask you whose that song is from : "i am a sample, i am a product", do you know anything?
then, don't forget forget you work for museum and such and just don't help when people are suffering out there...
don't ask me, know who you are..
ciao, sevy
Guenter Geiger wrote:
I actually wanted to stay out of this discussion, but I have to support the opinions of hc. and yves.
The patches system works very well, and I think it is a model how collaboration can work out, if we follow the rules.
Guenter
On Thu, 6 Oct 2005, Mathieu Bouchard wrote:
On Thu, 6 Oct 2005, Yves Degoyon wrote:
yes, i second that. furthermore, i regret the arrogant attitude of people who think they invented a brand new program because they changed the interface..
It's not all about the gooey. When is SIMD going into the real pd? When is your threaded soundfiler going into the real pd?
don't judge a book by the cover...
A GUI is not a cover. a splash-screen might be a cover...
Why the book metaphor ? The experience of using the software is much different from the one of using a book. Reading the source code is more like reading a book, but most people don't do that, and if it were only about the source code and not running it there would be little point in PureData.
i'm just interested in having a click-free pd, and i posted some patches for having a threaded soundfiler that 2 years ago, i still using these patches.
Tsk, tsk. True punks just enjoy the clicks.
Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju Freelance Digital Arts Engineer, Montréal QC Canada
PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
On Fri, 7 Oct 2005, Yves Degoyon wrote:
i was only asking a bit of respect for miller
why would respect mean status quo ?
when i saw the first "patcher·" version for mac OS with 5 objects, that was already inspiring
And then what? Can't better GUIs be even more inspiring? What about tab-completion and tooltips on inlets, outlets, object arguments, message arguments ? What about a better GOP ? What about a better API for creating GUI objects ?
don't forget that fucking the sound system is partly fucking the system
And how does this matter? Which system is "the" system? Why does it need to be fucked?
if i ask you whose that song is from : "i am a sample, i am a product",
it's "End Result" by Crass. why is that song even relevant?
then, don't forget you work for museum and such and just don't help when people are suffering out there... don't ask me, know who you are..
Huh, try again when you're less drunk: I can't figure out what you're trying to make me understand.
____________________________________________________________________ Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju Freelance Digital Arts Engineer, Montréal QC Canada
ola,
if i ask you whose that song is from : "i am a sample, i am a product",
it's "End Result" by Crass. why is that song even relevant?
good point. it's definitely relevant if you consider pd as a product and introduce competition.
then, don't forget you work for museum and such and just don't help when people are suffering out there... don't ask me, know who you are..
Huh, try again when you're less drunk: I can't figure out what you're trying to make me understand.
this was maybe OT, but it was to recontextualize the importance of this debate that is next to 0 to me, when we have some bad days here and other problems that matter a little bit more ( like 2400 africans deported to the desert by maroccan and spanish authorities ), we would like that some independent medias ( operated with pd ) could cover these facts.
i can tell, i had a bad day, so this debate here really means little to me.
ciao, keep your arrogant and concurrential attitude, i'm not interested in what comes out of it.
ciao, sevy
On Thu, 6 Oct 2005, Guenter Geiger wrote:
The patches system works very well, and I think it is a model how collaboration can work out, if we follow the rules.
It works well for people who are already satisfied with what Miller wants PureData to be.
For the rest of us, hmmm, it doesn't work that well, no...
____________________________________________________________________ Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju Freelance Digital Arts Engineer, Montréal QC Canada
Why should I make efforts to contribute to a branch I don't plan to continue to use, and that I wish gets replaced by devel_0_39 in day-to-day use?
But I can definitely tell you now that any interest I might have had in helping the devel/inpure/whatever branch is rapidly evaporating. You guys need to come down off your high horses, you are all using Miller's Pd. Most of the code in that branch was still written by Miller.
yes, i second that. furthermore, i regret the arrogant attitude of people who think they invented a brand new program because they changed the interface.. don't judge a book by the cover...
don't forget that Miller is very busy, that he is making good efforts to incorporate useful changes and that he is a philosopher and writer so he doesn't spend all his time on code.
i'm just interested in having a click-free pd, and i posted some patches for having a threaded soundfiler that 2 years ago, i still using these patches.
well, pd is a piece of software, that is able to do a few things, and is lacking a lot of features ... (especially, it's not designed to be click-free)
a user interface is a pretty important part of the software, since it's the "interface" to the "user" ... a bit more, than the cover of a book. beside that, there are more severe changes in devel, (dsp) scheduling, threading, that aim to a clean solution, but they won't result in a clean solution, if 20000 groups of developers are inventing 20001 wheels ... some other changes that would result in a click-free software will require some even larger changes, not to mention that it will most likely collide with other changes, if it's not coordinated.
personally i have to admit, that i'm really fed up with this whole discussion. pd will probably me my audio programming language for the next few years, but it will definitely not be my long-term solution!
cheers ... tim
I understand that for the big changes in the various branches, like threading or the GUI reworking you are doing, patches are not possible. But your changes for uninitialized values sound like a simple bugfix, where a patch would be possible and a nice thing to do.
well, if someone cares, he can read the diffs and create a patch against HEAD (that's easy, since there is a pd-cvs list) ...
but there are people, who don't care ...
t
Zitiere Tim Blechmann TimBlechmann@gmx.net:
I understand that for the big changes in the various branches, like threading or the GUI reworking you are doing, patches are not possible. But your changes for uninitialized values sound like a simple bugfix, where a patch would be possible and a nice thing to
do.
well, if someone cares, he can read the diffs and create a patch against HEAD (that's easy, since there is a pd-cvs list) ...
but there are people, who don't care ...
oh wow! seems like i can finally get rid of the "mr. rude and grumpy" award...
weirdly enough, i just yesterday started to track down and fix some "uninitialized values in strcmp()" issue (running pd with valgrind reported a lot of problems), but i didn't get far because people kept coming into my office and asking this and that... so it seems that this might already be fixed.
mfg.ads.r IOhannes
well, if someone cares, he can read the diffs and create a patch against HEAD (that's easy, since there is a pd-cvs list) ...
but there are people, who don't care ...
oh wow! seems like i can finally get rid of the "mr. rude and grumpy" award...
i didn't wanted to sound rude ... but personally i don't have any ambitions to fix miller's pd, since it just takes time and i don't benefit from it, since i don't use miller's pd ...
weirdly enough, i just yesterday started to track down and fix some "uninitialized values in strcmp()" issue (running pd with valgrind reported a lot of problems), but i didn't get far because people kept coming into my office and asking this and that... so it seems that this might already be fixed.
i suppose you can ignore most of the errors coming from structures like:
while (s2 = *s1) { s1 = something(s2); }
lots of these structures are used in pd's code and i somehow have the feeling, that valgrind doesn't handle them properly, since the equivalent structure:
while (1) { if(!s1) break; s1 = something(s2); }
doesn't seem to throw this error ... i looked into this a few weeks ago ...
cheers ... t
while (s2 = *s1) { s1 = something(s2); }
and
while (1) { if(!s1) break; s1 = something(s2); }
is not the same. In the latter case s2 isn't initialized. Don't know if this is of any significance.
oops, it was too early in the morning ... i wanted to write:
while(1) { s2 = *s1; if (!s2) break; s1 = something(s2); }
thanks for correcting me ... tim
heya
On 30 Sep 2005, at 11:55, IOhannes m zmoelnig wrote:
seems like i can finally get rid of the "mr. rude and grumpy" award...
i didn't wanted to sound rude ... but personally i don't have any
of course. neither did i want to sound rude or grumpy when i eventually did so...
Just 2eurocents from a devel_0.39 -and- MAIN user...my guess is we're going to talk about forking here, at today's IRC meeting, right?
I've seen forks in other FLOSS projects, and they're never pretty. But then, there isn't usually a pumpkin holder as determined and present as Miller.
May I suggest, that while we consider these issues, we also consider the appointment of a release manager? I know that Tim's work on dev39 is almost nominally exactly that, but I feel that someone should take on the actual release manager role, since that would almost certainly help the fork-like feelings and problems here, no?
david -- # David Plans Casal
problem.each { |day| assert_nil(spoon) }
On Fri, 30 Sep 2005, David Plans Casal wrote:
seems like i can finally get rid of the "mr. rude and grumpy" award...
i didn't wanted to sound rude ... but personally i don't have any
of course. neither did i want to sound rude or grumpy when i eventually did so...
Just 2eurocents from a devel_0.39 -and- MAIN user...my guess is we're going to talk about forking here, at today's IRC meeting, right?
There hasn't been that much talking about forking the project at the meeting. Anyway I don't think it's really a topic in itself: it's implicit that if we don't communicate (between the Millers and the nonMillers among us) then the crack in the floor will widen faster than if we don't.
However, the crack in the floor will continue widening until Miller gives up gatekeeping his branch alone.
I've seen forks in other FLOSS projects, and they're never pretty.
But are they necessary? If they're necessary, then whether they're pretty or not is not a question.
May I suggest, that while we consider these issues, we also consider the appointment of a release manager? I know that Tim's work on dev39 is almost nominally exactly that, but I feel that someone should take on the actual release manager role, since that would almost certainly help the fork-like feelings and problems here, no?
Now the question is: what will the release manager do when Pd/MSP 0.40 comes out? Because I'm not certain at all what Tim will/would do with a Pd/MSP 0.40 on his hands.
And then I wonder who would volunteer for merging stuff while not dropping any features from either branch.
What else should the release manager do? There could be "stabilized" versions of the devel branch, that is, for each big release, a branch made only for bugfixes, but I don't think we can afford that luxury right now, unless someone volunteers for that, and that's certainly not certain.
____________________________________________________________________ Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju Freelance Digital Arts Engineer, Montréal QC Canada
On 4 Oct 2005, at 05:28, Mathieu Bouchard wrote:
On Fri, 30 Sep 2005, David Plans Casal wrote:
Just 2eurocents from a devel_0.39 -and- MAIN user...my guess is we're going to talk about forking here, at today's IRC meeting, right?
However, the crack in the floor will continue widening until Miller gives up gatekeeping his branch alone.
+1
Though I have heard his reasons in the past, I still think proper release management (controlled by more than 1 person, managed by 1 person ultimately) is needed, and I guess Miller's position at the moment doesn't allow that.
I've seen forks in other FLOSS projects, and they're never pretty.
But are they necessary? If they're necessary, then whether they're pretty or not is not a question.
When they have been absolutely necessary (the codebase was diverging wildly), prettiness wasn't on anyone's agenda, no.
May I suggest, that while we consider these issues, we also consider the appointment of a release manager? I know that Tim's work on dev39 is
ow the question is: what will the release manager do when Pd/MSP 0.40 comes out? Because I'm not certain at all what Tim will/would do with a Pd/MSP 0.40 on his hands.
It shouldn't have to come down to being his decision. In a 'normal' FLOSS process, releases don't just 'come out'.
And then I wonder who would volunteer for merging stuff while not dropping any features from either branch.
My guess : no one.
What else should the release manager do? There could be "stabilized" versions of the devel branch, that is, for each big release, a branch made only for bugfixes, but I don't think we can afford that luxury right now, unless someone volunteers for that, and that's certainly not certain.
I agree. My point is that release management is preferable to forking, every day, but I admit PD may be too fragmented already.
Perhaps I'm missing blocks of history here, but it seems to me that it shouldn't be impossible to achieve convention between branches, provided there is an initial setup effort. Count me in, FWIW.
Cheers,
David
On Tue, 4 Oct 2005, David Plans Casal wrote:
May I suggest, that while we consider these issues, we also consider the appointment of a release manager? I know that Tim's work on dev39 is
ow the question is: what will the release manager do when Pd/MSP 0.40 comes out? Because I'm not certain at all what Tim will/would do with a Pd/MSP 0.40 on his hands.
It shouldn't have to come down to being his decision. In a 'normal' FLOSS process, releases don't just 'come out'.
No, I only assumed that the release manager you talked about would manage the release of non-Miller code. From what I know I presume that even if more people organised around devel_0_xx, Miller would still release his own version and not use devel_0_xx.
And then I wonder who would volunteer for merging stuff while not dropping any features from either branch.
My guess : no one.
Tim has almost done that for 37->38, 38->39, but I don't think he'll do that eternally.
Perhaps I'm missing blocks of history here, but it seems to me that it shouldn't be impossible to achieve convention between branches, provided there is an initial setup effort. Count me in, FWIW.
I dunno, if you want to do that, first conquer San Diego -- and I don't mean Carmen here!!!
____________________________________________________________________ Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju Freelance Digital Arts Engineer, Montréal QC Canada
-
David Plans Casal -
Frank Barknecht -
Guenter Geiger -
Hans-Christoph Steiner -
IOhannes m zmoelnig -
Mathieu Bouchard -
Thomas Grill -
Tim Blechmann -
Yves Degoyon -
zmoelnig＠iem.at