On Thu, Aug 11, 2005 at 06:28:07PM +0200, Henning Makholm wrote: > > In this particular case though, Debian is the primary environment for > > the program. > > That's not by itself a reason to include packaging-specific files in > the upstream tarball. Okay, fine. I'm just giving reasons I think _might_ be cause to deviate from usual practice; like I said I'm not the Debian developer here so it's not up to me to say what weight they may or may not carry for you.
> > For us, taking the Debian parts out might be just as awkward. > > I really doubt that. Could you explain which problems you see with > having a clear separation? Don't put words into my mouth. It unnecessarily polarizes the discussion. I have nothing against a "clear separation," but to me that is not necessarily the same as having disparate SCM implementations for different parts of the same project. In fact, I might as well argue that you're advocating a "dirty" separation. I'll tell you why first, then explain in related terms why I'm suggesting what I have been suggesting in the first place. To me, having a debian/ directory and branching off Debian release branches from the trunk are examples of a clear separation. But what you are saying sounds to my untrained ear like you want to keep a set of patches (really the SCM software's job!) and manage them in one CVS or Subversion repository, and continuously apply them to a largely version-coupled codebase that is managed in the same way in a different repository, when neither is supposed to live without the other. That to me sounds like not so much a clean separation as it is makework. If it doesn't describe the process accurately, then please explain how so that we can get this whole issue out of the way. Now what I'm _trying_ to do, by offering direct repository access and branching discretion to the Debian maintainer, is to free him and ourselves from the implementation details of that separation, and facilitate a sensible separation. When a bugfix comes in through BTS, the maintainer would be able to commit it as "upstream" or "downstream" depending on where it belongs. He would not have to go through separate processes and email exchanges based on that call, and none of us would have to deal with conflicting upstream and downstream changes. Conversely, we would not have to re-integrate any Debian patches in our test cycle. Even if there were conflicts, they would probably be easier to manage if they were all in branches of a single source-control repository. It's the job the software was designed for. So that's why I was suggesting to keep the Debian packaging in the same repository. Now if that is not helpful, explain the reason to me in practical terms. Don't throw loaded terms like "clear separation" and "the friendly way" about without justifying them. You're talking to someone unfamiliar with the Debian maintenance process; if I'm missing something, simply tell me and noone needs to get upset at all. Jeroen -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
