How to handle Debian patches

classic Classic list List threaded Threaded
150 messages Options
1234 ... 8
Reply | Threaded
Open this post in threaded view
|

How to handle Debian patches

Raphael Hertzog-3
[Breaking the thread on purpose to start a new one]

On Fri, 16 May 2008, Lucas Nussbaum wrote:

> On 16/05/08 at 15:41 +0200, Miriam Ruiz wrote:
> > just reviewed by just one person, but then again, I seriously think
> > that it would have been quite difficult to discover that there was a
> > problem with this one. The proof that it wasn't evident is not only
> > that upstream didn't see the problem either, nor any other developer
> > or derivative distribution or independent reviewers in 2 years.
>
> I think that one problem is that our patches are too difficult to
> review. We should make our Debian-specific changes more visible,
> comment them, etc.
>
> We could write a diff2html tool that would help read our diff.gz files
> by separating packaging changes from changes made to upstream source,
> and then publish that information on a patches.d.o service, and link it
> from various places (packages.d.o, PTS).

I totally agree that we need to make our changes more visible. In the
openssl case, the patch in question is inside the .diff.gz and you don't
notice it in the unpacked source package. I tend to give a look to what's
in debian/patches/ when I rebuild a package but not to what's in .diff.gz
only.

To me this one proof more than even when VCS are used to maintain
packages, our source packages must clearly identify the Debian patches
that are applied. The source package is an export format of our packaging
work and they must highlight our changes so that other people can easily
grab our changes and/or review them. [1]

In the general case, I do believe that the new source package format "3.0
(quilt)" will help as all Debian specific changes will always end up in
debian/patches/. Any manual change leads to a new patch that will be
associated to the version where it has been introduced so it's easy to
look the changelog to find the explanation of the change (if any). And
patches directly installed in debian/patches ought to be documented (see
below for more on this).

Once we switched to this source format, it should be trivial to create
patches.debian.org. [2]

Add to this that each patch should have some standardized header on top
stating:
- a description of the patch and its purpose
- the associated bug number
- who wrote the patch
- where it has been forwarded upstream
- sign-off by reviewers maybe

Someone recently posted an example of this. IMO we should write a DEP
on patch management and standardize those headers. And probably enforce
their usage for patches on sensitive packages (lintian checks?).

Cheers,

[1] It has a cost but I believe it's worth it. And we need to work on
tools that let us handle our changes in topic branches and yet still
generate a package which is a plain upstream tarball + a series of patches.

[2] And IMO we should go further than patches.d.o, we need to create a
cross-distro infrastructure where we can share patches. We really have to
show the way here... (we complained enough that ubuntu patches were
unusable, surely we can show how to do it right when it comes to sharing
patches with others and upstream)
--
Raphaël Hertzog

Le best-seller français mis à jour pour Debian Etch :
http://www.ouaza.com/livre/admin-debian/


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: How to handle Debian patches

martin f krafft
Please Cc [hidden email] on this thread!

Including the full response for the list.

also sprach Raphael Hertzog <[hidden email]> [2008.05.16.1654 +0100]:

