Re: Bug#322282: ITP: swapspace -- Dynamic swap space manager
Scripsit Jeroen Vermeulen
> On Thu, Aug 11, 2005 at 06:28:07PM +0200, Henning Makholm wrote:
> > > 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,"
If you have nothing against a clear separation between the upstream
source and the Debian packaging, when why are you objecting when I say
you should have one?
> but to me that is not necessarily the same as having disparate SCM
> implementations for different parts of the same project.
Huh? Is your Debian packaging stuff written in Scheme?
> In fact, I might as well argue that you're advocating a "dirty"
> separation.
That would be wrong.
> To me, having a debian/ directory and branching off Debian release
> branches from the trunk are examples of a clear separation.
If the tarball you provide to packagers include a debian/ directory,
then your separation is not clear. The packager will have to jump
through hoops in order to make sure that a new upstream source does
not break his existing debian diff in unexpected ways. One is expected
to pay special attention to patches one has to do in upstream source,
but if one's entire debian/ directory has to be created on top of
existing files from upstream, then this job expands ten- or
hundredfold.
> 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,
I really don't care which kind of version management or
scripting/implementation language you are using. All I'm telling you
is that you will make the Debian maintainer's job much harder if you
insist of including a debian/ directory in your upstream tarballs.
That is _irrespective_ of how you produce said tarballs.
> If it doesn't describe the process accurately, then please explain
> how so that we can get this whole issue out of the way.
How == don't ship any debian/ directory in the upstream source.
You can have one in your internal version control system if you think
that is fun, just as long as your tarball generation script excludes
it.
> 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.
There are *very* well tested and time-honored procedures for managing
the separation between upstream source and Debian packaging. We have
tools and scripts to support the process, and it will be easiest for
a Debian maintainer to do it just as we use to. And it's certainly
easy for the upstream author: The *only* thing you need to do is to
not get in the way.
> 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.
It is of course OK for you to give the Debian maintainer repository
access for bugfixes in upstream code. (Of course, the Debian
maintainer may not want to learn the intricasies of whatever version
management system you are using, so you should still be prepared to
receive and process bugfixes as ordinary diff files).
You can *offer* the Debian maintainer the ability to store his
packaging files in your repository, but he is no obliged to take you
up on the offer. And, more importantly, the *next* Debian maintainer
will not be obliged to do so even if the current one does. If you then
ship the old maintainer's outdated packaging in your tarballs, the new
maintainer will have to deal with the hassle of maintaining his
packaging amidst the mess left by the previous ones. That'll cost him
trouble, it will cost us and you unnecessary bandwidth, and it will
risk making the packaging utterly impenetrable to the *next* next
maintainer.
> Don't throw loaded terms like "clear separation" and "the friendly
> way" about without justifying them.
Well, you are free to not believe our accumulated experience about
producing Debian. Do as you like.
--
Henning Makholm "You want to know where my brain is,
spetsnaz girl? Do you? Look behind you."
Reply to: