Sorry for the late reply. I'll send only a single reply this time
since my flood reply seemed to annoy some people. I still think
short single replies are better than long, unified ones...
also sprach Pierre Habouzit <madcoder@debian.org> [2008.02.03.2038 +1100]:
> > > I'm less and less sure that a git-based format is a brilliant
> > > idea. I like git more than a lot, but it's a poor idea to base
> > > source packages on them.
> >
> > Why?
>
> Because it's a way to high level tool for the task. Git (and
> I suppose that the following is true for other DVCS, and if not,
> they _REALLY_ suck, and I mean it, really) has been designed so
> that you can only exchange patches.
Many people actually tend to think of Git as a filesystem...
> > > IOW, all that you should need to grok what is in a source package
> > > should basically be tar/ar/cpio/... and vi.
> >
> > Are you sure that this has to be the case in 10 years?
>
> Are you sure git will be there and backward compatible in 10 years ?
> Okay, it's likely given the current upstream, that focuses a _lot_ on
> backward compatibility. But still. Some repository formats have been
> deprecated (the object store is of version3 and IIRC git doesn't grok
> version1 anymore, but I may be mistaken). That's the kind of gamble I
> wouldn't take.
>
> Whereas I guess tar will always grok tarballs it generates today in 10
> years, and gzip/bzip2/lzma/$compressor won't change either, and text is
> text for enough time to assume it'll remain as editeable in 10 years.
Fair enough, but why would e.g. version3 ever be removed? It's not
like versioned storage formats need a whole lot more support than
the infrastructure to identify them, which is already in place.
> > Nice, I didn't see this before. This *is* in fact nice and puts
> > the quilt *format* very high on my list.
>
> Yes, quilt preserves *everything* you put in the header, so if you use
> git (or $scm) to generate the patches with authoring information, commit
> message and so on, it wont be lost.
Excellent.
> What I ask you is just to be consistent. Either we _will_ modify
> source packages, either we won't. If we will, adding features to it is a
> good idea, if we won't, let's just focus on how to let it be expressive
> enough to encode in it all what we use as new features upstream from it.
> And as a matter of a fact, quilt is enough for that.
Good arguments. Thanks!
also sprach David Nusinow <dnusinow@speakeasy.net> [2008.02.03.1154 +1100]:
> > - patch/feature-branch-specific history. Say feature branch 'foo'
> > has a bug, so you check it out and work on it again... now
> > you're suddenly in the context of all the work you've previously
> > done and you can trivially browse the history of changes
> > applicable only to what you're currently working on.
>
> How do you decide the order to apply your feature branches? Do you encode
> it in the branch name? Congratulations, you've just reinvented dbs. Do you
> have a separate file in the debian directory that tells you the merge
> order? Congratulations, you've just reimplemented quilt. Do you write a
> script to update your branches automatically, only failing when you have to
> manually update yourself? Congratulations, you've just reinvented every
> other patch system in existence.
Good points, thanks David.
also sprach Manoj Srivastava <srivasta@debian.org> [2008.02.05.1751 +1100]:
> On Sat, 26 Jan 2008 11:34:27 -0500, David Nusinow
> <dnusinow@speakeasy.net> said:
> [...]
> > An alternate idea I keep seeing is feature branches. I have absolutely
> > no idea why these are considered preferable to most people. In the
> > case of the X server we regularly carry around 30 patches on our
> > stack. If we were to put each of these on its own unique feature
> > branch, merging them becomes an exercise in pain. Sure, we could
> > implement our own custom scripts and have very strict naming policies,
> > but then you've re-invented the wheel and congratulations, you have
> > yet another custom piece of crap software that you have to maintain on
> > top of the already complicated one you actually care
> > about. Additionally, you have a lot more branches getting in the way
> > when you're trying to figure out which one you're looking for.
>
> In my experience, once I have created the integration branch,
> most upstream versions require little to none re-merging; I just apply
> the delta to each of the feature branches, _and_ the integration
> branch. Very rarely do I have to fix up a feature branch, and then
> apply a second delta with that fix up to the integration branch; but it
> has not been, for me, painful at all, nor do I have to jump through
> hoops every single time to accommodate new upstream.
But sometimes you will have to touch an integration branch and then
things get messy, especially if there are dependencies between
feature branches. I think David is making a very strong point
here...
also sprach Ben Finney <bignose+hates-spam@benfinney.id.au> [2008.02.07.2242 +1100]:
> > On Thu, Feb 07, 2008 at 05:12:00AM +0000, Manoj Srivastava
> > wrote: That's not really about "bring your feature branches"
> > into a patch system, but rather export them into something that
> > looks like one so that the security team or the NMUer can have
> > a good outlook of the modifications you apply to upstream.
>
> In the scenario Manoj presents above, the modifications applied to
> upstream are easily available all in one place: the foo.diff.gz.
But I may want to see the differences from upstream nicely
separated into patches, rather than whole chunks? This is the same
argument why 32k diffs provided on patches.ubuntu.com are useless to
Debian maintainers.
> Whereas with a patch bundle system, the security team needs to
> know *every* patch bundle system in use and how to use it, just to
> have a chance of operating on arbitrary Debian source packages.
It looks like they'll just have to know quilt, or any other
compatible system.
Thanks to everyone for a good discussion. I am sure this isn't the
last we've heard on this front.
With Extremadura coming up, who would be interested in joining
a "workgroup" to work on this stuff? I would volunteer to chair such
a session...
--
.''`. martin f. krafft <madduck@debian.org>
: :' : proud Debian developer, author, administrator, and user
`. `'` http://people.debian.org/~madduck - http://debiansystem.info
`- Debian - when you have better things to do than fixing systems
"if you can dream it, you can do it"
-- walt disney
Attachment:
digital_signature_gpg.asc
Description: Digital signature (see http://martin-krafft.net/gpg/)