> [Breaking the thread on purpose to start a new one]
>
> On Fri, 16 May 2008, Lucas Nussbaum wrote:
> > On 16/05/08 at 15:41 +0200, Miriam Ruiz wrote:
> > > just reviewed by just one person, but then again, I seriously think
> > > that it would have been quite difficult to discover that there was a
> > > problem with this one. The proof that it wasn't evident is not only
> > > that upstream didn't see the problem either, nor any other developer
> > > or derivative distribution or independent reviewers in 2 years.
> >
> > I think that one problem is that our patches are too difficult to
> > review. We should make our Debian-specific changes more visible,
> > comment them, etc.
> >
> > We could write a diff2html tool that would help read our diff.gz files
> > by separating packaging changes from changes made to upstream source,
> > and then publish that information on a patches.d.o service, and link it
> > from various places (packages.d.o, PTS).
>
> I totally agree that we need to make our changes more visible. In the
> openssl case, the patch in question is inside the .diff.gz and you don't
> notice it in the unpacked source package. I tend to give a look to what's
> in debian/patches/ when I rebuild a package but not to what's in .diff.gz
> only.
>
> To me this one proof more than even when VCS are used to maintain
> packages, our source packages must clearly identify the Debian patches
> that are applied. The source package is an export format of our packaging
> work and they must highlight our changes so that other people can easily
> grab our changes and/or review them. [1]
>
> In the general case, I do believe that the new source package format "3.0
> (quilt)" will help as all Debian specific changes will always end up in
> debian/patches/. Any manual change leads to a new patch that will be
> associated to the version where it has been introduced so it's easy to
> look the changelog to find the explanation of the change (if any). And
> patches directly installed in debian/patches ought to be documented (see
> below for more on this).
>
> Once we switched to this source format, it should be trivial to create
> patches.debian.org. [2]
>
> Add to this that each patch should have some standardized header on top
> stating:
> - a description of the patch and its purpose
> - the associated bug number
> - who wrote the patch
> - where it has been forwarded upstream
> - sign-off by reviewers maybe
>
> Someone recently posted an example of this. IMO we should write a DEP
> on patch management and standardize those headers. And probably enforce
> their usage for patches on sensitive packages (lintian checks?).
>
> Cheers,
>
> [1] It has a cost but I believe it's worth it. And we need to work on
> tools that let us handle our changes in topic branches and yet still
> generate a package which is a plain upstream tarball + a series of patches.
>
> [2] And IMO we should go further than patches.d.o, we need to create a
> cross-distro infrastructure where we can share patches. We really have to
> show the way here... (we complained enough that ubuntu patches were
> unusable, surely we can show how to do it right when it comes to sharing
> patches with others and upstream)
> --
> Raphaël Hertzog
>
> Le best-seller français mis à jour pour Debian Etch :
> http://www.ouaza.com/livre/admin-debian/
>
>
> --
> To UNSUBSCRIBE, email to [hidden email]
> with a subject of "unsubscribe". Trouble? Contact [hidden email]
>

