GRaphael Hertzog writes (Re: git bikeshedding (Re: triggers in dpkg, and dpkg
maintenance)):
Either do the supplementary work or wait patiently with some _friendly_
nagging from time to time.
The supplementary work to fix up my flex branch ? But this is
precisely what using a drcs is supposed
On Wed, Mar 05, 2008 at 12:55:00AM -0300, Henrique de Moraes Holschuh wrote:
Isn't this going way out of proportion? That's the first I hear from any
*refuses* to merge, as opposed to the merge not going to be done the way I
would like it to happen, and it is taking too long for it to get
Henrique de Moraes Holschuh writes (Re: git bikeshedding (Re: triggers in
dpkg, and dpkg maintenance)):
On Tue, 04 Mar 2008, Mike Bird wrote:
Raphael seems to have the power to block your packages but he has
no rational excuse. Can the tech committee overrule Raphael or
does Debian need
Clint Adams writes (Re: git bikeshedding (Re: triggers in dpkg, and dpkg
maintenance)):
On Wed, Mar 05, 2008 at 12:55:00AM -0300, Henrique de Moraes Holschuh wrote:
Isn't this going way out of proportion? That's the first I hear from any
*refuses* to merge, as opposed to the merge not going
On Wed, 05 Mar 2008, Ian Jackson wrote:
What's the difference, really? Isn't it a case of people on all sides
trying to control each other instead of cooperating?
What would you like me to do ?
Either do the supplementary work or wait patiently with some _friendly_
nagging from time to
On Wed March 5 2008 12:29:08 Raphael Hertzog wrote:
I've been added to dpkg's Uploader a few weeks ago, I'm not dpkg's main
coordinator. I have no veto power, I was mainly trying to give my view
of the situation ...
May I suggest then that if no dpkg maintainer objects here
within 48 hours
Mike Bird [EMAIL PROTECTED] writes:
On Wed March 5 2008 12:29:08 Raphael Hertzog wrote:
I've been added to dpkg's Uploader a few weeks ago, I'm not dpkg's main
coordinator. I have no veto power, I was mainly trying to give my view
of the situation ...
May I suggest then that if no dpkg
On Wed, Mar 05, 2008, Mike Bird wrote:
May I suggest then that if no dpkg maintainer objects here
within 48 hours that Ian should proceed with his update?
May you stop in the next hour giving executive advice when you're not
representing anybody whatsoever?
--
Loïc Minier
--
To
On Wed March 5 2008 13:30:06 Otavio Salvador wrote:
Mike Bird [EMAIL PROTECTED] writes:
On Wed March 5 2008 12:29:08 Raphael Hertzog wrote:
I've been added to dpkg's Uploader a few weeks ago, I'm not dpkg's main
coordinator. I have no veto power, I was mainly trying to give my view
of the
On Wed, 05 Mar 2008, Mike Bird wrote:
Please post the URL for this policy. I apologize if you've already
posted and I missed it, but Google couldn't find it for me.
http://wiki.debian.org/Teams/Dpkg/GitUsage
Now I would appreciate if you could stop spreading lies and aggressive
remarks in
On Wed March 5 2008 14:52:04 Raphael Hertzog wrote:
On Wed, 05 Mar 2008, Mike Bird wrote:
Please post the URL for this policy. I apologize if you've already
posted and I missed it, but Google couldn't find it for me.
http://wiki.debian.org/Teams/Dpkg/GitUsage
Hi Raphael,
I had already
Mark Brown writes (Re: git bikeshedding (Re: triggers in dpkg, and dpkg
maintenance)):
On Fri, Feb 29, 2008 at 05:11:17PM +0100, Raphael Hertzog wrote:
But Guillem wants to review and understand the code. In this process,
he will rearrange the changes in smaller logical chunks.
Ah
Mike Bird writes (Re: git bikeshedding (Re: triggers in dpkg, and dpkg
maintenance)):
On Fri February 29 2008 09:26:32 Henrique de Moraes Holschuh wrote:
That does not work well in large development teams.
I confess I've only worked on development teams ranging from one to a
few hundred
Raphael Hertzog writes (Re: git bikeshedding (Re: triggers in dpkg, and dpkg
maintenance)):
Now please let this thread die.
I agree that this thread needs to die.
Sadly before that happens you need to agree to two things:
* I will push the triggers changes into dpkg master
* I will rejoin
Henrique de Moraes Holschuh writes (Re: git bikeshedding (Re: triggers in
dpkg, and dpkg maintenance)):
On Sun, 02 Mar 2008, Mike Bird wrote:
I would argue that even in such cases a better form of insurance
would be a design specification, and that if a design specification
Now, that's
John Goerzen writes (Re: git bikeshedding (Re: triggers in dpkg, and dpkg
maintenance)):
On Friday 29 February 2008 6:16:59 am Otavio Salvador wrote:
That's why you should avoid using the branch as basis to others until
it's clean and also avoid to make it public (without a reason) too
also sprach Ian Jackson [EMAIL PROTECTED] [2008.02.24.1949 +0100]:
One should not rebase a git branch which has had other branches taken
from it, nor should one rebase a git branch which has ever been
published (at least, unless it has been published with a warning
announcing that it might be
On Tue March 4 2008 10:44:22 Ian Jackson wrote:
Of course this triggers feature has a proper specification. It was
discussed and agreed on debian-dpkg and now resides in the doc/
subdirectory of my dpkg triggers tree, which is what Raphael is
refusing to allow me to merge.
Raphael seems to
Mike Bird writes (Re: git bikeshedding (Re: triggers in dpkg, and dpkg
maintenance)):
On Tue March 4 2008 10:44:22 Ian Jackson wrote:
Of course this triggers feature has a proper specification. It was
discussed and agreed on debian-dpkg and now resides in the doc/
subdirectory of my dpkg
On Sun, 02 Mar 2008, Raphael Hertzog wrote:
I would never say that the barrier for new developers is low. I don't know
in which world Robert lives but dpkg is a complex piece of code and you
don't understand it in a few minutes.
As if everybody were experienced C hackers that have used
On Tue, 04 Mar 2008, Mike Bird wrote:
On Tue March 4 2008 10:44:22 Ian Jackson wrote:
Of course this triggers feature has a proper specification. It was
discussed and agreed on debian-dpkg and now resides in the doc/
subdirectory of my dpkg triggers tree, which is what Raphael is
Ian Jackson [EMAIL PROTECTED] writes:
John Goerzen writes (Re: git bikeshedding (Re: triggers in dpkg, and dpkg
maintenance)):
On Friday 29 February 2008 6:16:59 am Otavio Salvador wrote:
That's why you should avoid using the branch as basis to others until
it's clean and also avoid
On Sat March 1 2008 21:09:27 Henrique de Moraes Holschuh wrote:
So, every change in dpkg code is *always* completely obvious, and you never
need any extra information that is not in a comment?
Really?
If some dpkg team members cannot be trusted to comment their code,
then they cannot be
On Sun, 2008-03-02 at 02:09 -0300, Henrique de Moraes Holschuh wrote:
And I am completely *sure* it would not be irrelevant for me were I
debugging dpkg without a full, complete, dpkg-regular-developer level of
understanding of the code. Or if I were trying to understand how dpkg
works, so
On Sun, 02 Mar 2008, Robert Collins wrote:
On Sun, 2008-03-02 at 02:09 -0300, Henrique de Moraes Holschuh wrote:
And I am completely *sure* it would not be irrelevant for me were I
debugging dpkg without a full, complete, dpkg-regular-developer level of
understanding of the code. Or
On Sat, 2008-03-01 at 11:18 -0600, Manoj Srivastava wrote:
Now, having bisecability could be useful (I have never used a
bisect); I don't know what the effect of a version that does not
compile or is otherwise buggy would have on the work flow.
Depending on the treatment of
On Fri, Feb 29, 2008 at 08:22:51AM -0800, Mike Bird wrote:
On Fri February 29 2008 06:29:07 Otavio Salvador wrote:
I personally apply this same policy on repositories that I work and it
usually makes much easier logs to read.
I'm not a DD but I've been programming since 1963 when I was 7.
On Sun, 02 Mar 2008, Robert Collins wrote:
On Sun, 2008-03-02 at 02:09 -0300, Henrique de Moraes Holschuh wrote:
And I am completely *sure* it would not be irrelevant for me were I
debugging dpkg without a full, complete, dpkg-regular-developer level of
understanding of the code. Or if I
On Sun, 02 Mar 2008, Henrique de Moraes Holschuh wrote:
On Sun, 02 Mar 2008, Robert Collins wrote:
Well, when I sat down some years back to do a couple of things with
dpkg; I found no need to consult change logs to understand the current
code of the time. Perhaps its quality has massively
On Sun, 02 Mar 2008, Mike Bird wrote:
You've rattled on at great length without showing any value to git
logs beyond providing clues to a successor developer where a
predecessor falls under a bus part way through developing a feature.
That's still good enough for me. Seems that I got something
On Mon, Feb 25, 2008 at 12:19:33PM -0300, Otavio Salvador wrote:
Robert Collins [EMAIL PROTECTED] writes:
On Sun, 2008-02-24 at 16:46 -0300, Henrique de Moraes Holschuh wrote:
Yet, rebasing is still routinely performed in the Linux kernel
development.
What I find interesting and
On Fri, Feb 29, 2008 at 12:40:55PM +, Colin Watson wrote:
That's why you should avoid using the branch as basis to others until
it's clean and also avoid to make it public (without a reason) too.
This makes it more difficult to ask for review while the branch is in
progress, which is a
On Sat, 1 Mar 2008 11:07:54 -0500, Theodore Tso [EMAIL PROTECTED] said:
On Fri, Feb 29, 2008 at 12:40:55PM +, Colin Watson wrote:
That's why you should avoid using the branch as basis to others
until it's clean and also avoid to make it public (without a
reason) too.
This makes it
On Fri, 29 Feb 2008, Mike Bird wrote:
On Fri February 29 2008 09:26:32 Henrique de Moraes Holschuh wrote:
On Fri, 29 Feb 2008, Mike Bird wrote:
I'm not a DD but I've been programming since 1963 when I was 7.
Based on decades of software engineering experience, I would
just like to
On Fri, Feb 29, 2008 at 09:16:59AM -0300, Otavio Salvador wrote:
Ian Jackson [EMAIL PROTECTED] writes:
What I am trying to achieve is to use git in the proper way: that is,
in a way which makes merging work properly.
Insisting that I use git in a manner which makes merges break but
Ian Jackson [EMAIL PROTECTED] writes:
Raphael Hertzog writes (Re: git bikeshedding (Re: triggers in dpkg, and dpkg
maintenance)):
As soon as you edit commits, they'll get a new id, and thus you'll disrupt
merging.
As I thought.
What I am trying to achieve is to use git in the proper way
On Fri February 29 2008 09:26:32 Henrique de Moraes Holschuh wrote:
On Fri, 29 Feb 2008, Mike Bird wrote:
I'm not a DD but I've been programming since 1963 when I was 7.
Based on decades of software engineering experience, I would
just like to remind you to USE THE FSCKING SOURCE!!!
I am
On Fri, Feb 29, 2008 at 05:11:17PM +0100, Raphael Hertzog wrote:
But Guillem wants to review and understand the code. In this process,
he will rearrange the changes in smaller logical chunks.
Ah, the impression that has been created on the lists is more that the
patches were being NACKed and
Raphael Hertzog wrote:
Heh, anybody can blindly apply the patches corresponding to the branch
and attach to it a sane commit message. If that was the real problem, it
would most probably already be done and we wouldn't discuss here.
But Guillem wants to review and understand the code. In
On Friday 29 February 2008 6:16:59 am Otavio Salvador wrote:
Ian Jackson [EMAIL PROTECTED] writes:
Raphael Hertzog writes (Re: git bikeshedding (Re: triggers in dpkg, and
dpkg maintenance)):
As soon as you edit commits, they'll get a new id, and thus you'll
disrupt merging.
As I
On Friday 29 February 2008 8:29:07 am Otavio Salvador wrote:
Colin Watson [EMAIL PROTECTED] writes:
On Fri, Feb 29, 2008 at 09:16:59AM -0300, Otavio Salvador wrote:
Ian Jackson [EMAIL PROTECTED] writes:
What I am trying to achieve is to use git in the proper way: that is,
in a way which
Mark Brown writes (Re: git bikeshedding (Re: triggers in dpkg, and dpkg
maintenance)):
I've no idea if anyone involved would consider it acceptable but might
merging the triggers branch into the mainline with --squash be a
suitable comprimise? This would give a single commit discarding
Raphael Hertzog writes (Re: git bikeshedding (Re: triggers in dpkg, and dpkg
maintenance)):
As soon as you edit commits, they'll get a new id, and thus you'll disrupt
merging.
As I thought.
What I am trying to achieve is to use git in the proper way: that is,
in a way which makes merging
On Thu, 28 Feb 2008, Ian Jackson wrote:
Mark Brown writes (Re: git bikeshedding (Re: triggers in dpkg, and dpkg
maintenance)):
I've no idea if anyone involved would consider it acceptable but might
merging the triggers branch into the mainline with --squash be a
suitable comprimise
Ian Jackson writes (Re: git bikeshedding (Re: triggers in dpkg, and dpkg
maintenance)):
It is very unfortunate for git that most of its advocates want to
adopt these almost unmanageable development practices along with the
revision control software.
I'd like to expand on this, and partly
On Tue February 26 2008 2:05:50 pm Ian Jackson wrote:
It is very unfortunate for git that most of its advocates want to
adopt these almost unmanageable development practices along with the
revision control software.
Yes, I agree. And even more ironic that Linus himself doesn't think that
Pierre Habouzit writes (Re: git bikeshedding (Re: triggers in dpkg, and dpkg
maintenance)):
Raphael is wrong to ask you to rebase, he's _really_ wrong about that,
but *you* also are wrong to ask him to pull (aka fetch + merge). The
usual way is that _you_ merge the current state of dpkg
Raphael Hertzog writes (Re: git bikeshedding (Re: triggers in dpkg, and dpkg
maintenance)):
It starts with two very big commits touching almost all files
and is followed by many small commits which have ubuntu changelog entries
as commit log (and thus the summary line is useless).
It also
Henrique de Moraes Holschuh writes (Re: git bikeshedding (Re: triggers in
dpkg, and dpkg maintenance)):
Given that many of us work on the kernel, some of us are both upstream and
downstream in git, and therefore know *both* sides of the troubles and
advantages of git rebase quite well... I
Pierre Habouzit writes (Re: git bikeshedding (Re: triggers in dpkg, and dpkg
maintenance)):
Well, what you want him to do then is not rebasing onto master,
because that won't change that a single bit. And indeed I agree this
history is a complete mess, and an SCM abuse.
What you want
On 25/02/2008, Pierre Habouzit wrote:
What you want him to do is using:
git rebase -i his original branch point
Probably with -p.
--
Cyril Brulebois, who tried, w/o prior knowledge of the code.
pgpi79bZt6Ty5.pgp
Description: PGP signature
On Tue, Feb 26, 2008 at 07:09:46PM +, Ian Jackson wrote:
I will then merge mainline into my branch, do any conflict resolution
necessary, and give it a quick test to make sure nothing seems to have
been broken in the meantime. Then merging my branch back into
mainline is, as you say,
On Tue, 26 Feb 2008, Ian Jackson wrote:
But, is it really worth the effort to go back and edit revision logs
now ? And if I do so, will I disrupt merging any less than if I
rebase ?
As soon as you edit commits, they'll get a new id, and thus you'll disrupt
merging.
The thing that you
On Mon, 25 Feb 2008, Pierre Habouzit wrote:
I vote for clean history and a bissectable tree, and I think it is worth the
effort. But I am no dpkg developer, this is a thing you guys have to find
an agreement among yourselves.
You vote for the mad route. Sorry, but it makes absolutely
On Mon, Feb 25, 2008 at 08:38:03AM +, Raphael Hertzog wrote:
On Mon, 25 Feb 2008, Pierre Habouzit wrote:
I vote for clean history and a bissectable tree, and I think it is worth
the
effort. But I am no dpkg developer, this is a thing you guys have to find
an agreement among
Ian Jackson [EMAIL PROTECTED] writes:
Raphael Hertzog writes (Re: triggers in dpkg, and dpkg maintenance):
However you haven't made it easy to merge your code... you repository is a
mess to proof-read and the cleaning work that you don't want to do has
thus to be done by Guillem.
This is
Robert Collins [EMAIL PROTECTED] writes:
On Sun, 2008-02-24 at 16:46 -0300, Henrique de Moraes Holschuh wrote:
Yet, rebasing is still routinely performed in the Linux kernel
development.
What I find interesting and rather amusing here is Linus talking
negatively about rebase: in particular
Pierre Habouzit [EMAIL PROTECTED] writes:
...
And AFAICT, the kernel works in the very same way. What gets rebased
though, are the bugfixes patches that come by 2 or 3, and that add no
value when added as a specific branch. Usually those in git.git are
applied on top of the 'maint' branch
On Sun February 24 2008 1:46:59 pm Henrique de Moraes Holschuh wrote:
I vote for clean history and a bissectable tree, and I think it is worth
the effort. But I am no dpkg developer, this is a thing you guys have to
find an agreement among yourselves.
See [1] for why this behavior stinks.
On Mon February 25 2008 9:31:15 am Otavio Salvador wrote:
Right. Well said.
This however doesn't changes the value of logical changes. I doubt
git.git people would accept patches like:
Now it compiles again
Ouch! Syntax error
First try to get it done
...
It's much nicer to have
John Goerzen [EMAIL PROTECTED] writes:
Dirty history is not only tolerated, but the *only* sane option with,
lesse... rcs cvs svn darcs tla baz (bzr?)
Only the git and hg people seem to care (and the git people a lot more than
hg people).
After you get used to get branches with proper
On Mon, 2008-02-25 at 10:19 -0600, John Goerzen wrote:
Dirty history is not only tolerated, but the *only* sane option with,
lesse... rcs cvs svn darcs tla baz (bzr?)
bzr supports both ways of working, either cleaning up, or preserving
the history as is.
It has rebase support through a
On Mon, 25 Feb 2008, John Goerzen wrote:
On Mon February 25 2008 9:31:15 am Otavio Salvador wrote:
Right. Well said.
This however doesn't changes the value of logical changes. I doubt
git.git people would accept patches like:
Now it compiles again
Ouch! Syntax error
First try to
Henrique de Moraes Holschuh [EMAIL PROTECTED] writes:
Preserving history is part of it, but not the objective. Sometimes you just
have to plain clean up the mess, so as to be able to see anything of value
through it.
As people ofthen do when using file based ChangeLog. People doesn't
put:
On Mon, 2008-02-25 at 17:58 +, James Westby wrote:
On Mon, 2008-02-25 at 10:19 -0600, John Goerzen wrote:
Dirty history is not only tolerated, but the *only* sane option with,
lesse... rcs cvs svn darcs tla baz (bzr?)
bzr supports both ways of working, either cleaning up, or
On Sun, 24 Feb 2008, Ian Jackson wrote:
But for the reasons which were discussed at length on debian-dpkg in
October, this is not a good idea. Sadly I was not able to persuade
Raphael.
Given that many of us work on the kernel, some of us are both upstream and
downstream in git, and therefore
On Sun, 2008-02-24 at 16:46 -0300, Henrique de Moraes Holschuh wrote:
Yet, rebasing is still routinely performed in the Linux kernel
development.
What I find interesting and rather amusing here is Linus talking
negatively about rebase: in particular its propensity to turn tested
code (what
On Sun, Feb 24, 2008 at 06:49:10PM +, Ian Jackson wrote:
Jarg Sommer writes (Re: triggers in dpkg, and dpkg maintenance):
Ian Jackson [EMAIL PROTECTED] wrote:
24 Oct 2007 - Raphael Hertzog asks me to `git-rebase', edit the email
address in my git commit logs, and so
On Mon, 25 Feb 2008, Robert Collins wrote:
On Sun, 2008-02-24 at 16:46 -0300, Henrique de Moraes Holschuh wrote:
Yet, rebasing is still routinely performed in the Linux kernel
development.
What I find interesting and rather amusing here is Linus talking
negatively about rebase: in
On Sun, Feb 24, 2008 at 07:46:59PM +, Henrique de Moraes Holschuh wrote:
On Sun, 24 Feb 2008, Ian Jackson wrote:
But for the reasons which were discussed at length on debian-dpkg in
October, this is not a good idea. Sadly I was not able to persuade
Raphael.
Given that many of us
On Mon, 25 Feb 2008, Pierre Habouzit wrote:
For having worked quite a bit in git.git (I sent my 100th patch that
should go upstream on yesterday), I can tell that it's not true. I mean,
the very people designing git, are also the one using it in the kernel
developpement, and look at git
71 matches
Mail list logo
