[PD-dev] re: branch convergence

guenter geiger geiger at xdv.org
Mon Nov 15 15:48:24 CET 2004


On Mon, 15 Nov 2004, Matju wrote:

>
> Sorry for the delay.
>

No problem, we have time.

> On Tue, 26 Oct 2004, guenter geiger wrote:
> > On Mon, 25 Oct 2004, Matju wrote:
> > Hi,
> > Although I might sound a bit repetitive, the devel branch is not meant to
> > be published.
>
> One question... what's "pd extended" ?

right, but still, the CVS devel branch was not meant to be published.
The fact that it was doesn't change the intention it was created for, or
does it ?

>
> Besides, Pd was also not intended to be a clone of MAX, and yet people use
> it a lot like that, and then Pd was also not meant to do video processing,
> and yet people use it for that. (and so on)
>
> What I mean is that if ever there's a significant incentive to publish
> binaries of the devel branch, then it will happen.
> (it may also happen if
> one mistakenly believe that there is an incentive, but, whatever.) Maybe
> everything will go well, but if some of my patches are rejected for
> whatever reason, be it for lack of time, lack of understanding, or lack of
> agreement, I don't see why I'd have to wait in line forever.
>
> That said, I will attempt to collaborate, but I'm not completely sure that
> submitting patches and applying them in scrambled order is a system that
> will survive long. The chance of interpatch conflict increases as the
> number of patches increase and that their spread factor is big (some
> patches modify 5 files or more, and not necessarily because the fix is
> lousy and made without care for diffing: sometimes you just _have_ to
> modify 5 files)

Actually patches that will not get accepted should be rejected and closed.
This way I hope  that there won't be too many patches lying around.

> > There is a webpage on sourceforge where you can submit patches (check
> > out http://pure-data.sf.net/bug-report.php).
>
> I don't know why features should be added on a page called bug-report.php;
> it's not a showstopper, but frankly, the name of the page is
> counter-intuitive. I wouldn't have looked there. The menu says "Bugs,
> Patches, FR", but seriously, "Patches" already has a strong, different
> meaning in the Pd world, which is confusing, and then FR doesn't look like
> a familiar abbreviation at all.

Yes, you are right. What if I change bug-report.php to trackers.php ?
I can also call the menu entry "Trackers", or just write "feature
requests" instead of FR, but it makes the menu entry quit  lengthy.
The reason for concentrating on the bug reporting aspect was that I
thought that is what most of the users would do.

> BTW, how normal is it to call "bug fix" what is really an added feature?
> And then how arrogant is it?

That was not my intention. I am trying to rephrase the section on patches
in order not to sound arrogant. I just sort of mixed up the two purposes
of patches, which is bug fixes and new features. Thanks for pointing it
out.

> > Its really easy. Submitting a patch is just one click away.
>
> No, it's more of a matter of duplicating the work done by CVS, but a bit
> more manually, and then figuring out dependencies and conflicts with all
> other patches that have been applied since the beginning of the branch (or
> of the last major checkpoint). The "click away" is just the last easy
> step.

You are right, I wrote that  as a buzz word, so that people accept the
system. Submitting a patch is actually easy, creating it not.

The question now is, who is responsible for creating the patch. I
think that it is not a lot harder to create the patch than to merge back
the changes in CVS.

Of course your case is a special one, because you have changes that are
going deeper into the core of Pd than others. I don't know really how
to solve this, it is likely that the system we have is not up to this
task. What would be your proposal ? Lets talk about it.

> Btw, if I'm supposed to keep a few dozen .diff files around for submission
> and also the .diff's of other people to check for potential conflicts, how
> is CVS supposed to be useful to us at all?

The same, probably it doesn't work. I would be more than happy to drop
all this patches stuff and go over to a more open development model,
where people can change the Pd code directly, but it is not up to me
to decide this.

Guenter





More information about the Pd-dev mailing list