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-05-2008, 05:24 PM
Patrick Schoenfeld
 
Default How to cope with patches sanely --> Debian New Maintainers' Guide

Hi,

On Sat, Jan 26, 2008 at 12:40:14AM +0900, Osamu Aoki wrote:
> This seems to be much cleaner than dpatch or quilt. Also with the help
> of gitk, history is much more visible. I look forward to see it matured
> and accepted.

personally I am a fan of the diversity in the Debian project. Its really
fine, that developers are not forced to work with certain software
(besides the minimal common standardisation that is needed), while I
don't see a reason why they shouldn't be able to. However I also agree
that in some levels diversity is way too much.
The way patches to the upstream source is handled is one of these
points where the diversity is way to much, as I and obviously a lot of
other people think as well.

So, yes, there should be a common agreement of how we handle patches and
I am a fan of version control systems (for a number of reasons), but I
would not agree that forcing all developers to use git is a good idea.
Personally I would think that it makes more sense to keep version
control and patch management seperated. There could be a common
agreement on a patch system and that would be really fine. I'm using
dpatch so far, but it has its weakness, so I don't see a reason why I
shouldn't go with another patch system.

So, I would agree with those recommending quilt, if it has significant
pros besides dpatch. That would be forcing to a specific tool and so
giving up some diversity, but it would keep giving up freedom of choice
on a low level, while forcing everybody to a specific VCS wouldn't keep
it low.

Best Regards,
Patrick


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 
Old 02-06-2008, 10:09 AM
Patrick Schoenfeld
 
Default How to cope with patches sanely --> Debian New Maintainers' Guide

Hi Pierre,

On Tue, Feb 05, 2008 at 09:17:12PM +0100, Pierre Habouzit wrote:
> Again, the discussion isn't (for me) about a tool, but an exchange
> format. We are discussing having patches served in a quilt series, and

okay, this approach is similar but different. So you want a quilt
series, but not quilt. This means every other utility must be able to
generate this and must support every future quilt has, which itself may
not have. So, effectively you don't actively force them to use sth. but
passiveley you do. The difference is small however.

> let people adapt their tools to be able to export their work as a quilt
> series so that other can find it and import it in their own tool of
> choice if needed.

But I am nitpicking. Call it "defining a common interface", while I call
it "decide on quilt as a common patch system". That does not matter.
What matters is that we give up a little diversity for some more
efficience.

> Enforcing maintenance tools is A Bad Idea™. The difference is huge:
> having common interfaces means that there is One True Tool that everyone
> can use if he doesn't know the Real Tools the Maintainer uses (apt-get
> source versus $SCM clone/checkout/whatever).

That are different solutions to different problems. apt-get source only
fetches finished (release, uploaded) source packages, while $SCM
clone/checkout/whatever fetches the history of the package including the
snapshot of it when doing the checkout. The common interface for $SCM
would more likely be debcheckout imo.

Regards,
Patrick


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 

Thread Tools




All times are GMT. The time now is 07:21 AM.

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