--
 .''`.   martin f. krafft <[hidden email]>
: :'  :  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
 
"a mathematician is a device for turning coffee into theorems."
                                                         -- paul erdös

digital_signature_gpg.asc (196 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: How to handle Debian patches

Miriam Ruiz-2
2008/5/16 martin f krafft <[hidden email]>:
> Please Cc [hidden email] on this thread!

Done.

> also sprach Raphael Hertzog <[hidden email]> [2008.05.16.1654 +0100]:

>> Add to this that each patch should have some standardized header on top
>> stating:
>> - a description of the patch and its purpose
>> - the associated bug number
>> - who wrote the patch
>> - where it has been forwarded upstream
>> - sign-off by reviewers maybe
>>
>> Someone recently posted an example of this. IMO we should write a DEP
>> on patch management and standardize those headers. And probably enforce
>> their usage for patches on sensitive packages (lintian checks?).

Just for the record, I totally agree with Raphael. I guess this would
be something very useful to have and quite an improvement on the
situation.

Greetings,
Miry


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: How to handle Debian patches

Martin Uecker
In reply to this post by martin f krafft

martin f krafft <[hidden email]> wrote:

> [2] And IMO we should go further than patches.d.o, we need to create a
> cross-distro infrastructure where we can share patches. We really have to
> show the way here... (we complained enough that ubuntu patches were
> unusable, surely we can show how to do it right when it comes to
> sharing patches with others and upstream)

I am not convinced that more technological infrastructure is really
the solution. Isn't simply the upstream source the right place for
collaboration?

IMHO the problem is not, that managing and reviewing  patches in
debian or sharing patches with other is distributions is too hard,
but that it is *too easy* to introduce changes into Debian, removing
all pressure for close cooperation with the upstream project.

Regards,
Martin



signature.asc (196 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: How to handle Debian patches

Stefano Zacchiroli
On Fri, May 16, 2008 at 06:54:18PM +0200, Martin Uecker wrote:
> I am not convinced that more technological infrastructure is really
> the solution. Isn't simply the upstream source the right place for
> collaboration?

NACK, or better: ACK in theory, but not in practice. Sometime you have
wonderful upstreams which are willing to cooperate, reactive, and even
share with you the love for $DVCS so that you can already exchange patch
freely. But sometimes, most in my experience, this good properties do
not hold.

At that point you can really benefit in sharing patches across distros.

I've been doing it a handful of times with Fedora maintainers which are
working on OCaml packaging. They can easily point me to a single place
on the web where they have patches. And I've benefited from them, as in
the past they benefited from patches of mine. It happens that there are
patches that upstream is not willing to take (maybe just because he is
unreasonable) but in which more than one distro are interested [1].

On the contrary, as the Debian counterpart I cannot point them to a
single unified place where my patches are available. Or better, I can
but just because all OCaml packages are stored in a single svn
repository, with a clear defined policy of only using debian/patches/
and no patches to upstream sources in .diff.gz.

On a Debian-wide scale this kind of uniformity is not there: different
$VCS, different policies on what to put in .diff.gz and what not. I
think we will benefit a lot from a new unified patches.d.o
infrastructure which clearly shows what changes we have made to
software.

... and this is not only to ease code review which can diminish the risk
of future disasters like openssl, but also for share efforts with
others, probably the most important mantra of free software.

(i.e. full-ack on Raphael's post)

Cheers.

[1] if you want an example here is one: the library libcamlrun.so
implements the OCaml runtime systems as a shared object, if you have
installed OCaml you can find it in `ocamlc -where`. It is linked without
-fPIC by upstream which does not want to link it with because it slows
down performances (which is of course true). Upstream does not want
either to provide an additional library libcamlrun_shared.so linked with
-fPIC as it will be an extra lib to maintain. In Debian I'm now applying
a patch coming from Fedora which adds an extra library
libcamlrun_shared.so as there is software, like Apache modules, which
won't work if -fPIC is left aside

--
Stefano Zacchiroli -*- PhD in Computer Science ............... now what?
zack@{upsilon.cc,cs.unibo.it,debian.org}  -<%>-  http://upsilon.cc/zack/
(15:56:48)  Zack: e la demo dema ?    /\    All one has to do is hit the
(15:57:15)  Bac: no, la demo scema    \/    right keys at the right time

signature.asc (196 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: How to handle Debian patches

Donnie Berkholz-2
On 19:51 Fri 16 May     , Stefano Zacchiroli wrote:
> On the contrary, as the Debian counterpart I cannot point them to a
> single unified place where my patches are available. Or better, I can
> but just because all OCaml packages are stored in a single svn
> repository, with a clear defined policy of only using debian/patches/
> and no patches to upstream sources in .diff.gz.

http://patches.ubuntu.com/by-release/extracted/ contains patches for
both Debian and Ubuntu. It's quite useful.

Thanks,
Donnie

PS -- this might not make it to debian-devel if it doesn't allow
unsubscribed posters.


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: How to handle Debian patches

Goswin von Brederlow-2
In reply to this post by martin f krafft
martin f krafft <[hidden email]> writes:

> Please Cc [hidden email] on this thread!
>
> Including the full response for the list.
>
> also sprach Raphael Hertzog <[hidden email]> [2008.05.16.1654 +0100]:
>> Add to this that each patch should have some standardized header on top
>> stating:
>> - a description of the patch and its purpose
>> - the associated bug number
>> - who wrote the patch
>> - where it has been forwarded upstream
>> - sign-off by reviewers maybe
>>
>> Someone recently posted an example of this. IMO we should write a DEP
>> on patch management and standardize those headers. And probably enforce
>> their usage for patches on sensitive packages (lintian checks?).

It would be nice if dpkg-source would automatically create a header
template if missing and fork an editor whenever it changes a
patch. Maybe add a comment section with a diffstat of the last changes
that will be removed when exiting the editor for quick reference while
describing the change.

MfG
        Goswin


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: How to handle Debian patches

martin f krafft
In reply to this post by Donnie Berkholz-2
also sprach Donnie Berkholz <[hidden email]> [2008.05.16.1853 +0100]:
> http://patches.ubuntu.com/by-release/extracted/ contains patches
> for both Debian and Ubuntu. It's quite useful.

Lucas Nussbaum threw the idea of having a webpage with posisbly
annotated patches for each Debian package on *.debian.org at me the
other day, in response to the OpenSSL debacle. I really liked it!

It would be making it easy for everyone to look exactly at what we
change between upstream and us, and it would certainly help with
collaboration and QA.

Apologies if this has been mentioned before. I am currently swamped
and can't read along.

--
 .''`.   martin f. krafft <[hidden email]>
: :'  :  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
 
perl -e 'print "The earth is a disk!\n" if ( "earth" == "flat" );'

digital_signature_gpg.asc (196 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: How to handle Debian patches

Agustin Martin Domingo
In reply to this post by Raphael Hertzog-3
On Fri, May 16, 2008 at 05:54:32PM +0200, Raphael Hertzog wrote:
> Add to this that each patch should have some standardized header on top
> stating:
> - a description of the patch and its purpose
, including pointers to relevant discussions, if any.

The idea is that anyone reviewing the patch get easy access to as much
relevant info as possible, either if it is at a bug report or elsewhere.

--
Agustin


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: How to handle Debian patches

Joey Hess
In reply to this post by Raphael Hertzog-3
Raphael Hertzog wrote:
> I totally agree that we need to make our changes more visible. In the
> openssl case, the patch in question is inside the .diff.gz and you don't
> notice it in the unpacked source package. I tend to give a look to what's
> in debian/patches/ when I rebuild a package but not to what's in .diff.gz
> only.
>
> To me this one proof more than even when VCS are used to maintain
> packages, our source packages must clearly identify the Debian patches
> that are applied.

You're insinuatiog that a VCS does not allow easily browsing and
examining patches, and I just don't buy it.

> stating:
> - a description of the patch and its purpose
> - the associated bug number
> - who wrote the patch
> - where it has been forwarded upstream
> - sign-off by reviewers maybe

All stuff that you get essentially for free by committing to a VCS.

> [2] And IMO we should go further than patches.d.o, we need to create a
> cross-distro infrastructure where we can share patches. We really have to
> show the way here... (we complained enough that ubuntu patches were
> unusable, surely we can show how to do it right when it comes to sharing
> patches with others and upstream)

We didn't just complain that Ubuntu's patches were unusable, but that
their whole means of communication of them back to upstream, ie Debian,
was/is flawed. We [1] complained that automatically publishing patches was
not sufficient to get those patches integrated back into Debian because --

a) People cannot be expected to poll a directory somewhere for new
   patches.
   (Which Ubuntu has partially addressed, if your proposal does, it's
   not clear to me specifically how.)
b) Monolithic patches that make multiple changes are near-useless.
   (Which Ubuntu has not satisfactorally addressed, IMHO; I still get
   automated patch mails with multiple changes in them. Your propsal
   tries to address this.)
c) Patches lacked explanations of why changes were made, beyond the
   changelog, and it was difficult to figure out more.
   (Which Ubuntu has not particularly addressed, and I'm not sure your
   proposal addresses entirely..)
d) The best way to get good code is to go out and get in communication
   with upstream about it, explain the rationalle so that they can fully
   understand it, and take their advice into account.
   (Which Ubuntu maintainers generally still fail to do with Debian, and
   which your proposal doesn't really facilitate Debian doing more than
   we do now.)

I can certianly see some good benefits to the lines that you're
thinking, but if this turns into a pile of patches on a website that
upstream has to manually go find, and rarely does, and a lot of busywork
keeping the patches up-to-date, and maintaining redundant metadata ... then
why would I want to use that when I can shoot a mail off to upstream
with a git-format-patch in it?

--
see shy jo

[1] specifically, me

