[Tracker-discuss] Getting Started

[Michael Twomey]

On 11/1/06, Stefan Seefeld <seefeld at sympatico.ca> wrote:
>
> 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.
>

I think one line of thinking being advocated here is handling things
like critical bugfixes and backports. It might take us 5 days to
update the python tracker to the latest release of roundup, but we
might need to implement a critical security fix as soon as possible.
Using a vendor branch with a patch allows us to quickly push out a
fix.

You can argue that you can do ad hoc patches against a tarball, but
the vendor branch approach makes it easier for folks to work together
and track the changes being pushed out.

With a little bit of scripting the vendor branch approach should have
minimal difference to using the tarball releases, but should give us
the flexibility to do this kind of fix if we need to.

> 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's not impossible that we will need to modify roundup. Tracking it
in svn lets us feed back changes to core roundup development quite
easily.

At least, that's my take on this. I follow this approach for my work
roundup instance and I find it works quite well for me.

mick