FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Debian > Debian Development

 
 
LinkBack Thread Tools
 
Old 02-02-2008, 05:47 AM
martin f krafft
 
Default How to cope with patches sanely (Was: State of the project - input needed)

also sprach Darren Salt <linux@youmustbejoking.demon.co.uk> [2008.01.26.1105 +1100]:
> So no need for .git.tar.gz, then - just carry on shipping
> .orig.tar.gz and .diff.gz, and use debcheckout if you need the
> history.

As Debian moves more and more into developing countries, where
Internet access is not (yet) ubiquitous, this seems like a step
backwards. Ideally, the history should be on the source DVDs.

I am strongly in favour of something like git.tar.gz. joeyh's
implementation may not be what we end up with. But it's a start. Now
we can let time tell how to do it. Let the competition begin!

--
.'`. 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

redistribution of this email via the
microsoft network is prohibited.
 
Old 02-02-2008, 05:52 AM
martin f krafft
 
Default How to cope with patches sanely (Was: State of the project - input needed)

also sprach Colin Watson <cjwatson@debian.org> [2008.01.27.0133 +1100]:
> include this sort of cruft. If patch systems must stay around,
> I would be happy if somebody could design and write a standard
> wrapper that could figure out the differences automatically, and
> get it into devscripts.

I think this is the way forward, and even more: such a wrapper
should ideally map the workflow in used by other distros. I have
recently met with Fedora people at LCA and we basically came to the
conclusion that we not only do the same stuff, but we also have
a one-to-one mapping between our packaging workflows. And Fedora is,
just like Debian, running up against the limits of the workflow(s)
in use, so what better time to rethink it now and *together*?

http://madduck.net/blog/2008.01.29:consolidating-packaging-workflows-across-distros

I really want to see Debian spearhead cross-distro efforts and
I intend to allocate some time to this. I am still writing this up
elsewhere, so stay tuned for more information on this from me.

Interested people might want to sign up to my vcs-pkg mailing list,
which I am designating as the discussion forum for such efforts
until a better one comes along.

--
.'`. 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

"i can stand brute force, but brute reason is quite unbearable. there
is something unfair about its use. it is hitting below the
intellect."
-- oscar wilde
 
Old 02-02-2008, 05:55 AM
martin f krafft
 
Default How to cope with patches sanely (Was: State of the project - input needed)

also sprach Andreas Tille <tillea@rki.de> [2008.01.28.1859 +1100]:
> The only problem that me and I guess at least 50% of DDs have with
> debcheckout(1) and debcommit(1) is that they did not know them before
> this thread. Feel free to call me ignorant, but I was not aware of
> these tools (and will not be able to check them for the next couple
> of days because of time constraints). So perhaps we do face here a
> mere communication problem for a problem that is technically solved.

The answer to this is, IMHO: let's take small steps. Instead of
solving this across the entire archive, I would like to see
individual maintainers experiment with it and report to the others.
Ideally, we'll eventually converge on a single workflow and can take
it from there. Once it's become a de-factor standard, everyone will
sooner or later find out. I just think there is no need to involve
everyone in the design stage, since many of us "just" maintain
packages and don't have the time to follow and try out every single
innovation.

--
.'`. 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

"the truth is rarely pure and never simple. modern life would be very
tedious if it were either, and modern literature a complete
impossibility!"
-- oscar wilde
 
Old 02-02-2008, 07:18 AM
martin f krafft
 
Default How to cope with patches sanely (Was: State of the project - input needed)

also sprach David Nusinow <dnusinow@speakeasy.net> [2008.01.27.0334 +1100]:
> External patch systems are not ideal by any means, but they do
> clearly address these issues as well as I could ask for. It's
> trivial to update the patches, just go one by one through them.
> You can trivially see the patch in full, which makes it quite easy
> to deal with. Patches, once ready, can be easily sent upstream for
> later inclusion. Patches can be commented in their headers, which
> allows an easy single place to collect information rather than
> having to scour through your history.

I really don't see how this is in any way different from feature
branches. Sure, having 30-or-so feature branches around may make you
dizzy at first, but most of them you won't have to touch, and if you
do, then what you get is pretty cool:

- merge support, in case the base branch ('master' or 'upstream'
or 'debianisation') has changed. Unless there have been
incompatible changes, the VCS can "update" your patch trivially
easy, and better than any of the patch systems I've seen.

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

--
.'`. 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

it's practically impossible to look at a penguin and feel angry.
 
Old 02-02-2008, 07:21 AM
martin f krafft
 
Default How to cope with patches sanely (Was: State of the project - input needed)

also sprach Pierre Habouzit <madcoder@debian.org> [2008.01.27.0505 +1100]:
> Seconded. I'd add, that in fact we should standardize on quilt
> as an exchange format for patches, because it's simple, and that
> there are powerful tools to handle them.

Except those patches contain no VCS-specific data, like the author.
In relation to licencing issues, I think it's especially interesting
to have the ability to cherry-pick and keep the original committer
info unchanged. I'd say what we really want is a way to cherry-pick
between different VCS, and a higher-level wrapper on top of all VCS
implementing a generic, cross-distro workflow.

--
.'`. 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

