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
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 alre
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 th
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 vie
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 UNSUBSCR
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
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 t
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 t
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*
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 ove
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
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
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 l
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
> >
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
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 migh
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 t
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
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 desi
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 mast
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 tea
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
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 somethi
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 massi
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 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 w
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 bra
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
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,
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 tr
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 l
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.
>>
>>
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, whic
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 inter
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,
> >>
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 i
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. I
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
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!!!
>
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 not sure this applies to dpkg, but in kernel land, the full reasoning
b
On Fri February 29 2008 08:11:17 Raphael Hertzog wrote:
> But Guillem wants to review and understand the code. In this process,
> he will rearrange the changes in smaller logical chunks.
Horses for courses.
A software engineering class would help Guillem get up to speed
without impacting Ian's pr
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.
Based on decades of software engineering experience, I would
ju
On Fri, 29 Feb 2008, Mark Brown wrote:
> On Thu, Feb 28, 2008 at 08:51:41PM +0100, Raphael Hertzog wrote:
> > On Thu, 28 Feb 2008, Ian Jackson wrote:
>
> > > Does this not also suffer from the problem that branches made from my
> > > triggers branch become unuseable or difficult to merge ?
>
> >
On Thu, Feb 28, 2008 at 08:51:41PM +0100, Raphael Hertzog wrote:
> On Thu, 28 Feb 2008, Ian Jackson wrote:
> > Does this not also suffer from the problem that branches made from my
> > triggers branch become unuseable or difficult to merge ?
> git merge --squash is more or less equivalent to appl
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 makes merging work properly.
>> >
>> > Insisting tha
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
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
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 ex
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 mainlin
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
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
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
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 does
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 25/02/2008, Pierre Habouzit wrote:
> What you want him to do is using:
>
> git rebase -i
Probably with -p.
--
Cyril Brulebois, who tried, w/o prior knowledge of the code.
pgpi79bZt6Ty5.pgp
Description: PGP signature
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 SC
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 gi
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
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 t
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
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, 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
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 p
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 p
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
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.
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' b
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 p
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.
>
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 agreemen
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 absol
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 h
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 o
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, 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 y
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,
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 therefor
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 forth, allegedly
> > in order to make my change
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 precisely the git bikeshedding I was ta
79 matches
Mail list logo
