Re: Bug#322282: ITP: swapspace -- Dynamic swap space manager
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
Reply to: