On Wed, May 28, 2008 at 07:57:03PM -0500, Raphael Geissert wrote:
You can imagine harvesting alioth.d.o and extracting all debian/control
stored in whatever $VCS you find there, but you can't be sure if this is
the currently used $VCS, if there are other versions of the package
versioned
Stefano Zacchiroli wrote:
On Wed, May 28, 2008 at 07:57:03PM -0500, Raphael Geissert wrote:
You can imagine harvesting alioth.d.o and extracting all debian/control
stored in whatever $VCS you find there, but you can't be sure if this
is the currently used $VCS, if there are other versions
Stefano Zacchiroli wrote:
On Sat, May 17, 2008 at 02:26:29PM -0400, Joey Hess wrote:
I think it's about time to file mass bugs on whatever packages are left
that use version control and lack the fields.
...
You can imagine harvesting alioth.d.o and extracting all debian/control
stored in
On Tue, 20 May 2008, Lars Wirzenius wrote:
I'm a fairly long-time Unix user. I find it much preferably when command
line tools are quiet by default when things are going well.
I completely agree. I just have the feeling that some points were raised
in the discussion that things are not going
Le mardi 20 mai 2008 à 23:03 -0500, Manoj Srivastava a écrit :
A quilt format package with a single combined patch. Get the
integration branch, get orig.tar.gz, build. dpkg-buildpackage will
automatically create a debian_version.patch for you. It is easy.
How is this better than
ke, 2008-05-21 kello 09:09 +0200, Andreas Tille kirjoitti:
Would you regard this as a useful bug report or not?
I think that would be a rather excellently useful bug report. The only
way to improve it would be to include an actual patch to implement it.
--
To UNSUBSCRIBE, email to [EMAIL
On Wed, 21 May 2008, Lars Wirzenius wrote:
ke, 2008-05-21 kello 09:09 +0200, Andreas Tille kirjoitti:
Would you regard this as a useful bug report or not?
I think that would be a rather excellently useful bug report.
OK, so I will go on filing it this way.
The only
way to improve it
On Wed, 21 May 2008, Andreas Tille wrote:
Subject: Please provide an option to list patches outside debian directory
Please add a --verbose/-v option to 'dpkg-source -x' that performs
lsdiff -z -x '*/debian/*' *.diff.gz
to point potential maintainers / bug fixers to patches that
On Wed, 21 May 2008, Raphael Hertzog wrote:
Would you regard this as a useful bug report or not?
No.
Ups, it's just to late (#482166)
I'm currently evaluating a smooth transition from all orig+diff to the
3.0 (quilt) format and as such I'm not really interested in a new option
that only
Andreas Tille [EMAIL PROTECTED] writes:
On Wed, 21 May 2008, Raphael Hertzog wrote:
I'm currently evaluating a smooth transition from all orig+diff to
the 3.0 (quilt) format and as such I'm not really interested in a
new option that only makes sense for the old format that I hope to
On Wed, 21 May 2008, Andreas Tille wrote:
Hmmm, do you regard it as realistic that all maintainers will change to
a new format in Lenny+1? I do not think of maintainers who are in principle
not happy about this format but those who maintain packages that might stay
untouched perfectly fine
On Wed, 21 May 2008, Raphael Hertzog wrote:
Because if the new format is the default format built by dpkg-source, this
will happen automatically when you rebuild your packages...
Yes. But there is probably some statistics about packages that are not
rebuild inbetween two releases. I admit
Manoj Srivastava [EMAIL PROTECTED] writes:
On Mon, 19 May 2008 10:42:54 +0200, Goswin von Brederlow
[EMAIL PROTECTED] said:
Hmm. You say things like this:
Because the git format is imho conceptualy broken and the
implementation is far from completely thought out.
And
Pierre Habouzit [EMAIL PROTECTED] writes:
On Mon, May 19, 2008 at 04:06:36PM +, Manoj Srivastava wrote:
B) (This is an honest question). How many things can rerere remember? If
I use rerere to record how to resolve current conflicts in feature
branches, does the historical
Gunnar Wolf [EMAIL PROTECTED] writes:
Lucas Nussbaum dijo [Sat, May 17, 2008 at 02:37:31PM +0200]:
If I understand things correctly (but I'm really not sure I do), 3.0
(quilt) won't really help with that: it won't prevent maintainers to
directly modify files outside of debian/ , and generate
Le Mon, May 19, 2008 at 10:25:35PM +0200, Bernd Eckenfels a écrit :
In article [EMAIL PROTECTED] you wrote:
give a hint about this. If patches are hidden anywhere in the upstream
code some developers fail to realise this and my suggestion might help
noticing this fact.
The debian Diff
ti, 2008-05-20 kello 00:01 +0200, Andreas Tille kirjoitti:
The debian Diff is not hiding patches in the upstream code. It is the
canonical place to publish them (at least for some (most?) of the debian
packages following policy).
Well, I'm DD for 10 years - I know this fact. But did you
On Sat, May 17, 2008 at 10:18:58PM +0100, Roger Leigh wrote:
The syntax for the fields also does not currently let you specify a
branch or tag, it's just the whole repo. Personally, I'd like it to
allow specification of the branch/tag used to produce the specific
release of the package in
On Mon, May 19, 2008 at 09:58:55AM -0500, Manoj Srivastava wrote:
And then you go saying things like that:
It is trivial to generate a quilt format package from git/arch/hg/svn
and I'm sure there will be a RCS-build-package soon enough that does
that.
This can not happen
On Tue, May 20, 2008 at 06:07:14AM +, Goswin von Brederlow wrote:
How do you tell git-rerere to keep all conflict resolutions needed to
convert feature branches into a patch series but not others?
I was merely answering a first set of questions, for the rest please
read documentation
Goswin von Brederlow dijo [Tue, May 20, 2008 at 08:10:05AM +0200]:
If I understand things correctly (but I'm really not sure I do), 3.0
(quilt) won't really help with that: it won't prevent maintainers to
directly modify files outside of debian/ , and generate a huge
In article [EMAIL PROTECTED] you wrote:
modified. A quick inspection shows that for most of them the only change
is the path to Perl in the first line.
Yes, and I really wonder why they are using local perl and removing the -w
flag. Both is against best practise. I was actually asuming while
On Tue, 20 May 2008 08:00:48 +0200, Goswin von Brederlow [EMAIL PROTECTED]
said:
Manoj Srivastava [EMAIL PROTECTED] writes:
On Mon, 19 May 2008 10:42:54 +0200, Goswin von Brederlow
[EMAIL PROTECTED] said:
Hmm. You say things like this:
Because the git format is imho conceptualy broken
On Tue, 20 May 2008 00:44:44 +0200, Stefano Zacchiroli [EMAIL PROTECTED]
said:
On Mon, May 19, 2008 at 09:58:55AM -0500, Manoj Srivastava wrote:
And then you go saying things like that:
It is trivial to generate a quilt format package from
git/arch/hg/svn and I'm sure there will be a
Stefano Zacchiroli [EMAIL PROTECTED] writes:
The remaining ones will indeed need manual intervention, but aren't
this kind of changes those which are supposed to be pushed upstream?
So some more burden on the developer on these rare (if you buy my
statement above) cases can even be beneficial
Josselin Mouette [EMAIL PROTECTED] writes:
Le dimanche 18 mai 2008 à 12:00 +0200, Raphael Hertzog a écrit :
As a Debian package maintainer however I'm convinced that we'd be better
served by having only native + 3.0 quilt. The VCS comes _before_ the
source package and the source package is
On Mon, 19 May 2008, Goswin von Brederlow wrote:
Josselin Mouette [EMAIL PROTECTED] writes:
Le dimanche 18 mai 2008 à 12:00 +0200, Raphael Hertzog a écrit :
As a Debian package maintainer however I'm convinced that we'd be better
served by having only native + 3.0 quilt. The VCS comes
On Mon, 19 May 2008, Bernd Eckenfels wrote:
I dont see a reason why the normal unpack action should spam the user.
If a user feels spammed there might be means to switch this off. A command
line option that reduces the verbosity comes to mind even /dev/null might be
a place to foreward this
Raphael Hertzog [EMAIL PROTECTED] writes:
On Mon, 19 May 2008, Goswin von Brederlow wrote:
Josselin Mouette [EMAIL PROTECTED] writes:
Le dimanche 18 mai 2008 à 12:00 +0200, Raphael Hertzog a écrit :
As a Debian package maintainer however I'm convinced that we'd be better
served by
2008/5/19 Goswin von Brederlow [EMAIL PROTECTED]:
Because the git format is imho conceptualy broken and the
implementation is far from completely thought out. The strongest
point against it is that the user has to learn git to use it.
I'm curious about this. Why is it conceptualy broken and
On Mon, May 19, 2008 at 10:55:00AM +0200, Miriam Ruiz wrote:
2008/5/19 Goswin von Brederlow [EMAIL PROTECTED]:
Because the git format is imho conceptualy broken and the
implementation is far from completely thought out. The strongest
point against it is that the user has to learn git to
Miriam Ruiz [EMAIL PROTECTED] writes:
2008/5/19 Goswin von Brederlow [EMAIL PROTECTED]:
Because the git format is imho conceptualy broken and the
implementation is far from completely thought out. The strongest
point against it is that the user has to learn git to use it.
I'm curious about
On Mon, 19 May 2008 09:20:11 +0200 (CEST), Andreas Tille [EMAIL PROTECTED]
said:
If you care about the changes, just use the command. You can even
have an alias if you prefer that.
BTW:
+++ openssl-0.9.8g/Makefile
+++ openssl-0.9.8g/Configure
+++ ... (50 lines deleted)
+++
On Mon, 19 May 2008 10:42:54 +0200, Goswin von Brederlow
[EMAIL PROTECTED] said:
Hmm. You say things like this:
Because the git format is imho conceptualy broken and the
implementation is far from completely thought out.
And then you go saying things like that:
It is
On Mon, May 19, 2008 at 03:29:13PM +, Mike Hommey wrote:
On Mon, May 19, 2008 at 09:58:55AM -0500, Manoj Srivastava wrote:
On Mon, 19 May 2008 10:42:54 +0200, Goswin von Brederlow
[EMAIL PROTECTED] said:
Hmm. You say things like this:
Because the git format is imho
On Mon, May 19, 2008 at 09:58:55AM -0500, Manoj Srivastava wrote:
On Mon, 19 May 2008 10:42:54 +0200, Goswin von Brederlow
[EMAIL PROTECTED] said:
Hmm. You say things like this:
Because the git format is imho conceptualy broken and the
implementation is far from completely
On Mon, 19 May 2008 17:29:13 +0200, Mike Hommey [EMAIL PROTECTED] said:
On Mon, May 19, 2008 at 09:58:55AM -0500, Manoj Srivastava wrote:
On Mon, 19 May 2008 10:42:54 +0200, Goswin von Brederlow
[EMAIL PROTECTED] said:
Hmm. You say things like this:
Because the git format is imho
On Mon, 19 May 2008, Manoj Srivastava wrote:
In that case, I fail to see why you are only interested in this
information if the maintainer did not use quilt. Seems like you should
be concerned about changes made to upstream, period, regardless of
whether the changes are recorded in
In article [EMAIL PROTECTED] you wrote:
give a hint about this. If patches are hidden anywhere in the upstream
code some developers fail to realise this and my suggestion might help
noticing this fact.
The debian Diff is not hiding patches in the upstream code. It is the
canonical place to
Lucas Nussbaum dijo [Sat, May 17, 2008 at 02:37:31PM +0200]:
If I understand things correctly (but I'm really not sure I do), 3.0
(quilt) won't really help with that: it won't prevent maintainers to
directly modify files outside of debian/ , and generate a huge
On Mon, 19 May 2008, Bernd Eckenfels wrote:
The debian Diff is not hiding patches in the upstream code. It is the
canonical place to publish them (at least for some (most?) of the debian
packages following policy).
Well, I'm DD for 10 years - I know this fact. But did you read about
habits
On Mon, May 19, 2008 at 04:06:36PM +, Manoj Srivastava wrote:
B) (This is an honest question). How many things can rerere remember? If
I use rerere to record how to resolve current conflicts in feature
branches, does the historical information get lost? (like, I use
rerere to help
Mike Hommey [EMAIL PROTECTED] writes:
On Mon, May 19, 2008 at 09:58:55AM -0500, Manoj Srivastava wrote:
On Mon, 19 May 2008 10:42:54 +0200, Goswin von Brederlow
[EMAIL PROTECTED] said:
It is trivial to generate a quilt format package from
git/arch/hg/svn and I'm sure there will be a
On Tue, 20 May 2008, Pierre Habouzit wrote:
git-rerere keeps recorded conflicts resolution for 60 days by default,
and it's configureable, and it needs to use git-gc (or git rerere gc) to
cleanse it, so if you don't, it just won't disappear.
I admit I realy don't care what your favourite VCS
su, 2008-05-18 kello 11:42 +1000, Ben Finney kirjoitti:
Joey Hess [EMAIL PROTECTED] writes:
I think it's about time to file mass bugs on whatever packages are
left that use version control and lack the fields.
How would the putative filer of these bugs determine which packages
are in
On Fri, 16 May 2008, 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
On Sun, 2008-05-18 at 09:51 +0200, Andreas Tille wrote:
On Fri, 16 May 2008, 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
On Sat, 17 May 2008, Joey Hess wrote:
Raphael Hertzog wrote:
On Fri, 16 May 2008, Joey Hess wrote:
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
On Sunday 18 May 2008, Mike Hommey wrote:
--cut--
You don't have to check it in revision control, you just have to be able
to generate them from revision control.
For .diff.gz, we already have tools to handle such files properly
(without duplicating their content), it's called quilt or
On Sun, May 18, 2008 at 11:19:31AM +0200, Raphael Hertzog wrote:
On Sat, 17 May 2008, Joey Hess wrote:
Raphael Hertzog wrote:
On Fri, 16 May 2008, Joey Hess wrote:
Coming up with a complex set of requirements that everyone has to follow
up front in their workflow[1] is not going to
On Sat, 17 May 2008, Lucas Nussbaum wrote:
On 16/05/08 at 17:54 +0200, Raphael Hertzog wrote:
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/.
If I understand things correctly
On Sat, 17 May 2008, Joey Hess wrote:
Lucas Nussbaum wrote:
At some point, we will need to find a way to decide which v3 format we
are going to choose in adddition to the v3 (native) format (with a GR?).
We can't afford to allow several different v3 formats to coexist.
The entire point
On Sun, 18 May 2008, Andreas Tille wrote:
On Fri, 16 May 2008, 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
Neil Williams [EMAIL PROTECTED] writes:
Incidentally, you can collapse the zgrep into lsdiff -z:
$ lsdiff -z *.diff.gz | grep -v debian
lsdiff -z -x '*/debian/*' *.diff.gz
--
Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/
--
To UNSUBSCRIBE, email to [EMAIL
Le dimanche 18 mai 2008 à 12:00 +0200, Raphael Hertzog a écrit :
As a Debian package maintainer however I'm convinced that we'd be better
served by having only native + 3.0 quilt. The VCS comes _before_ the
source package and the source package is just an export from the VCS.
However I think
Le samedi 17 mai 2008 à 22:55 -0400, Joey Hess a écrit :
Unless you serialize your changes, you cannot expect them to be
understandable for NMUers.
I have no idea what you're talking about WRT serialising changes.
This is what I’m concerned about. You’re so blinded by the coolness of
your
On 18/05/08 at 11:27 +0200, Mike Hommey wrote:
On Sun, May 18, 2008 at 11:19:31AM +0200, Raphael Hertzog wrote:
On Sat, 17 May 2008, Joey Hess wrote:
Raphael Hertzog wrote:
On Fri, 16 May 2008, Joey Hess wrote:
Coming up with a complex set of requirements that everyone has to
On Sun, May 18, 2008 at 04:44:29PM +0200, Lucas Nussbaum wrote:
On 18/05/08 at 11:27 +0200, Mike Hommey wrote:
On Sun, May 18, 2008 at 11:19:31AM +0200, Raphael Hertzog wrote:
On Sat, 17 May 2008, Joey Hess wrote:
Raphael Hertzog wrote:
On Fri, 16 May 2008, Joey Hess wrote:
On 18/05/08 at 16:48 +0200, Mike Hommey wrote:
On Sun, May 18, 2008 at 04:44:29PM +0200, Lucas Nussbaum wrote:
On 18/05/08 at 11:27 +0200, Mike Hommey wrote:
On Sun, May 18, 2008 at 11:19:31AM +0200, Raphael Hertzog wrote:
On Sat, 17 May 2008, Joey Hess wrote:
Raphael Hertzog wrote:
On Sun, May 18, 2008 at 04:54:28PM +0200, Lucas Nussbaum wrote:
On 18/05/08 at 16:48 +0200, Mike Hommey wrote:
On Sun, May 18, 2008 at 04:44:29PM +0200, Lucas Nussbaum wrote:
On 18/05/08 at 11:27 +0200, Mike Hommey wrote:
On Sun, May 18, 2008 at 11:19:31AM +0200, Raphael Hertzog wrote:
On Sun, 18 May 2008, Raphael Hertzog wrote:
With the 3.0 quilt format, dpkg-source -x will list each patch that it
applies (and since the debian directory is stored in a tarball and not in
a .diff, it always means _real_ changes contrary to the v1 format where we
always see the line applying
In article [EMAIL PROTECTED] you wrote:
lsdiff -z -x '*/debian/*' *.diff.gz
or whatever - as long as I get a list of patched files brought up to my
intention immediately.
I dont see a reason why the normal unpack action should spam the user. If
you care about the changes, just use the
On Sat, May 17, 2008 at 12:45:20AM +0200, Miriam Ruiz wrote:
2008/5/16 martin f krafft [EMAIL PROTECTED]:
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
On Fri, May 16, 2008 at 05:13:24PM -0500, Manoj Srivastava wrote:
On Fri, 16 May 2008 23:27:03 +0300, George Danchev [EMAIL PROTECTED] 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
On 17/05/2008, Charles Plessy wrote:
Other idea: when the package is produced through a workflow that uses
debian/patches, shipping them in /usr/share/doc/package/patches.
Do you really want that?
openoffice.org_2.4.0-6.diff.gz 82,595.1 kB
Not to mention all packages where an autoreconf run
Le vendredi 16 mai 2008 à 17:08 -0500, Manoj Srivastava a écrit :
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
On 17/05/08 at 00:45 +0200, Miriam Ruiz wrote:
2008/5/16 martin f krafft [EMAIL PROTECTED]:
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!
[I'm not subscribed to debian-devel, so feel free to cc me if you want
to keep me in the loop]
Le samedi 17 mai 2008, à 00:19 +0200, Raphael Hertzog a écrit :
On Fri, 16 May 2008, Joey Hess wrote:
I can certianly see some good benefits to the lines that you're
thinking, but if this turns
On 16/05/08 at 17:54 +0200, Raphael Hertzog wrote:
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/.
If I understand things correctly (but I'm really not sure I do), 3.0
(quilt) won't
On Fri, May 16, 2008 at 04:04:20PM -0400, 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
Le samedi 17 mai 2008 à 14:37 +0200, Lucas Nussbaum a écrit :
If I understand things correctly (but I'm really not sure I do), 3.0
(quilt) won't really help with that: it won't prevent maintainers to
directly modify files outside of debian/ , and generate a huge
On Fri, May 16, 2008 at 08:07:38PM +0200, Goswin von Brederlow wrote:
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
On Fri, May 16, 2008 at 04:04:20PM -0400, Joey Hess 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
On Sat, May 17, 2008 at 12:07:43PM +, Vincent Untz wrote:
[I'm not subscribed to debian-devel, so feel free to cc me if you want
to keep me in the loop]
done.
+ it also seems that some debian developers would prefer the VCS way
instead of patches.debian.org. Well, if all the debian
Le samedi 17 mai 2008, à 15:24 +0200, Pierre Habouzit a écrit :
On Sat, May 17, 2008 at 12:07:43PM +, Vincent Untz wrote:
[I'm not subscribed to debian-devel, so feel free to cc me if you want
to keep me in the loop]
done.
+ it also seems that some debian developers would prefer the
Le Sat, May 17, 2008 at 11:36:00AM +0200, Cyril Brulebois a écrit :
On 17/05/2008, Charles Plessy wrote:
Other idea: when the package is produced through a workflow that uses
debian/patches, shipping them in /usr/share/doc/package/patches.
Do you really want that?
Guillem Jover [EMAIL PROTECTED] writes:
On Fri, 2008-05-16 at 15:49:25 -0700, Russ Allbery wrote:
That would work, although it does... well, not double, but at least
increase the work for any branch that also has a submission branch,
since any upstream merge conflicts have to be resolved on
On Saturday 17 May 2008, Vincent Untz wrote:
Le samedi 17 mai 2008, à 15:24 +0200, Pierre Habouzit a écrit :
On Sat, May 17, 2008 at 12:07:43PM +, Vincent Untz wrote:
[I'm not subscribed to debian-devel, so feel free to cc me if you want
to keep me in the loop]
done.
+ it
On Sat, 17 May 2008 11:40:43 +0200, Josselin Mouette [EMAIL PROTECTED] said:
Le vendredi 16 mai 2008 à 17:08 -0500, Manoj Srivastava a écrit :
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
On Sat, 17 May 2008 15:24:13 +0200, Pierre Habouzit [EMAIL PROTECTED] said:
(publishing my branch in a gitweb) isn't normalized, and won't
probably ever be, or not under this form.
Don't you think that Vcs-Browse and Vcs-$SCN headers are
normalized ways for telling end users where
On Sat, May 17, 2008 at 11:51:22AM -0500, Manoj Srivastava wrote:
On Sat, 17 May 2008 11:40:43 +0200, Josselin Mouette [EMAIL PROTECTED]
said:
Le vendredi 16 mai 2008 à 17:08 -0500, Manoj Srivastava a écrit :
diffing the tips of branches in a SCM has been far more friendly. So
I find
On Sat, 17 May 2008 09:07:08 +0200, Mike Hommey [EMAIL PROTECTED] said:
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
George Danchev wrote:
Then comes even more, even Ben Laurie (as he writes in
his blog) with all his aggression missed to find the debian's pkg-openssl VCS
repo [1] unless he has been helped by someone at some point. I'm not against
the VCS repo (I myself use some for my packaging), I just
On Fri, May 16, 2008 at 03:25:11PM -0700, Russ Allbery wrote:
In fact, despite being one of the big quilt advocates in the last round of
this discussion, I am at this point pretty much sold on using Git due to
its merges and branch support and have started to switch my packages over.
However,
On Saturday 17 May 2008, Joey Hess wrote:
George Danchev wrote:
Then comes even more, even Ben Laurie (as he writes in
his blog) with all his aggression missed to find the debian's pkg-openssl
VCS repo [1] unless he has been helped by someone at some point. I'm not
against the VCS repo (I
Raphael Hertzog wrote:
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
Theodore Tso wrote:
How often is a logical change more than just a single commit?
I think the most common case for me is when I need to bring the change
forward to new upstream versions (with conflicts). In that case, I'll
end up with multiple commits in the VCS hostory for the change.
So
Raphael Hertzog wrote:
On Fri, 16 May 2008, Joey Hess wrote:
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
Le samedi 17 mai 2008 à 11:51 -0500, Manoj Srivastava a écrit :
Diffing the tips of branches in a SCM will not show you which lines
were changed by which changeset. If you want that information - which
is one of the most useful ones, because the same file can be changed
for many different
Le samedi 17 mai 2008 à 15:12 -0400, Joey Hess a écrit :
Aren't patch files in debian/patches/ with some headers a defined
interface?
It's an interface, that if you stop there in defining it, means that I
have to check debian/patches/ into revision control, and bloat my
.diff.gz or
On Sat, May 17, 2008 at 02:26:29PM -0400, Joey Hess wrote:
George Danchev wrote:
Then comes even more, even Ben Laurie (as he writes in
his blog) with all his aggression missed to find the debian's pkg-openssl
VCS
repo [1] unless he has been helped by someone at some point. I'm not
Josselin Mouette wrote:
Are you deliberately omitting the sane formats to distribute patched
debian sources that are implemented?
I'm talking about the formats that I expect to be using. The implication
thst I'm somehow insane is not very useful.
--
see shy jo
signature.asc
Description:
On Sat, May 17, 2008 at 05:04:56PM +, Manoj Srivastava wrote:
On Sat, 17 May 2008 15:24:13 +0200, Pierre Habouzit [EMAIL PROTECTED] said:
(publishing my branch in a gitweb) isn't normalized, and won't
probably ever be, or not under this form.
Don't you think that
On Sat, May 17, 2008 at 07:05:20PM +, Joey Hess wrote:
And conversely, as upstream I'm git-aming patches emailed to me every
day from people from all over, including other distributions, and that
works quite well. The quality of the patches is often high since they are
worked up to the
On Sat, May 17, 2008 at 10:40:53PM +0200, Pierre Habouzit wrote:
On Sat, May 17, 2008 at 05:04:56PM +, Manoj Srivastava wrote:
On Sat, 17 May 2008 15:24:13 +0200, Pierre Habouzit [EMAIL PROTECTED]
said:
(publishing my branch in a gitweb) isn't normalized, and won't
probably
On Sat, May 17, 2008 at 08:49:39PM +, Mike Hommey wrote:
On Sat, May 17, 2008 at 10:40:53PM +0200, Pierre Habouzit wrote:
All in all, pointing to VCSes is just making things harder, because
you fight against direct product of VCSes, workflows, and almost
packages. And no tool is
Pierre Habouzit [EMAIL PROTECTED] writes:
On Sat, May 17, 2008 at 05:04:56PM +, Manoj Srivastava wrote:
On Sat, 17 May 2008 15:24:13 +0200, Pierre Habouzit [EMAIL PROTECTED]
said:
(publishing my branch in a gitweb) isn't normalized, and won't
probably ever be, or not under this
Theodore Tso [EMAIL PROTECTED] writes:
On Fri, May 16, 2008 at 03:25:11PM -0700, Russ Allbery wrote:
In fact, despite being one of the big quilt advocates in the last round
of this discussion, I am at this point pretty much sold on using Git
due to its merges and branch support and have
On Sat, May 17, 2008 at 02:26:29PM -0400, Joey Hess wrote:
I think it's about time to file mass bugs on whatever packages are left that
use version control and lack the fields.
Unfortunately this is not easy to do, as least not as mass bug filing.
Point is that it is not easy to spot which
On 17/05/08 at 23:00 +0200, Pierre Habouzit wrote:
On Sat, May 17, 2008 at 08:49:39PM +, Mike Hommey wrote:
On Sat, May 17, 2008 at 10:40:53PM +0200, Pierre Habouzit wrote:
All in all, pointing to VCSes is just making things harder, because
you fight against direct product of VCSes,
1 - 100 of 144 matches
Mail list logo
