Re: git bikeshedding (Re: triggers in dpkg, and dpkg maintenance)
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 to avoid as I've said. We're going round in circles here. I gave you my advice on the best way to help Guillem review and merge your work, that's all. Guillem was ill recently, hopefully he'll catch up soon and will be able to work on the merge of the triggers branch. So are you saying that we're just waiting for Guillem to say `yes' ? I think the time for Guillem to review my code has passed long since. Ian. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
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 to be done the way I would like it to happen, and it is taking too long for it to get merged. What's the difference, really? Isn't it a case of people on all sides trying to control each other instead of cooperating? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: git bikeshedding (Re: triggers in dpkg, and dpkg maintenance)
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 to fork a dpkg under more sensible maintainers? 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 merged. These changes have been ready for 6 months and the only thing preventing me from pushing and uploading them immediately is Raphael's objection. I don't even need him to do any work, just say `yes'. I think that is exactly blocking. Ian. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: git bikeshedding (Re: triggers in dpkg, and dpkg maintenance)
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 to be done the way I would like it to happen, and it is taking too long for it to get merged. 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 ? What Raphael is suggesting would result in extra real work for me: Not only do I have to rework my branch so that my revision logs are pretty the way he likes. I would also have to do additional substantial merge conflict resolution on my flex branch. This is the most error-prone part of coding. It would be completely unnecessary if he just says `yes'. I'm not trying to control Raphael at all. I just want his permission to go ahead and deploy this important work. Ian. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: git bikeshedding (Re: triggers in dpkg, and dpkg maintenance)
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 time. I'm not trying to control Raphael at all. I just want his permission to go ahead and deploy this important work. 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 (the alternative would have been to skip the thread and nobody from the dpkg team would have responded here because right from the beginning it was to be expected that the discussion was not going to be pleasant/productive). I gave you my advice on the best way to help Guillem review and merge your work, that's all. Guillem was ill recently, hopefully he'll catch up soon and will be able to work on the merge of the triggers branch. 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 [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: git bikeshedding (Re: triggers in dpkg, and dpkg maintenance)
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 that Ian should proceed with his update? --Mike Bird -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: git bikeshedding (Re: triggers in dpkg, and dpkg maintenance)
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 maintainer objects here within 48 hours that Ian should proceed with his update? Obviously NO. It's a team policy and noone outside of team should override it. -- O T A V I OS A L V A D O R - E-mail: [EMAIL PROTECTED] UIN: 5906116 GNU/Linux User: 239058 GPG ID: 49A5F855 Home Page: http://otavio.ossystems.com.br - Microsoft sells you Windows ... Linux gives you the whole house. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: git bikeshedding (Re: triggers in dpkg, and dpkg maintenance)
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 UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: git bikeshedding (Re: triggers in dpkg, and dpkg maintenance)
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 situation ... May I suggest then that if no dpkg maintainer objects here within 48 hours that Ian should proceed with his update? Obviously NO. It's a team policy and noone outside of team should override it. 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. The most recent I could find was from July 2007[0] wherein it states: We have currently no clear policies about commits. There are currently no clear policies about uploads ... . When was this changed to block Ian's work? Thanks, --Mike Bird [0] http://lists.debian.org/debian-dpkg/2007/07/msg00018.html -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: git bikeshedding (Re: triggers in dpkg, and dpkg maintenance)
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 this thread. Find something useful to contribute to Debian. -- Raphaël Hertzog Le best-seller français mis à jour pour Debian Etch : http://www.ouaza.com/livre/admin-debian/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: git bikeshedding (Re: triggers in dpkg, and dpkg maintenance)
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 seen that policy. The portions that apply to Ian are in fact recommendations rather than mandates. Even if misconstrued as mandates, that policy says that Ian can rebase as many times as he wants (zero?) and then merge. You're arguing that Ian has to rebase as many times as you want (one?). Where's the dpkg team policy that says Ian has to rebase? Thanks! Guillam last summer said that 24 hours to review a change might not be enough, and left us with the impression that 2 days or maybe a week would suffice. It was an opinion but not a policy. I have not found any policy that says Guillam should have six or more months to block a change. Particularly where the blocked change has been working without significant problems in Ubuntu for months. Where is the policy that says Guillam can block a change for six months? Thanks! Now I would appreciate if you could stop spreading lies and aggressive remarks in this thread. As of this writing it seems that it is in fact you that has mis-stated dpkg policy. Specifically: the policy to which you have posted a link does not state what you have claimed dpkg policy to be. Hopefully you are not a liar and that was only a mistake and you will now post a link which supports your claim. If not, please retract your mistaken claims concerning dpkg team policy and permit Ian to get on with improving Debian. Find something useful to contribute to Debian. Debunking the nonsense which has prevented Ian from improving Debian is a positive contribution. For an example of a negative contribution, consider the insecure programmers who have blocked Ian's excellent work for approximately six months. --Mike Bird -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: git bikeshedding (Re: triggers in dpkg, and dpkg maintenance)
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, the impression that has been created on the lists is more that the patches were being NACKed and wouldn't be looked at until the logs had been rewritten. That is exactly the situation. The changes have been stuck since August. In fact, what is needed is not the patches being looked at. They need to be committed. Anything reasonable that might be done to prove they were right has already been done. Waiting for the existing maintainers to review these changes is not reasonable, if for no other reason than that they have had 6 months to do so and have done nothing. Ian. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: git bikeshedding (Re: triggers in dpkg, and dpkg maintenance)
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 developers. dpkg has how many thousand developers? 0.003 thousand developers, +/- 0.001 thousand. Ian. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: git bikeshedding (Re: triggers in dpkg, and dpkg maintenance)
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 the dpkg team as a full member The dpkg team could have used all your energy in other more productive ways. It's not like we have a backlog of 500 bugs to handle... Fixes to some of which are languishing un-committed in my git branches. Ian. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: git bikeshedding (Re: triggers in dpkg, and dpkg maintenance)
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 something I'd like to see happening. I am used to design specifications ending up in the commit log (or not existing at all, which really pains me) when dealing with free software development. Well, I agree with you here. 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. Ian. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: git bikeshedding (Re: triggers in dpkg, and dpkg maintenance)
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. Whatever happened to release early, release often? Quite so. Also, Otavio is quite wrong to suggest that I shouldn't have based my experimental flex branch on the triggers branch. To do otherwise would have made conflicts inevitable because the two overlap; I would have had to do my flex work based on the old code and then do parts of them again, with a merge trainwreck to sort out. It is exactly that merge trainwreck which my workflow - which is the same as that adopted by nearly all users of every drcs except git - avoids. It is that workflow which the present `dpkg team' insist that they are unwilling to accept. It is a `policy' that they have `agreed' and in their view as a supplicant I should just knuckle down and obey it. Well, firstly the policy is wrong, and secondly I am not really interested in playing some game where I have to bow and scrape and do makework to prove myself. Ian. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: git bikeshedding (Re: triggers in dpkg, and dpkg maintenance)
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 rebased). Both of these practices lead to severe problems. I refuse to read the entire thread, so sorry if someone else has already suggested... ... leave your branch intact, but cherry pick all commits from it to a new branch off master. Then submit that patch. Once it's merged, you can rebase the new branch and it'll empty itself. Your old branch stays around, but it won't be used anymore since the triggers are now in dpkg mainline -- or in a feature branch in the main repo. -- .''`. martin f. krafft [EMAIL PROTECTED] : :' : 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 all i know is that i'm being sued for unfair business practices by micro$oft. hello pot? it's kettle on line two. -- michael robertson digital_signature_gpg.asc Description: Digital signature (see http://martin-krafft.net/gpg/)
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 triggers tree, which is what Raphael is refusing to allow me to merge. 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 to fork a dpkg under more sensible maintainers? --Mike Bird -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: git bikeshedding (Re: triggers in dpkg, and dpkg maintenance)
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 triggers tree, which is what Raphael is refusing to allow me to merge. 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 to fork a dpkg under more sensible maintainers? Well, I'm hoping to be able to persuade Raphael without completely destroying any chance of us working constructively together. Raphael has been doing much useful work which I want to see continue. I could appeal to the TC but sadly I think (with some shame, as a TC member) that this would be unlikely to yield an answer in time to deploy triggers in lenny, if at all. Also there is of course a conflict of interest for me personally which would make the whole thing look rather like self-dealing. I have considered mediation but I think really the answer that a decision is needed, not a helping hand to allow us to communicate. Our problems are not that Raphael and I are being rude to each other. The main problem is that we have an irreconcilable difference of opinion about workflow. Also, Raphael doesn't seem to trust my code. There are a couple of `nuclear buttons' that I could push: I could announce an intention to hijack dpkg, or I could declare myself upstream (or, very similarly, declare myself `master' in git terminology). These would be very unfriendly and I don't think they would lead to very good outcomes. Ian. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: git bikeshedding (Re: triggers in dpkg, and dpkg maintenance)
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 longjmp() so many times that anything else that comes up can only be easy to understand... In my book, if you can understand it in one month @ 8h/week playing with the code, it is good enough. Not so easy that people who just know enough to be dangerous will touch it, and not so hard as to require an itch borthering on titanic to get one to want to participate. And I sincerely hope anyone touching dpkg C source is damn good at programming in C. -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: git bikeshedding (Re: triggers in dpkg, and dpkg maintenance)
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 refusing to allow me to merge. 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 to fork a dpkg under more sensible maintainers? 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 merged. -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: git bikeshedding (Re: triggers in dpkg, and dpkg maintenance)
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 to make it public (without a reason) too. Whatever happened to release early, release often? Quite so. Also, Otavio is quite wrong to suggest that I shouldn't have based my experimental flex branch on the triggers branch. To do otherwise would have made conflicts inevitable because the two overlap; I would have had to do my flex work based on the old code and then do parts of them again, with a merge trainwreck to sort out. You can use them as basis but after they have been cleaned to useless commits and made logical. I do it all the time and it works fine. Also, doing that, is very simple to rebase your other branches against a new one. You could use git rebase --into. -- O T A V I OS A L V A D O R - E-mail: [EMAIL PROTECTED] UIN: 5906116 GNU/Linux User: 239058 GPG ID: 49A5F855 Home Page: http://otavio.ossystems.com.br - Microsoft sells you Windows ... Linux gives you the whole house. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: git bikeshedding (Re: triggers in dpkg, and dpkg maintenance)
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 trusted to log their changes. (Note that this is not an assertion as to the trustworthiness or otherwise of any or all dpkg team members.) 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. I would argue that even in such cases a better form of insurance would be a design specification, and that if a design specification is not warranted then the feature is trivial and it's better to discard the partially implemented trivial feature and have the new developer restart development of the trivial new feature from scratch. --Mike Bird -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: git bikeshedding (Re: triggers in dpkg, and dpkg maintenance)
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 as to start working on dpkg, for that matter. 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 decreased since; yet somehow I doubt that. -Rob -- GPG key available at: http://www.robertcollins.net/keys.txt. signature.asc Description: This is a digitally signed message part
Re: git bikeshedding (Re: triggers in dpkg, and dpkg maintenance)
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 were trying to understand how dpkg works, so as to start working on dpkg, for that matter. 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 decreased since; yet somehow I doubt that. VCS have improved over time and it makes sense to use them wisely to make it even easier to understand one's changes and to let even more people help out without having to spend hours to understand all parts of the code. There's no question of code quality, but simply of good work habits and of policy decided by the dpkg team. Now please let this thread die. The dpkg team could have used all your energy in other more productive ways. It's not like we have a backlog of 500 bugs to handle... 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 [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: git bikeshedding (Re: triggers in dpkg, and dpkg maintenance)
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 branches by the bisection tool it can cause false reports of the origin of a defect; this then increases the manual effort needed to find a problem. -Rob -- GPG key available at: http://www.robertcollins.net/keys.txt. signature.asc Description: This is a digitally signed message part
Re: git bikeshedding (Re: triggers in dpkg, and dpkg maintenance)
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. Based on decades of software engineering experience, I would just like to remind you to USE THE FSCKING SOURCE!!! Logs are not the source. No matter how much time you waste fiddling with them, they are really unimportant. Programmers need to see what the code is today. When bisecting a programmer may care what the code was yesterday. But no programmer cares all that much how some other programmer summarized some past state of the code. If there's anything important to know it should be documented in a design document or noted in a comment. And even those should be taken with a grain of salt. Time spent prettifying logs is time that could be better spent programming or packaging or playing with the grandkids. X is a 20 year old codebase with most of the little details of the code lost to the depths of time. We're forced to use the code (or what memory the older developers still have) for large chunks of the codebase, so I can empathize very much with what you're saying because it's the most important way to interact with the code. But I very much want justification for lots of the details when making changes and I wish we had a strong history going back those 20 years. Sortware like dpkg will probably be with us for another 30 years at the rate we're going. Who're you to say that the history in the logs won't be important? - David Nusinow -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: git bikeshedding (Re: triggers in dpkg, and dpkg maintenance)
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 were trying to understand how dpkg works, so as to start working on dpkg, for that matter. 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 decreased since; yet somehow I doubt that. That's certainly good to hear, it means the barrier for new developers is low, which is quite good. The same would hold for debugging? -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: git bikeshedding (Re: triggers in dpkg, and dpkg maintenance)
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 decreased since; yet somehow I doubt that. That's certainly good to hear, it means the barrier for new developers is low, which is quite good. The same would hold for debugging? 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 longjmp() so many times that anything else that comes up can only be easy to understand... 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 [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: git bikeshedding (Re: triggers in dpkg, and dpkg maintenance)
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 through to you, at least. 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 something I'd like to see happening. I am used to design specifications ending up in the commit log (or not existing at all, which really pains me) when dealing with free software development. Rarely will it be properly documented and added to the project tree. Often, any such specs are found in a mailinglist thread somewhere, which is even more decoupled from the code than a comment, commit log entry, or a text document somewhere in the project tree. is not warranted then the feature is trivial and it's better to discard the partially implemented trivial feature and have the new developer restart development of the trivial new feature from scratch. Now, that I agree with. -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: git bikeshedding (Re: triggers in dpkg, and dpkg maintenance)
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 rather amusing here is Linus talking negatively about rebase: in particular its propensity to turn tested code (what you actually committed) into untested code (what you committed + what someelse has done, in a version of a tree no human has ever evaluated for correctness). If people doesn't test and review the patches after rebasing, it looks right but everyone is suppose to test the changes after a merging (as for rebasing). I'll note that when I submit a branch, I prefer to do a rebase, and *then* do extensive testing. That's because for a new feature, I generally understand it better than the upstream maintaining, and *I* want to be the one doing the merge and testing after the fact, as opposed to assuming the upstream will do the appropriate merge fixups and testing. For big projects, this is essential, and Linus in fact does *not* test after doing a merge. (It doesn't scale for him to test after every single merge from his Lieutennants.) But for smaller projects, it should really be up to the submitter; I don't think there is any one Absolutely Right Way To Do It. If someone wants to rebase and then test before sending a pull request, I don't think there's anything wrong with that. Especially if the projects have a good regression test suite. (Both git and e2fsprogs have good regression tests, and that makes life *much* easier to test after doing a rebase or a merge; basically, I'll run the full regression test to make sure that anything unanticipated hasn't broken, and then do explicit testing about the feature being merged or rebased.) BTW, because of the regression test suite, and my general policy for e2fsprogs is that I want to make sure that make check has 0 failed tests after every single commit, rebasing to collapse and remove development history makes life easier to fulfill the fully git bisectable with 0 make check failures between every commit constraint. So as long as the person submitting the patch makes it clear that they have tested exactly what is being requested to be pulled, there's nothing wrong with whether or not they do the rebase right before sending the pull request. My preference is to do the rebase and test, and from a smaller project such as dpkg, I can't think of any good reason for the maintainer to force the submitters to follow one approach or another. Regards, - Ted -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: git bikeshedding (Re: triggers in dpkg, and dpkg maintenance)
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 valuable property. It is ridiculous to artificially avoid making branches public; a branch is a useful means of collaboration and we should take advantage of it as such. It's a bad idea to base work on a feature where the code is still being under review. Even if you keep all of the historical crap on the branch, to be preserved for ever, it's going to cause merge difficulties for people who base branches based on that patch which is under review. So you really, REALLY, don't want people basing work on code which is still being developed, since it may be that the review may include, why don't you totally refactoring the code *THIS* way, which will end up breaking everyone who depends on your new function interface anyway. So how to solve this problem? (a) Send patches via e-mail for review. This actually works better, because people can respond via e-mail much more easily than if it just shows up in a git repository. You can also send an explicit request for people to review the patch when it is sent via e-mail. (b) Put the patches on a git branch which is *guaranteed* to be constantly rewound, and is not to be used as a base for derived patches. By convention the 'pu' branch in the git (and e2fsprogs) source repository is declared to be one which is used only for people who want to test the latest bleeding edge code, but it should not be used as the basis of any derived or child branches. I have never once run into this problem with other revision control systems in which branching and merging are common. Somehow it just never seems to be a real issue. I contend that dpkg is not big enough for it to become a real issue. It's not a fatal issue, but in the long run, the code is more maintainable if the code revision history is clean. It's like having a few goto's in the code. Does that make the code unmaintainable? No. But it does make it worse. Or think about how much effort some of us spend to make the code gcc -Wall free of warnings. Does not doing it make the code fundamentally bad? No. Is it still worth doing? Many of us believe that it is worth doing, nevertheless. - Ted -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: git bikeshedding (Re: triggers in dpkg, and dpkg maintenance)
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 more difficult to ask for review while the branch is in progress, which is a valuable property. It is ridiculous to artificially avoid making branches public; a branch is a useful means of collaboration and we should take advantage of it as such. It's a bad idea to base work on a feature where the code is still being under review. Even if you keep all of the historical crap on the branch, to be preserved for ever, it's going to cause merge difficulties for people who base branches based on that patch which is under review. I do not understand this. See, usign topic branches for upstream code that does reversions and bug fix one off versions, I have never really encoutered extraordinary difficulties in merging. Admittedly, the most complex case I have is Emacs, and I merge in changes from HEAD and sometimes from the lexbind branch, and both these are under rapid development -- what merge problems have I been avoiding? So you really, REALLY, don't want people basing work on code which is still being developed, since it may be that the review may include, why don't you totally refactoring the code *THIS* way, which will end up breaking everyone who depends on your new function interface anyway. Well, a complete refactoring would cause me to clone off another branch, and restart there, abandoning the current branch, but my cases are far different for the kernel. Which is significant; we are not talking about a code base with the size, scope, and contributors like the kernel does; perhaps the ruls might well be different? So how to solve this problem? (a) Send patches via e-mail for review. This actually works better, because people can respond via e-mail much more easily than if it just shows up in a git repository. You can also send an explicit request for people to review the patch when it is sent via e-mail. (b) Put the patches on a git branch which is *guaranteed* to be constantly rewound, and is not to be used as a base for derived patches. By convention the 'pu' branch in the git (and e2fsprogs) source repository is declared to be one which is used only for people who want to test the latest bleeding edge code, but it should not be used as the basis of any derived or child branches. Hmm. OK, how about this picture: inline: branching.png This is my typical workflow. Most of the time, upstream changes flow down to topic branches and integration branches; and since I use arch, I do plain old merges. If I actually rebase any Topic branch for the occasional feed back to upstream, that would cause problems in the integration branch (do not merge and rebase in the same tree). My tentative solution is to clone Topic_A_3.0 in Topic_A_3_Prime, and rebase the new branch -- which seems deceptively simple. The fact that no one has proposed that as a solution makes me think that perhaps this is not as easy as I am making it out to be. I would really appreciate any comments on this bit. I have never once run into this problem with other revision control systems in which branching and merging are common. Somehow it just never seems to be a real issue. I contend that dpkg is not big enough for it to become a real issue. It's not a fatal issue, but in the long run, the code is more maintainable if the code revision history is clean. It's like having a few goto's in the code. Does that make the code unmaintainable? No. But it does make it worse. Or think about how much effort some of us spend to make the code gcc -Wall free of warnings. Does not doing it make the code fundamentally bad? No. Is it still worth doing? Many of us believe that it is worth doing, nevertheless. While I appreciate the analogy, I am not sure how valid it is. I lurk on the emacs development list, and pull from the HEAD of the development branch several times a week. Since this is the HEAD of development, things might break, so I look at changelogs. Having messy history, and revocations of changes do not seriously impact my review of what has changed. I have often heard people say that clean history makes things easier, but since I do not see much of a difficulty with unclean history, I am not sure I find this argument persuasive. 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. manoj -- Actually, what I'd like is a little toy spaceship!! Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/~srivasta/ 1024D/BF24424C print 4966
Re: git bikeshedding (Re: triggers in dpkg, and dpkg maintenance)
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 remind you to USE THE FSCKING SOURCE!!! I am not sure this applies to dpkg, but in kernel land, the full reasoning behind even one-line trivial patches to some deep-magic areas are just plain impossible to understand without a ton of explanations in the log. Irrelevant. The size and complexity of dpkg are not in the same ballpark, county, state, country, or hemisphere as the kernel. So, every change in dpkg code is *always* completely obvious, and you never need any extra information that is not in a comment? Really? I am prepared to accept that as truth for a seasoned dpkg developer, but only if I hear it from all current active dpkg developers. Because even if a single one of them has found a (good) commit log to be valuable to understand something, that means you are wrong. 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 as to start working on dpkg, for that matter. Logs are not the source. No matter how much time you waste fiddling with them, they are really unimportant. Programmers Sorry, I don't agree with you. Logs are important. Especially if one member of the team quits, and another has to join in and find out exactly what was happening to the code at that point in time (as opposed to reading the code at that point in time, to know how it looked like). A log by this measure has temporary value during development of a new feature. Thereafter the value is negligable. Therefore by this measure Oh, not at all. Don't you at least look at the commit log comments for any line of code that just plain doesn't make sense to you should you find yourself in need to change that line of code or the code surrounding it? Properly written commit logs tell you what the programmer INTENDED TO DO when he commited a set of changes, and often also WHY he wanted to do it in a specific way. That in itself can be very valuable information if either some of it is not obvious, or if (surprise!) the programmer made a mistake in the code he commited, and it doesn't actually do what he intended it to! Of course, the commit log might be erroneous. In which case someone will end up wasting time making sure the code is correct even if it doesn't do what the commit logs says it should. That happens, too. And if it happens too often on your team, then yes, you would be better of without any commit logs at all. In other words, good commit logs aid debugging and maintainance when it is not being done by the one who wrote the code in the first place (and depending on how good his memory is, even for the one who wrote the code). it is not worth spending time prettifying logs for git merges of completed features. That is not for you to decide, that's for whomever will do the merge to decide. You can refuse to do any such prettifying (if anyone asks you to in the first place), but upstream is also in its right to do the prettifying themselves (since they clearly think it is that important!) or to just ignore your contributions, then. should be documented in a design document or noted in a comment. Comments have this very bad property of getting stale, which really is a damn pity, as comments are in the code and therefore extremely more likely to be read by someone trying to modify that area of the code. Logs are never stale, as they are only valid at one exact point in time and they are tied to a specific set of changes anyway. But they don't have the extreme advantage of locality that comments do. You need *both*, and you need to take good care of *both*. You may wish to have both logs and comments but you have not demonstrated any value to logs other than for WIP, nor any return on the investment of Ian's time to prettify logs for you. There is more than writing code, there is *maintaining* it. Which is far more important than writing code in the first place for every long-lived and important piece of infrastructure (like dpkg, like the kernel). If good commit logs and history are usefull for debugging and maintaining the code down the road, then they ARE important. And that has nothing to do with work-in-progress. Now, I am currently not going to bother to explain right now why commit logs are important when debugging code one is not intimately familiar with. Maybe later, if I have nothing better to do. But it has to do with it speeding up the debugging a great deal if you know what the code author wanted to do in the first place, and also helping you locate where the bug might be
Re: git bikeshedding (Re: triggers in dpkg, and dpkg maintenance)
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 gives prettier logfiles is absurd. 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 valuable property. It is ridiculous to artificially avoid making branches public; a branch is a useful means of collaboration and we should take advantage of it as such. Usually, I make branches public when my log looks sane. And it's not absurd, is to allow everyone to be kept sane when looking the log in 5 years forward. I have never once run into this problem with other revision control systems in which branching and merging are common. Somehow it just never seems to be a real issue. I contend that dpkg is not big enough for it to become a real issue. -- Colin Watson [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: git bikeshedding (Re: triggers in dpkg, and dpkg maintenance)
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: that is, in a way which makes merging work properly. Insisting that I use git in a manner which makes merges break but gives prettier logfiles is absurd. 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. Usually, I make branches public when my log looks sane. And it's not absurd, is to allow everyone to be kept sane when looking the log in 5 years forward. -- O T A V I OS A L V A D O R - E-mail: [EMAIL PROTECTED] UIN: 5906116 GNU/Linux User: 239058 GPG ID: 49A5F855 Home Page: http://otavio.ossystems.com.br - Microsoft sells you Windows ... Linux gives you the whole house. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: git bikeshedding (Re: triggers in dpkg, and dpkg maintenance)
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 not sure this applies to dpkg, but in kernel land, the full reasoning behind even one-line trivial patches to some deep-magic areas are just plain impossible to understand without a ton of explanations in the log. Irrelevant. The size and complexity of dpkg are not in the same ballpark, county, state, country, or hemisphere as the kernel. Logs are not the source. No matter how much time you waste fiddling with them, they are really unimportant. Programmers Sorry, I don't agree with you. Logs are important. Especially if one member of the team quits, and another has to join in and find out exactly what was happening to the code at that point in time (as opposed to reading the code at that point in time, to know how it looked like). A log by this measure has temporary value during development of a new feature. Thereafter the value is negligable. Therefore by this measure it is not worth spending time prettifying logs for git merges of completed features. should be documented in a design document or noted in a comment. Comments have this very bad property of getting stale, which really is a damn pity, as comments are in the code and therefore extremely more likely to be read by someone trying to modify that area of the code. Logs are never stale, as they are only valid at one exact point in time and they are tied to a specific set of changes anyway. But they don't have the extreme advantage of locality that comments do. You need *both*, and you need to take good care of *both*. You may wish to have both logs and comments but you have not demonstrated any value to logs other than for WIP, nor any return on the investment of Ian's time to prettify logs for you. Time spent prettifying logs is time that could be better spent programming or packaging or playing with the grandkids. 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 developers. dpkg has how many thousand developers? --Mike Bird -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
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, the impression that has been created on the lists is more that the patches were being NACKed and wouldn't be looked at until the logs had been rewritten. I guess that's a bit less of a bad situation. -- You grabbed my hand and we fell into it, like a daydream - or a fever. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: git bikeshedding (Re: triggers in dpkg, and dpkg maintenance)
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 this process, he will rearrange the changes in smaller logical chunks. If the code had been submitted in that form (easy to review), the branch would most probably already have been merged and we would be done. What about keeping the (bad) real history (so that merging with out-tree branch will still be easy) AND presenting logical chunks easy to review ? I imagine the current situation is something as A0 A1 - ... - A mainline branch \\ B1 B2 Btrigger branch with crap history (and several merges from mainline) Then go to the situation : A0 A1 - ... --- A P1 ... P6 logical chunks easy to review \\ \\ B1 B2 B - M1 - M final commit to push with the property that M1, M and P3 represent exactly the same source tree (but obviously they are not the same commit as they do not have the same history) There will still be some commit with crap log (Bx) in the git repo but, if no one create branches from Bx or M1, one would always be able to follow an easy to understand path from the base to its commit (by looking the changes on the Px path and knowing that the merge M merges two *identical* trees) Best regards, Vincent -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: git bikeshedding (Re: triggers in dpkg, and dpkg maintenance)
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 thought. 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 gives prettier logfiles is absurd. 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. Whatever happened to release early, release often? I prefer to make everything public unless I have a reason not to. It lets anyone interested help out, and it makes less work for me because I don't have to keep track of what should be public and what shouldn't. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: git bikeshedding (Re: triggers in dpkg, and dpkg maintenance)
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 makes merging work properly. Insisting that I use git in a manner which makes merges break but gives prettier logfiles is absurd. 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 valuable property. It is ridiculous to artificially avoid making branches public; a branch is a useful means of collaboration and we should take advantage of it as such. I'm not saying that it couldn't be made public for review however I suppose noone will ask for review if it's still at start of development process. The moment you commit a patch on the branch is the moment it potentially is interesting. Here's an example. I'm looking at evaluating Redmine, a web-based project management tool, sorta like *forge but smaller, easier, faster, and better. Redmine's SVN tree has integration with Darcs, Mercurial, etc. -- but not git. So someone made a Git branch of it that has Git support. This support will certainly be integrated into mainline at some point. Meanwhile, even if he is still working to refine it, it's useful to me to see it because I'd want Git integration. I understand the risks of running bleeding-edge code, and in this case maybe it's worth it, and maybe I'm interested in helping to test, too. -- John -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: git bikeshedding (Re: triggers in dpkg, and dpkg maintenance)
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 the branch history which isn't ideal but would avoid having the history from your branch in the main history. Does this not also suffer from the problem that branches made from my triggers branch become unuseable or difficult to merge ? Ian. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: git bikeshedding (Re: triggers in dpkg, and dpkg maintenance)
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 work properly. Insisting that I use git in a manner which makes merges break but gives prettier logfiles is absurd. The thing that you doesn't seem to understand is that if you don't do it, Guillem will do it for you and you'll have to fix up your other branches (flex-based parser, ...) anyway and you won't be able to use plain merge for that (or rather you can but it will be highly inefficient compared to a git-rebase -i where you skip the irrelevant commits that have been merged with other id). Only if Guillem insists on not taking on board the points that I and others are making here. Ian. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: git bikeshedding (Re: triggers in dpkg, and dpkg maintenance)
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? This would give a single commit discarding the branch history which isn't ideal but would avoid having the history from your branch in the main history. 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 applying the patch corresponding to the whole branch. So it will also break merging from other branches based on the merged branch. 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 [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: git bikeshedding (Re: triggers in dpkg, and dpkg maintenance)
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 reiterate what John Goerzen said earlier about other revision control systems. If dpkg were in darcs, bzr or arch, hardly anyone would seriously suggest a workflow like the suggested git-rebase; we've heard that it's in a minority amongst hg users as well. Everyone would assume that we would use the workflow I am proposing. That workflow is indeed supported by git. So it is clear that my suggested workflow is not inherently unacceptable or unworkable for dpkg. Is it really the case that just because git has this rebase functionality (which is designed for submitting patches in enormous projects), we must use it ? Surely the question is whether the benefits of the rebase workflow outweigh the costs. Costs: * Code changes need to be reworked and reorganised * Commit logs need to be reedited * Code needs to be retested after the above changes have been made, probably several times * The commit logs do not reflect reality Benefits: * It is somewhat easier to read the diffs when considering whether to merge, or whether to do substantial structural rework first * The commit logs are neater The first one of those two benefits is obviously the only one that is relevant. But it can only be relevant if there is some doubt as to whether my triggers code should be merged without substantial rework. Surely it must be clear that it should ? The specification was discussed extensively and agreed in the appropriate Debian fora. The implementation has been deployed and tested in a very widely used Debian derivative. The cost of attempting to reorganise the timeline of code changes should not be underestimated. It's not just the work (and its tiresome nature). These kind of activities, like merging, are very error-prone. Ie, if we adopt the rebase workflow the result is likely to have more bugs. Ian. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: git bikeshedding (Re: triggers in dpkg, and dpkg maintenance)
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 its appropriate for most projects, it appears. And moreover, that the picture that I have been getting -- and it sounds like you too -- about what is and is not acceptable in the Linux kernel development is a more nuanced than it appears. Thread at: http://thread.gmane.org/gmane.comp.version-control.git/75035 Direct link to the messages from Linus: http://article.gmane.org/gmane.comp.version-control.git/75064 http://article.gmane.org/gmane.comp.version-control.git/75083 http://article.gmane.org/gmane.comp.version-control.git/75150 but I would really suggest reading the whole thread. -- John -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: git bikeshedding (Re: triggers in dpkg, and dpkg maintenance)
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 in your work so that _you_ solve the conflicts and issues, and _then_ mainline can see how it looks and look at the cleansed diff. I definitely agree that I should be the one to do the merge. So at least twice already I have merged mainline into my tree and published the result. Ie, I agree with you. That's exactly what I want to happen. I'm very happy to do that merge again, if I have some assurance that it's not just wasted work. In fact, at this stage I don't even want any effort from Raphael and Guillem. All I want is permission. They have already granted me physical commit access but they have made it clear that they don't want me to merge my branch, or to commit freely, and that they will consider it abusive if I simply push a merged triggers branch. All I want is for Raphael or Guillem to say `oh all right then'. 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, just a fast forward - so I will simply do that, and push the result. And really I would like Raphael and/or Guillem to simply confirm that I'm a full member of the team. IOW, you have to merge master, preferably in a new branch than your trigger-new one, like a master-pu-triggers or whatever, and if mainline is pleased or can read that patch (that I'm sure isn't _that_ big) they _then_ will be able to merge that branch that would just be a fast-forward. The resulting patch is still big (3-4kloc of diff) because triggers is a big feature. The size will not change much depending on what precise revision it's based on. Note that they may ask you to rework this merge if they had done some further commits, but if you mkdir .git/rr-cache then git is able to use recorded images of already solved conflicts so that merging the same conflicts again and again doesn't costs you any time. IME I can just merge from mainline into my branch, and it all works completely fine and I never need to do any rework. This is, after all, what a distributed vcs is for. Ian. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: git bikeshedding (Re: triggers in dpkg, and dpkg maintenance)
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 contains invalid email address in some Author fields. Well, I'm sorry that not all of my early commit entries are ideal. Note that the wrong email address was due to a bug in Debian's git. 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 ? Ian. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: git bikeshedding (Re: triggers in dpkg, and dpkg maintenance)
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 can see why you'd have a tough time convincing anyone to change his mind about it. We will have lived it ourselves and made up our minds about it a long time ago, already... dpkg is not the Linux kernel. Linux dpkg Number of different people regularly contributinghundreds or three or significant changes thousandsfour Size of source (.tar.gz) 59 Mby 6.3 Mby Current gatekeepersOriginal author Developers who and hand-picked happened along lieutenants at the right time Organisational relationshipNone / Members of original between main contributors commercial project, under competition unified governance Linux has some very severe management problems to solve: its large size, its position right at the centre, and so forth. To deal with these problems, very heavyweight processes have evolved to ensure that the load on the small number of central gatekeepers is absolutely minimised. An underlying assumption is that in order to save a minute of work for Linus, it is worthwhile to impose tens of minutes, or even hours, of work on submitters. The gatekeepers in Linux can only delegate with extreme care because the code is too big for effective ongoing review, and because many contributors' motives are often specifically aligned with a desire to get a patch accepted - often with substantial financial implications. If you try to apply the same processes to dpkg, or to even smaller and less important projects, you're introducing a very cumbersome burden for very little good effect. 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. Ian. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: git bikeshedding (Re: triggers in dpkg, and dpkg maintenance)
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 him to do is using: git rebase -i his original branch point If I do that, it will surely break the revision history of my derived branches just as badly ? Ian. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: git bikeshedding (Re: triggers in dpkg, and dpkg maintenance)
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
Re: git bikeshedding (Re: triggers in dpkg, and dpkg maintenance)
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, just a fast forward - so I will simply do that, and push the result. 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 the branch history which isn't ideal but would avoid having the history from your branch in the main history. -- You grabbed my hand and we fell into it, like a daydream - or a fever. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: git bikeshedding (Re: triggers in dpkg, and dpkg maintenance)
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 doesn't seem to understand is that if you don't do it, Guillem will do it for you and you'll have to fix up your other branches (flex-based parser, ...) anyway and you won't be able to use plain merge for that (or rather you can but it will be highly inefficient compared to a git-rebase -i where you skip the irrelevant commits that have been merged with other id). 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 [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: git bikeshedding (Re: triggers in dpkg, and dpkg maintenance)
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 no sense to me. Ian's work was done at some point, tested from that point, and it makes sense to remember that fact. Actually it's insane to forget that fact. And rebasing is just pretending that fact never existed. It's just wrong. Let me put this straight. I don't want Ian to rebase for the sake of rebasing. I have no problem with merging clean branches. But his branch is not clean: http://git.debian.org/?p=users%2Fiwj%2Fdpkg.gita=searchh=triggersst=authors=Ian+Jackson 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 contains invalid email address in some Author fields. I wanted him to present the history in a way that makes sense to proof-readers and anyone else working on dpkg. Had he developed his branch with care to have something reviewable, I would have zero problem merging his branch without requiring a rebase. 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 [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: git bikeshedding (Re: triggers in dpkg, and dpkg maintenance)
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 yourselves. You vote for the mad route. Sorry, but it makes absolutely no sense to me. Ian's work was done at some point, tested from that point, and it makes sense to remember that fact. Actually it's insane to forget that fact. And rebasing is just pretending that fact never existed. It's just wrong. Let me put this straight. I don't want Ian to rebase for the sake of rebasing. I have no problem with merging clean branches. But his branch is not clean: http://git.debian.org/?p=users%2Fiwj%2Fdpkg.gita=searchh=triggersst=authors=Ian+Jackson 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 contains invalid email address in some Author fields. I wanted him to present the history in a way that makes sense to proof-readers and anyone else working on dpkg. Had he developed his branch with care to have something reviewable, I would have zero problem merging his branch without requiring a rebase. 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 him to do is using: git rebase -i his original branch point which will _not_ change where he came from, but only how he presented it, which is a tiny smallish lie about how it was brought to the world, but would make history way better. But again, rebasing onto master will not make that any better, it'll make fresh pooish history instead of the current one. -- ·O· Pierre Habouzit ··O[EMAIL PROTECTED] OOOhttp://www.madism.org pgpXneoFdbb3B.pgp Description: PGP signature
Re: git bikeshedding (Re: triggers in dpkg, and dpkg maintenance)
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 precisely the git bikeshedding I was talking about. The `work' that needs to be done is simply `git pull'. [1] My changes are not that hard to review and in any case they have been ready for merge for SIX MONTHS and deployed in a widely-used released Linux distribution for four months. What more evidence is needed of their suitability ? They're suitable to get in but commit logs and team repository policies need to be respected. I'm with Raphael here and IMHO (even being not a member of team) is that it shouldn't be merge until you, or someone interested, make it follow the policies. FWIW, you do have access to the repository but I would request you to be removed from the team if you made usage of it in a way that doesn't conform to the rules of the team. This includes having meaningful commit logs and using private rebased branches for most of the work except when we have a public branch where multiple persons of the team cooperate (such as what happens with the sourcev3 branch currently). http://wiki.debian.org/Teams/Dpkg/GitUsage This development model has been imported from the Linux kernel. It may be appropriate when there are hundreds or thousands of people generating huge quantities of patches, all trying to get their changes committed, with no organisational connection to the handful of people picked by the original author who need to act as gatekeeper. It is not appropriate for a project which has about four people submitting any significant number of patches, all of whom are fully signed-up members of a shared governance infrastructure, and where the gatekeepers are just the people in that project whose hands the code has most recently fallen into. Sorry but I disagree with you. Every project ought to have sane commit logs and logical changes. It makes cherry-picking, bisect and others much easier and improves the general programming experience of others devels since they see logical commits instead of a bunch of commit doing different changes all the time. Bear on mind that the comment used on the commit ought to be used to justify the commit itself. It's not only to give something to show at git log. -- O T A V I OS A L V A D O R - E-mail: [EMAIL PROTECTED] UIN: 5906116 GNU/Linux User: 239058 GPG ID: 49A5F855 Home Page: http://otavio.ossystems.com.br - Microsoft sells you Windows ... Linux gives you the whole house. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: git bikeshedding (Re: triggers in dpkg, and dpkg maintenance)
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 its propensity to turn tested code (what you actually committed) into untested code (what you committed + what someelse has done, in a version of a tree no human has ever evaluated for correctness). If people doesn't test and review the patches after rebasing, it looks right but everyone is suppose to test the changes after a merging (as for rebasing). -- O T A V I OS A L V A D O R - E-mail: [EMAIL PROTECTED] UIN: 5906116 GNU/Linux User: 239058 GPG ID: 49A5F855 Home Page: http://otavio.ossystems.com.br - Microsoft sells you Windows ... Linux gives you the whole house. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: git bikeshedding (Re: triggers in dpkg, and dpkg maintenance)
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 (aka the maintenance branch) and then merged back into master, and then back into 'next' (where the devel happens). IOW, it depends, and if you work on a new _feature_ it's really rarely rebased. 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 something like: Implements the basis for feature 'foo' Changes code to use new feature 'foo' and avoid all the messy commits done in the way. Besides that, I guess that even when you rebase something against git.git or linus tree, you'll end up being out to date and a merging being done since the volume of commits is too high to allow fast-forward merging only. Personaly, when I'm working on any branch I try to keep it against current version (be it maint or next or whatever) rebased. When merging, I don't worry if it'll be a merging or a fast-forward one. It'll only depends on how long the branch took to get merged. 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 no sense to me. Ian's work was done at some point, tested from that point, and it makes sense to remember that fact. Actually it's insane to forget that fact. And rebasing is just pretending that fact never existed. It's just wrong. Please see my commit about the logs above. As I said, it's much more about commit logs (for me at least) then rebasing. If Ian is OK to make it in logical pieces, it would be ok for me to merge. -- O T A V I OS A L V A D O R - E-mail: [EMAIL PROTECTED] UIN: 5906116 GNU/Linux User: 239058 GPG ID: 49A5F855 Home Page: http://otavio.ossystems.com.br - Microsoft sells you Windows ... Linux gives you the whole house. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: git bikeshedding (Re: triggers in dpkg, and dpkg maintenance)
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. Short version: you're throwing away history that may be useful later. My example was: Now, say we started from a common base where line 10 of file X said hi, I locally changed it to foo, upstream changed it to bar, and at merge time I decide that we were both wrong and change it to baz. I don't want to lose the fact that I once had it at foo, in case it turns out later that really was the right decision. [1] http://changelog.complete.org/posts/690-Git-looks-really-nice,-until.html -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: git bikeshedding (Re: triggers in dpkg, and dpkg maintenance)
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 something like: Implements the basis for feature 'foo' Changes code to use new feature 'foo' and avoid all the messy commits done in the way. Why? I would rather have the original history. After all, isn't that what version control is for? Preserving history? Because perhaps in my attempt to fix a syntax error I inadvertantly messed up some logic that I don't notice until a year later. Perhaps if I then look at $DVCS blame I can see that Ouch! Syntax error changed that logic, and if I then look at the patch, it may be quite easy to see what the syntax error was and how I fixed it incorrectly. One could easily do this hacking on a separate branch, then merge --no-ff into the main branch, and submit that. You'd have one logical top-level commit plus the whole history leading to it if you care. Also, I don't get why git people are so uptight about this. 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). -- John -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: git bikeshedding (Re: triggers in dpkg, and dpkg maintenance)
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 commits for review, you see the pros. It is much easier to everyone to handle it. It's clearer for someone looking when it has been done and he has a logical unit doing the change instead of 10 commits with messed log messages without visual relation but doing a single logical change. As I said before, I usually commit very ofthen. After the change is done I redo the branch splitting the change in logical units. Each change has a nice and well descripted comment that gives good information to everyone interested on it. -- O T A V I OS A L V A D O R - E-mail: [EMAIL PROTECTED] UIN: 5906116 GNU/Linux User: 239058 GPG ID: 49A5F855 Home Page: http://otavio.ossystems.com.br - Microsoft sells you Windows ... Linux gives you the whole house. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: git bikeshedding (Re: triggers in dpkg, and dpkg maintenance)
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 plugin, but I don't think it's widely used yet. Thanks, James -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: git bikeshedding (Re: triggers in dpkg, and dpkg maintenance)
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 get it done ... It's much nicer to have something like: Implements the basis for feature 'foo' Changes code to use new feature 'foo' and avoid all the messy commits done in the way. Why? I would rather have the original history. After all, isn't that what version control is for? Preserving history? No! Version control is for enhanced traceability of changes, to let one revert easily to previous working states of something, to aid debugging, to ease team work and further development, to (when possible) follow the flow of the code changes in the past, and to keep a lot of useful (when the developer does his job right) metadata along with the changes (i.e. the changelog). 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. -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: git bikeshedding (Re: triggers in dpkg, and dpkg maintenance)
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: Fix my 3rd syntax error today on it. It's used to track useful changes and logical changes. Same for history. -- O T A V I OS A L V A D O R - E-mail: [EMAIL PROTECTED] UIN: 5906116 GNU/Linux User: 239058 GPG ID: 49A5F855 Home Page: http://otavio.ossystems.com.br - Microsoft sells you Windows ... Linux gives you the whole house. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: git bikeshedding (Re: triggers in dpkg, and dpkg maintenance)
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 preserving the history as is. It has rebase support through a plugin, but I don't think it's widely used yet. The bzr community doesn't encourage rebase because of the destructive effect it has on collaboration - and at least the authors of bzr consider one of its primary goals being to enable collaboration between software authors. So rebase is there for folk that need it, but its not the recommended solution to the various problems mentioned in this thread. -Rob -- GPG key available at: http://www.robertcollins.net/keys.txt. signature.asc Description: This is a digitally signed message part
Re: git bikeshedding (Re: triggers in dpkg, and dpkg maintenance)
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 know *both* sides of the troubles and advantages of git rebase quite well... I can see why you'd have a tough time convincing anyone to change his mind about it. We will have lived it ourselves and made up our minds about it a long time ago, already... 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 rebased). Both of these practices lead to severe problems. Correct. Yet, rebasing is still routinely performed in the Linux kernel development. Indeed it should not be done for trivial reasons, as it does cause more work downstream, so the question is: what is a non-trivial reason? In the Linux kernel, we (as downstream) will usually cope with the problems it causes if it means clean history upstream. IMO, such behaviour is much better for the whole project later on. Say, in five years or so, when a different team will be working on dpkg. Or when someone is trying to chase down a bug, and has to look into the history to understand something. Many of the important subsystems in the Linux kernel community lives with this, it would not be done like that if rebasing was just a cosmetic thing. For one, merging properly rebased branches makes it a *LOT* easier to bissect, otherwise, you could find yourself bissecting a dpkg of two years ago to test a recently-merged feature whose work branches were started that long ago... In fact, it is bad enough in the kernel already, even with so much rebasing going on, because often the kernel you get while bissecting is just pure crap because people don't test enough before they send merge requests :-) If the main git branch pulls a rebased version of my triggers branch rather than the original, or if the same thing is attempted with patch and diff, then attempts to merge the main head back into the flex parser branch fail with conflicts. Raphael assured me that it would work just fine so I actually tried it, and so did Raphael later. The results were a pile of conflicts to fix up, as I had predicted. Yes. One has to just tough it up and rebase everything (and so does one's downstream). Rebase often enough in key points, and it won't be such a big pain to keep up with it. See the results of the workflow that Raphael is suggesting: http://lists.debian.org/debian-dpkg/2007/10/msg00206.html You probably want to skip the discussion and look at the transcript, about two thirds of the way down. Note that this is Raphael's message and the transcript he is presenting is what he apparently considers acceptable behaviour! Sure he does. We have a few thousand doing it in the kernel, why shouldn't he consider it acceptable? It is not done just for the kick of it. Clean history has a real benefit when it comes down to debugging and new developers joining in. Heck, some subsystems (like ACPI) have a rule where you have to *separate* all your changes into *rebased and clean* topic branches, merge them over a clean rebased branch from upstream, and submit the result of THAT merge. If you don't do it, the upstream maintainer will do it for you by force (and pick up your patches by email only, never pulling from you). OTOH, if you don't care for clean history, then the point is moot and rebasing is just a waste of everyone's effort. This can be avoided by using git properly. It already knows how to track which changes have already been merged. If you do it the right way (ie, just merge from my branch) then there are no conflicts. Everything is automatic; it just does the right thing. That would require your branch to be very clean, and would still cause issues when bissecting. If you never do bissects, and you don't care for a mess here and there in the history, indeed there is no good reason for rebasing. Of course you get a slightly messier revision history because the main dpkg revision history will then contains everything I actually did, rather than some sanitised rewrite of history. I think this is good because I want to know the actual context of a change, but Raphael thinks it is a problem because he wants a clean and pretty revision log. Yep. The real question is: which one is useful to people doing debugging and new developers joining in? Is that worth the effort? 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. -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness
Re: git bikeshedding (Re: triggers in dpkg, and dpkg maintenance)
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 you actually committed) into untested code (what you committed + what someelse has done, in a version of a tree no human has ever evaluated for correctness). -Rob -- GPG key available at: http://www.robertcollins.net/keys.txt. signature.asc Description: This is a digitally signed message part
Re: git bikeshedding (Re: triggers in dpkg, and dpkg maintenance)
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 forth, allegedly in order to make my changes easier to review. At the time I was reliably informed by git experts that published branches should not be rebased. As a rather more experienced git user it seems clear to me now that I was right to resist. There's no problem starting a new branch and rebasing this. % git branch trigger-new trigger % git rebase master trigger-new 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. 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 in your work so that _you_ solve the conflicts and issues, and _then_ mainline can see how it looks and look at the cleansed diff. IOW, you have to merge master, preferably in a new branch than your trigger-new one, like a master-pu-triggers or whatever, and if mainline is pleased or can read that patch (that I'm sure isn't _that_ big) they _then_ will be able to merge that branch that would just be a fast-forward. Note that they may ask you to rework this merge if they had done some further commits, but if you mkdir .git/rr-cache then git is able to use recorded images of already solved conflicts so that merging the same conflicts again and again doesn't costs you any time. Cheers, -- ·O· Pierre Habouzit ··O[EMAIL PROTECTED] OOOhttp://www.madism.org pgpnqb1X6frq0.pgp Description: PGP signature
Re: git bikeshedding (Re: triggers in dpkg, and dpkg maintenance)
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 particular its propensity to turn tested code (what you actually committed) into untested code (what you committed + what someelse has done, in a version of a tree no human has ever evaluated for correctness). Yet, Linus himself is the one who refuses to merge anything with dirty history :-) It is a two-way knife. You choose the side of it you prefer to hold to, but you have to be careful with it *anyway*. -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: git bikeshedding (Re: triggers in dpkg, and dpkg maintenance)
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 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 can see why you'd have a tough time convincing anyone to change his mind about it. We will have lived it ourselves and made up our minds about it a long time ago, already... 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 history, it's a suite of topic branches merges. For example, look at all the commits named 'merged branch ph/...' that would be the branches that come from my work. 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 (aka the maintenance branch) and then merged back into master, and then back into 'next' (where the devel happens). IOW, it depends, and if you work on a new _feature_ it's really rarely rebased. OTOH, if you don't care for clean history, then the point is moot and rebasing is just a waste of everyone's effort. The question isn't about clean history, but a faithful one. When you rebase a branch, you pretend that you developped it on top of where you rebased it onto. Except that you didn't. This can be avoided by using git properly. It already knows how to track which changes have already been merged. If you do it the right way (ie, just merge from my branch) then there are no conflicts. Everything is automatic; it just does the right thing. That would require your branch to be very clean, and would still cause issues when bissecting. If you never do bissects, and you don't care for a mess here and there in the history, indeed there is no good reason for rebasing. You're totally on crack, git bissect works really well across merges, and has really more chances to do so, because when you rebase, you usually e.g. don't check that intermediates points build, only the top. And an intermediate point that doesn't build is _WAY_ more likely to be a PITA for bisecting than a merge point. FWIW I bisect a lot, and bisect eliminates 'dead' branches (wrt the issue you want to track down) really efficiently. 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 no sense to me. Ian's work was done at some point, tested from that point, and it makes sense to remember that fact. Actually it's insane to forget that fact. And rebasing is just pretending that fact never existed. It's just wrong. -- ·O· Pierre Habouzit ··O[EMAIL PROTECTED] OOOhttp://www.madism.org pgpjVM63Zimu3.pgp Description: PGP signature
Re: git bikeshedding (Re: triggers in dpkg, and dpkg maintenance)
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 history, it's a suite of topic branches merges. For example, look at all the commits named 'merged branch ph/...' that would be the branches that come from my work. Of course branches are merged. But some of them are *rebased* before the merge request is sent. And rebased a lot while being developed, too (I count stgit and such tools usage as rebasing). And AFAICT, the kernel works in the very same way. What gets rebased No, it doesn't work always like that. Of course, parts of the kernel development are really patch-based (stgit, quilt, quilt-on-top-of-git, etc), and get into git at the last step only, and that may well have a lot to do with it. Heck, some subsystems and maintainers get patches only over email, which is the same as a rebase from the patch submitter's PoV. OTOH, if you don't care for clean history, then the point is moot and rebasing is just a waste of everyone's effort. The question isn't about clean history, but a faithful one. When you rebase a branch, you pretend that you developped it on top of where you rebased it onto. Except that you didn't. That's a way to look at it, yes. That would require your branch to be very clean, and would still cause issues when bissecting. If you never do bissects, and you don't care for a mess here and there in the history, indeed there is no good reason for rebasing. You're totally on crack, git bissect works really well across merges, and has really more chances to do so, because when you rebase, you usually e.g. don't check that intermediates points build, only the top. And an intermediate point that doesn't build is _WAY_ more likely to be a PITA for bisecting than a merge point. Only if you are a lazy ass. Oh wait, that describes a LOT of developers out there, in Debian and Linux alike ;-) *I* checkpatch (argh), build, AND do a light runtime-test at every point of a set I am sending upstream (and that's after the heavy testing during development). I can't speak for others, though. As for me being on crack, I better explain it a bit more what I mean, apparently... 1. You start developing by branching from upstream (mainline) 2. Upstream fixes some critical bugs (maybe they are not critical for you, but they are for a third party we will call tester), after you branched from it. You either ignore any updates in mainline while working on your branch, or (more likely, for long-lived branches) you merge from mainline back into your branch a number of times during development (always without rebasing). 3. You finish your work and ask upstream to pull from you. How well will bissect work for the tester, now, if he is trying to find out something that broke with the final merge between two points where something *else* is broken in mainline? I am not sure the above is something that happens on git or dpkg, but happens all the time in the kernel. Merge of recently-rebased subsystem trees lessen that pain a lot. This is all due not to bugs in git, it is dealing just fine with the merges and branches and bissecting those. FWIW I bisect a lot, and bisect eliminates 'dead' branches (wrt the issue you want to track down) really efficiently. Yes, it does. But that is NOT enough for certain projects. And very long-lived branches are the most likely ones to cause such problems. 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 no sense to me. Ian's work was done at some point, tested from that point, and it makes sense to remember that fact. Actually it's insane to forget that fact. And rebasing is just pretending that fact never existed. It's just wrong. There is no excuse for accepting untested code for merges in anything that doesn't go at breakneck speed. So I have to either assume it is going to be completely tested right before the merge, or right after it. Or both ;-) If it is going to be tested by the submitter right before the merge, he might as well do it properly and test it at every step of the changeset (which is the right thing to do, if you want bissections to be easy) and at that point, rebasing can't introduce new bugs. In fact, it will let the submitter find any new latent bugs due to mainline changes *before* submitting a merge request, which is the right thing to do. If the maintainer has to test everything the submitter did after he merges news code, he might as well clean up any dirty history, because that will help testing and understanding the new code a lot.
