Comment 8 for bug 530584

Le mardi 29 juin 2010 à 16:21 +0000, John A Meinel a écrit :
> Another point I don't quite understand:
> "If upstream changed the HACKING file, and merge back the packaging branch
> to their upstream branch (for instance, with hudson daily build), there will be a
> conflict in the HACKING file."
>
> I would think it would be very ill advised to merge a packaging branch
> back into the upstream branch. Specifically given that it *deletes all
> of these files*. Regardless of whether the content changed. If upstream
> was using autogen.sh, which then gets deleted in the packaging branch,
> merging packaging back in will delete autogen.sh, which will mess up the
> upstream build chain, right?

This is what the recipe are doing for daily build and shipping in
hudson. I think the udd project is responsible of this.

>
> Or is it just an ongoing "ok, now we have a new upstream code, merge the
> old packaging branch in to get a new packaging branch".
>
> It still feels to me that whatever changed in autogen.sh is going to
> need to be evaluated to see if it can be safely ignored, or whether it
> actually changes how the project is built, etc, and that needs to get
> propagated into the rest of the content.
>
> As a specific example, say upstream adds a new file (mynewcode.c), which
> then needs to be incorporated into the build process. Is it assumed that
> they have made a new tarball release which should have incorporated
> those changes? (I can admit that my lack of understanding is probably
> not understanding the full workflow.)
>

Well, I'm not in favor of this merging back either, but that's how daily
build are working. And that's the root cause of all those issues.