Maintaining meta-data for patches
yanefbsd at gmail.com
Sat Dec 13 11:36:00 PST 2008
On Sat, Dec 13, 2008 at 2:33 AM, Romain Tartière <romain at blogreen.org> wrote:
> As a port maintainer, you sometimes have to provide patches in your
> ports in order to have a piece of code working. If you maintain
> projects in a team, you will likely have to handle patches that you
> wrote along with patches that your co-workers have created.
> While this situation is not hard to handle while creating the port, it
> is slightly more complex when you want to update the port in question.
> You have to deal with each patch and see if it is still relevant, and
> since you don't have many info about it, you first have to figure out
> what it is supposed to fix. Generally, you try with / without the patch
> and see if you keep it, but don't go any further (search is the bug has
> been reported upstream, if solutions have been provided upstream, etc.).
> If I consider for example the port of Mono:
> We have 13 patches I want to review in order to cleanup the port.
> I would like to ask random questions like:
> - who made this patch? [*]
> - what is-it supposed to do? [*]
> - has it been reported upstream? where?
> - is it fixed in projects trunk upstream?
> - will it expire at some point (e.g. trunk has been fixed after
> foo-1.0.1 was tagged so the patch will be useless as soon as foo is
> at version>1.0.1)
> Questions marked with a * can be answered directly using some version
> control system (even if in my case it will not help much since most
> patches come from revision 3: «Initial import: copy of the cvs repo.»).
> I am so wondering if anyone has ever setup some tools to ease
> collaborative ports maintenance?
No, but setting up svk is the best way to maintain local patches
against a repository. I have yet to set it up though because I haven't
taken the time to do so yet.
More information about the freebsd-ports