Comment 6 for bug 530584

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?

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.)