[Tracker-discuss] Getting Started

[Stefan Seefeld]

Paul Dubois wrote:
> 1. I strongly suggest the vendor-branch method I mentioned before. That
> would mean that in this case you create a 'vendor' branch consisting of the
> version of Roundup that you modified to make the prototype. Then branch it
> to 'ours'. Submit the prototype as a change to 'ours'. Then we can start
> modifying it as needed.

Just to clarify: nobody modified roundup in order to build the prototype.
I don't anticipate us making modifications to any given roundup release,
so I'm not sure that putting the roundup code itself into a vendor branch
would benefit us in any way.

What we did work on was the tracker instance, which (I believe) evolved
out of a 'demo tracker' that was generated by running some 'demo.py'
script that ships with roundup packages.
But since we are not going to merge changes made to the demo tracker
to our own tracker, I don't think working with vendor branches here
makes much sense either.

> If we don't do this extra step, when a new Roundup comes out we have an
> awful job putting those changes into 'ours'. But with this scheme, we check
> the new Roundup into 'vendor' and integrate to 'ours' and let the
> source-code management tools for resolving conflicts be our friend.

Again, we don't modify roundup ourselves, so upgrading to a new roundup
version will incure the same amount of work for us, no matter whether
we have a copy in a vendor branch or not.

> It is possible that this is what you meant but I want to be sure. I did not
> do this when I first used Roundup and at the time Richard had no suggestion
> for me as to how to solve the problem. I paid a big price. But this scheme
> really does the trick.

Hmm, may be I'm completely missing what you are talking about then.

Thanks,
		Stefan

-- 

      ...ich hab' noch einen Koffer in Berlin...