"i like wagner's music better than anybody's. it is so loud that one
can talk the whole time without other people hearing what one says."
-- oscar wilde
 
Old 02-02-2008, 07:31 AM
martin f krafft
 
Default How to cope with patches sanely (Was: State of the project - input needed)

also sprach Pierre Habouzit <madcoder@debian.org> [2008.01.25.1959 +1100]:
> Oh and don't try to ask for complete uniformity in packaging, there
> are 1000 DDs, 10 times as many packages, different needs (you don't
> package a perl extension like you package mozilla or gcc or a java
> library) hence you can't ask people to use the same tools each time.

I'd even say that 90% of our packages don't even need patch
management systems...

PS: this figure is 80% correct but will surely be questioned by 70%
of the people. The likelihood that someone replies to this message
is 50%. The likelihood that someone flames is currently 12.6%. The
likelihood that I err is 0.

--
.'`. 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 one cannot enjoy reading a book over and over again,
there is no use in reading it at all."
-- oscar wilde
 
Old 02-02-2008, 07:32 AM
martin f krafft
 
Default How to cope with patches sanely (Was: State of the project - input needed)

also sprach Riku Voipio <riku.voipio@iki.fi> [2008.01.26.0205 +1100]:
> We have managed to get almost complete uniformity of the binary
> packages produced. And imho, it's one of the things that makes
> Debian great. In this background it's kinda sad that our source
> packaging such a mess with so many competing and overlapping
> tools and SCM managment practices.

Competition is good. Discussion and trying to identify what works
and what doesn't is better.

> Sure, the major problem that we dont's have a Tyrann [1] to
> choose, so people will prefer loudly what they are familiar
> with, rather than what is best. This means we need to find small
> evolutionary steps to get there, document best practices and
> eventually codify them.

+1. Well put.

--
.'`. 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

"life moves pretty fast. if you don't stop and look around once in
a while, you could miss it."
-- ferris bueller
 
Old 02-02-2008, 07:33 AM
martin f krafft
 
Default How to cope with patches sanely (Was: State of the project - input needed)

also sprach Josselin Mouette <joss@debian.org> [2008.01.25.2008 +1100]:
> I’d be glad if we could standardize on quilt.

Standardisation is not something you do, IMHO, it's something that
emerges. So if you want quilt to become the standard, test it,
experiment it, smooth out the rough edges, teach people, document
it, make it more flexible, etc..

--
.'`. 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

remember, half the people are below average.
 
Old 02-02-2008, 07:38 AM
martin f krafft
 
Default How to cope with patches sanely (Was: State of the project - input needed)

also sprach Pierre Habouzit <madcoder@debian.org> [2008.01.27.0939 +1100]:
> On Fri, Jan 25, 2008 at 06:00:02PM +0000, Raphael Hertzog wrote:
> > On Fri, 25 Jan 2008, Michael Banck wrote:
> > > On Fri, Jan 25, 2008 at 10:51:05AM +0100, Lucas Nussbaum wrote:
> > > > On 25/01/08 at 08:01 +0000, Steve Langasek wrote:
> > > > > As a second runner up, quilt is ok by me.

...

> 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?

> 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? I know what
you mean, I agree with you, but this sort of thinking must not get
in the way of innovation and advancements. When tar came around,
I am sure some people opposed to its use and said that everything
should be based on ar only. I am glad they didn't get their way
(even if this is fictitious and has never actually happened,
AFAICT).

At the same time, I don't think it's wise to expect people to know
the different ways to handle git.tar.gz and bzr.tar.gz and so on.
I think what we want is the often-mentioned wrapper which hides the
actual storage backend in use.

> Another thing is that people have the old habit to see the
> source package be the preferred form of modification for
> a Debian package.

Again, those people are not our priority. We ought not forget them,
but we also shouldn't restrict the rest of the project because of
them.

--
.'`. 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

"i can stand brute force, but brute reason is quite unbearable. there
is something unfair about its use. it is hitting below the
intellect."
-- oscar wilde
 
Old 02-02-2008, 07:43 AM
martin f krafft
 
Default How to cope with patches sanely (Was: State of the project - input needed)

also sprach Theodore Tso <tytso@mit.edu> [2008.01.28.1613 +1100]:
> From: Author O' The Patch <author@example.com>
> Detailed patch description
> Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
>
> This is at the beginning of every single quilt patch, and because of
> this, we can easily important the patch into either a mercurial or git
> repository, while preserving the authorship information of the patch.

Nice, I didn't see this before. This *is* in fact nice and puts
the quilt *format* very high on my list.

> Since we are keeping the patch series under source control, it
> allows us to refine patches, and keep a historical record of the
> improvements to a particular patch before it us pushed upstream.

and I guess you can use feature branches to create the patches, if
you like working with the VCS for this sort of thing (like I do) and
then store them in yet another branch.

--
.'`. 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

windoze 98: <n.> useless extension to a minor patch release for 32-bit
extensions and a graphical shell for a 16-bit patch to an 8-bit
operating system originally coded for a 4-bit microprocessor, written
by a 2-bit company that can't stand for 1 bit of competition.
 

Thread Tools




All times are GMT. The time now is 06:29 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org