signature.asc (196 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: How to handle Debian patches

Josselin Mouette
Le vendredi 16 mai 2008 à 16:04 -0400, Joey Hess a écrit :
> You're insinuatiog that a VCS does not allow easily browsing and
> examining patches, and I just don't buy it.

I can do more than insinuating: a VCS does not allow easily browsing and
examining patches. It doesn’t prevent it, but solely, it is not
sufficient.

--
 .''`.
: :' :      We are debian.org. Lower your prices, surrender your code.
`. `'       We will add your hardware and software distinctiveness to
  `-        our own. Resistance is futile.

signature.asc (196 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: How to handle Debian patches

George Danchev
In reply to this post by Joey Hess
On Friday 16 May 2008, Joey Hess wrote:

> Raphael Hertzog wrote:
> > I totally agree that we need to make our changes more visible. In the
> > openssl case, the patch in question is inside the .diff.gz and you don't
> > notice it in the unpacked source package. I tend to give a look to what's
> > in debian/patches/ when I rebuild a package but not to what's in .diff.gz
> > only.
> >
> > To me this one proof more than even when VCS are used to maintain
> > packages, our source packages must clearly identify the Debian patches
> > that are applied.
>
> You're insinuatiog that a VCS does not allow easily browsing and
> examining patches, and I just don't buy it.

This is true, but not always handy. What you might buy is that the upstream or
resp. debian user is not supposed to know for your kind of VCS (having it
installed, etc) and where to find your VCS repo -- a ftp'ing of diff.gz or
apt-get source pkg should be enough to get the *clearly identified patches*
to the upstream source tree.

--
pub 4096R/0E4BD0AB 2003-03-18 <people.fccf.net/danchev/key pgp.mit.edu>
fingerprint 1AE7 7C66 0A26 5BFF DF22 5D55 1C57 0C89 0E4B D0AB


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: How to handle Debian patches

Joey Hess
In reply to this post by Josselin Mouette
Josselin Mouette wrote:
> Le vendredi 16 mai 2008 à 16:04 -0400, Joey Hess a écrit :
> > You're insinuatiog that a VCS does not allow easily browsing and
> > examining patches, and I just don't buy it.
>
> I can do more than insinuating: a VCS does not allow easily browsing and
> examining patches. It doesn’t prevent it, but solely, it is not
> sufficient.

Just like a debian/patches is far from sufficient for presenting patches
in a generally usable or understandable format, which is why Raphael is
suggesting to add extra metadata to it.


Coming up with a complex set of requirements that everyone has to follow
up front in their workflow[1] is not going to yeld the best results, and
I think that's my core reason for disliking Raphael's proposal. Now, if
you can come up with protocols/interfaces that can be used to
publish/communicate patches, that are managed/generated in whatever way
is most useful for the maintainer, that seems more likely to work.

--
see shy jo

[1] I hate using this word, but I think you know what I mean.

signature.asc (196 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: How to handle Debian patches

George Danchev
On Friday 16 May 2008, Joey Hess wrote:

> Josselin Mouette wrote:
> > Le vendredi 16 mai 2008 à 16:04 -0400, Joey Hess a écrit :
> > > You're insinuatiog that a VCS does not allow easily browsing and
> > > examining patches, and I just don't buy it.
> >
> > I can do more than insinuating: a VCS does not allow easily browsing and
> > examining patches. It doesn’t prevent it, but solely, it is not
> > sufficient.
>
> Just like a debian/patches is far from sufficient for presenting patches
> in a generally usable or understandable format

How so ? I have seen several times non-Debian upstream developers downloading
diff.gz from packages.debian.org (which is quite popular location) gunzip and
patch < diff, then having a look at *.patch files, and they know what has
been changed to their particular upstream version (unless orig.tar.gz is not
orig anymore, which could be the sad part of the story).

> Coming up with a complex set of requirements that everyone has to follow
> up front in their workflow[1] is not going to yeld the best results, and
> I think that's my core reason for disliking Raphael's proposal. Now, if
> you can come up with protocols/interfaces that can be used to
> publish/communicate patches, that are managed/generated in whatever way
> is most useful for the maintainer, that seems more likely to work.

I personally don't think there is any need for new infrastrutures. We only
need to follow some simple rules, i.e. orig.tar.gz should be really the
original upstream source; diff.gz (debian/patches/ included) is what the
debian developer added to it.

--
pub 4096R/0E4BD0AB 2003-03-18 <people.fccf.net/danchev/key pgp.mit.edu>
fingerprint 1AE7 7C66 0A26 5BFF DF22 5D55 1C57 0C89 0E4B D0AB


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: How to handle Debian patches

Adam Majer-2
In reply to this post by Josselin Mouette
Josselin Mouette wrote:
> Le vendredi 16 mai 2008 à 16:04 -0400, Joey Hess a écrit :
>> You're insinuatiog that a VCS does not allow easily browsing and
>> examining patches, and I just don't buy it.
>
> I can do more than insinuating: a VCS does not allow easily browsing and
> examining patches. It doesn’t prevent it, but solely, it is not
> sufficient.

git.debian.org

Seems very clear to me. Same patch changes as upstream for small
projects like Linux.

Clear patches are not because of VCS, but because of clear and concisely
described changesets. If you have patches with bad descriptions or a
giant blob in VCS, then that is useless not because of the failure of
VCS, but the failure of the developer.

Cheers,
Adam


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: How to handle Debian patches

Russ Allbery-2
Adam Majer <[hidden email]> writes:

> Clear patches are not because of VCS, but because of clear and concisely
> described changesets. If you have patches with bad descriptions or a
> giant blob in VCS, then that is useless not because of the failure of
> VCS, but the failure of the developer.

And by changeset in this context, referring to Git, you mean a branch?

The description part is exactly the part that I don't know how to solve
easily using Git unless the solution is to rebase everything and amend
commits, which is a really annoying and substandard workflow.  If I'm
going to do that, I'd rather just use quilt, since then the workflow is
the same as quilt and quilt is better at it.  The useful part of Git is
the merging and branching support; if I'm not going to merge branches,
there doesn't seem to be a lot of point.  But merges mean that there are
no longer simple commits in the Git repository that one can point to.

How does upstream easily get the complete description of a change that I
have in a Git repository for packaging their software?  What should I be
doing to help with that?

--
Russ Allbery ([hidden email])               <http://www.eyrie.org/~eagle/>


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: How to handle Debian patches

Manoj Srivastava
In reply to this post by Josselin Mouette
On Fri, 16 May 2008 22:10:36 +0200, Josselin Mouette <[hidden email]> said:

> Le vendredi 16 mai 2008 à 16:04 -0400, Joey Hess a écrit :
>> You're insinuatiog that a VCS does not allow easily browsing and
>> examining patches, and I just don't buy it.

> I can do more than insinuating: a VCS does not allow easily browsing
> and examining patches. It doesn’t prevent it, but solely, it is not
> sufficient.

        I am not sure I can agree. I find examining a single patch deep
 down in a quilt series very hard, unless I learn and use quilt, since
 the patches are all linearized, and each patch is dependent on th
 previous patch.

        diffing the tips of branches in a SCM has been far more
 friendly.  So I find my old and new SCM's preferable to a quilt
 series -- since any feature can be compared to any other feature, or
 upstream, independently, and easily; this is terribly hard to do with
 quilt.

        manoj
--
"God is a comedian playing to an audience too afraid to laugh." Voltaire
Manoj Srivastava <[hidden email]> <http://www.debian.org/~srivasta/>  
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: How to handle Debian patches

Manoj Srivastava
In reply to this post by George Danchev
On Fri, 16 May 2008 23:27:03 +0300, George Danchev <[hidden email]> said:

> On Friday 16 May 2008, Joey Hess wrote:
>> Raphael Hertzog wrote:
>> > I totally agree that we need to make our changes more visible. In
>> > the openssl case, the patch in question is inside the .diff.gz and
>> > you don't notice it in the unpacked source package. I tend to give
>> > a look to what's in debian/patches/ when I rebuild a package but
>> > not to what's in .diff.gz only.
>> >
>> > To me this one proof more than even when VCS are used to maintain
>> > packages, our source packages must clearly identify the Debian
>> > patches that are applied.
>>
>> You're insinuatiog that a VCS does not allow easily browsing and
>> examining patches, and I just don't buy it.

> This is true, but not always handy. What you might buy is that the
> upstream or resp. debian user is not supposed to know for your kind of
> VCS (having it installed, etc) and where to find your VCS repo -- a

        I find this to be true for quilt too. How does one extract what
 the 057th patch does, without examining all the leading patches up to
 that point? Linearizing features and intermixing integration changes
 along with feature-sets  is something I have always found confusing.

> ftp'ing of diff.gz or apt-get source pkg should be enough to get the
> *clearly identified patches* to the upstream source tree.

        I find a quilt series to not fit the bill very well. On the
 other hand, creating ./debian/topics/foo/  with a git-format-patch
 series for each branch in there might be doable -- but then, these
 individual patches might not apply cleanly over each other.

        manoj
--
Life is a series of rude awakenings. R.V. Winkle
Manoj Srivastava <[hidden email]> <http://www.debian.org/~srivasta/>  
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: How to handle Debian patches

Raphael Hertzog-3
In reply to this post by Joey Hess
On Fri, 16 May 2008, Joey Hess wrote:
> Raphael Hertzog wrote:
> > To me this one proof more than even when VCS are used to maintain
> > packages, our source packages must clearly identify the Debian patches
> > that are applied.
>
> You're insinuatiog that a VCS does not allow easily browsing and
> examining patches, and I just don't buy it.

A VCS surely allows browsing and examining patches. But when I dig in a
VCS history, it's because I have something precise to look up, I will
rarely check it ouf of curiosity. debian/patches/ on the contrary is
something that gets my attention when I unpack a source package.

The other part of the problem depends on the workflow used within your
VCS. As Russ explained, if you use topic branch to keep logical changes,
then you have several relevant commits spread in the middle of multiple
upstream commits and you don't have a single description of the branch
itself.

But don't get me wrong, I'm not opposed to using VCS for package
maintainance (I do it!), I just think that we haven't found the perfect
workflow yet.

Ideally, I'd like something where I maintain my upstream changes in topic
branches and the Debian branch would be another topic branch that just
adds the debian directory (without debian/patches) and debian/patches/ is
auto-generated from the set of topic branches. For this, we probably need
to give some hints to the tool that will create the source package. Those
hints could be in a file debian/source/patch-generation and would contain
the (ordered) list of topic branches with its description and any other
required meta-information.

I know that it will not always work if we have strong dependencies between
the topic branches but I'm not sure we have to optimize for that case as
it shouldn't happen to often, and I prefer such a tool that work in 80% of
the cases than no tool at all and continue with a package that consist of
a giant patch mixing multiple stuff. (Or maybe we'll find a way to make it
work in all cases, that would be even better... maybe we have to define
and respect some relationship betwen the topic branches, have topic branch
B be always based on A, and C on B, etc. so that diff between A-B, and
B-C always end up being applicable one after the other)

> > stating:
> > - a description of the patch and its purpose
> > - the associated bug number
> > - who wrote the patch
> > - where it has been forwarded upstream
> > - sign-off by reviewers maybe
>
> All stuff that you get essentially for free by committing to a VCS.

If that's the case, you can auto-generate that information at the same
time when you generate the patches corresponding to your various branches.
It's great!

> I can certianly see some good benefits to the lines that you're
> thinking, but if this turns into a pile of patches on a website that
> upstream has to manually go find, and rarely does, and a lot of busywork
> keeping the patches up-to-date, and maintaining redundant metadata ... then
> why would I want to use that when I can shoot a mail off to upstream
> with a git-format-patch in it?

Certainly patches.d.o is not meant to replace direct interaction with
upstream developers but it would be a nice service for upstream developers
when the debian maintainer sucks (and it happens...) and also for other
distributions that can benefit from our work.

But when we give away patches, we also like to get patches from other back
so that's why I believe that if we design any patch sharing
infrastructure, we must open it from the beginning to other distributions
so that we actually benefit from it too.

Cheers,
--
Raphaël Hertzog

Le best-seller français mis à jour pour Debian Etch :
http://www.ouaza.com/livre/admin-debian/


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: How to handle Debian patches

Manoj Srivastava
In reply to this post by Russ Allbery-2
On Fri, 16 May 2008 14:39:56 -0700, Russ Allbery <[hidden email]> said:

> Adam Majer <[hidden email]> writes:
>> Clear patches are not because of VCS, but because of clear and
>> concisely described changesets. If you have patches with bad
>> descriptions or a giant blob in VCS, then that is useless not because
>> of the failure of VCS, but the failure of the developer.

> And by changeset in this context, referring to Git, you mean a branch?

> The description part is exactly the part that I don't know how to
> solve easily using Git unless the solution is to rebase everything and
> amend commits, which is a really annoying and substandard workflow.
> If I'm going to do that, I'd rather just use quilt, since then the
> workflow is the same as quilt and quilt is better at it.  The useful
> part of Git is the merging and branching support; if I'm not going to
> merge branches, there doesn't seem to be a lot of point.  But merges
> mean that there are no longer simple commits in the Git repository
> that one can point to.

> How does upstream easily get the complete description of a change that
> I have in a Git repository for packaging their software?  What should
> I be doing to help with that?

        Create a submission branch. There are two audiences for your
 work; one is downstream (which includes the integration branch for
 Debian), the other is upstream, one audience does not like rebases, the
 other thrives on it. See
  http://www.golden-gryphon.com/software/misc/packaging.html#sec-5.4
 for details on this scheme.

        manoj
--
The difference between dogs and cats is that dogs come when they're
called.  Cats take a message and get back to you.
Manoj Srivastava <[hidden email]> <http://www.debian.org/~srivasta/>  
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]

1234 ... 8