Re: [Openocd-development] git gui
Apologies to anyone for annoying this list again with what are mostly discussions about the libusb dysfunctionality. If you aren't interested in finding why projects become dysfunctional, and why people will take palliative action then, please ignore. On 2011.10.27 00:53, Peter Stuge wrote: It's not a good idea to use git as one sees fit if that ends up being unfit for others, Last time I checked, libusb-1.0 asked for patches to be submitted to the mailing list, thus I really fail to get why you should pay any attention to what goes on in -pbatard. Moreover I did create a specific integration branch some time ago off -pbatard, so that you could pick stuff directly from git if you wanted (more about this below). I have yet to hear anyone else but you complain about -pbatard, or find they couldn't work with it. If anyone really has anything to say about how atrocious it really is, please feel free to browse [1] and comment. If you want to pretend that my branch is unfit for others, then pray provide concrete examples of others complaining that it is unfit. and it's of course not a good idea to use anything in an inefficient way. As I explained, the way I use git is, after careful comparison, the way *I* found most efficient. If you believe there can only be one master way to be efficient for software development, I am starting to understand why libusb turned out so dysfunctional. I think it's difficult to find a setting where git doesn't offer some significant advantages over other common choices. You're misreading the point (as you've done over and over again when we debated this in libusb-devel). So, once again, this is not a statement about git vs X. This is a statement about git alone. Git does have limitations and areas where I personally find it is far from being intuitive. When I say that, I'm not comparing it with SVN or whatever. For the record, I like git a lot better than subversion, which I also use on regular basis. But I do find that a many aspects of git are unintuitive and could be improved on, even without looking at competitors. For instance, I explained how grid coordinates to designate commits to human users (while keeping hashes internally) would have been a better choice than simply reusing hashes, as it would offer an immediate way to also provide their chronological order when referenced. You can also read (and comment) on "Indiana Git and the Intuitiveness of Doom" [2], which is about setting a git remote repository or other annoyances like fast forward denying [3] (which, apparently means that some people believe that deleting public commits is a bad idea) to get an idea of my annoyances with git if you want more. Also don't try impose your views on others with regards to git usage, unless you really have something to say about the quality of the patches they submit to mainline. To clarify for those not following libusb, and to take a concrete example: Pete's public libusb repo isn't rebased on the main libusb repo merge queue, but is rather a fork of the main repo from when Pete started working on libusb. More or less (see below). That's because I couldn't possibly fathom that I'd have to keep maintaining that development branch for 2 years. I foolishly believed that libusb would start integrate my work quickly and wouldn't be as totally adverse to Release Early Release Often as it is (or, more exactly, as Peter is). Once they early patches were integrated, I could just produce the subsequent ones off mainline by rebasing, ensuring that I wouldn't have to waste too much time maintaining my own branch, and concentrate on development. My plan was always to wait for my patches to be integrated, drop -pbatard, as it WAS a personal development branch, and subsequently work off mainline. Yet, 2 years on and I'm still waiting for a single libusb release that integrates ANY of the Windows backend patches. If you want to kick somebody for Windows git development and integration not happening the way you'd like them to happen, you should really have a long hard look at yourself for doing everything you can to delay integration and release, and actually prevent people from using git the way it "should" be used. When a branch has to exist on its own, without any ties to mainline, because mainline keeps ignoring it for years, it does becomes a headache to use git as one should, because what you really end up with are 2 very independent branches. The only other alternative to not wasting my time would have been to stop all development until libusb caught up (which is pretty much what I am doing right now). Also, what you seem to miss, is that I do follow up with mainline by merging the changes that occur there, except I'm not using rebase, but I merge them in one big commit, since they don't matter for Windows development. So it's not a fork "from when". It's just a fork. So, what really happens in -pbatard is
Re: [Openocd-development] git gui
On 2011.10.26 16:29, Peter Stuge wrote: Øyvind Harboe wrote: my main problem has been that that I've found that those that use Tortoise have no patience for the complexities and necessity of interactive rebase, rather than Tortoise lack of support for this feature. This might fit Pete. In another project I've learned that he prefers not to use many of the features offered by git, among others indeed interactive rebase Well, what do you know. Apparently, and I must say much to my surprise as I have recently learned [1], it appears that I simply "decided to hate git", which of course should make it "impossible to discuss" such matters. I can't help but wonder though how my usage of git, in my own branch, matters so much to Peter, when I don't remember that any of the patches I submitted to libusb-devel over the past 2 years to have been faulted on a git technicality, or from me apparently not using git the "established way". This is even more true as I have a very verifiable track record of being able to produce patches very quickly, when requested, even for a major headaches like an implementation that has evolved on its own, at a very rapid pace, for about a year and that must now be integrated. If anything, it should mean that whatever method I use to produce them wasn't that detrimental after all... If you really want to disprove my approach, Peter, then please find some verifiable evidence that any part of what I have been doing so far for libusb has been detrimental to mainline (rather than try to impose your own *personal* views of what a "good" private branch should look like). Also, since I am always eager to experiment, and as, if anything, it might turn out to be the only useful thing generated from this idiotic accusation, please do provide a list of the "many features offered by git" which myself and others should know about. For the record, I did follow your last point about git grep and git blame on the tcl/slash issue. Right after you posted I actually tried to determine whether using git blame in this case might not have been an overkill. Turns out there were only 3 small commits in one year on that tcl file, which gitweb promptly returned. If anything then, I guess I'm still waiting for a better example of git blame and other commands which I don't use (regularly|at all) saving the day, just like I am waiting for a good example of how, on small projects such as libusb and OpenOCD, choosing to never revert anything, and splitting commits ad nauseam actually contributes to collectively reduce everybody's time in the long run, maintainers AND contributors included. As with any tool, after careful consideration (especially with regards to the fact that libusb is a small project, that sees very few commits, that are far in between) and experimentation, I have drawn my own conclusion, as I am entitled to, as to what was I consider the most effective way. As long as the patches I submitted met the expected quality level, and I believe they do, I fail to see why I should have to defend myself with regards to how I use git. But anyway, if you want the short version, after many months of submitting patches, I found out that I was a lot more effective almost never using rebase --of course this only pertains to libusb: can't really comment on what I'd do for OpenOCD-- or, lately not even merge, but simply slapping patch serials or files from one branch into another and hack away (which, having a GUI actually makes very enticing, and which maybe you guys should also consider as the possible reason why the new generation may not use git the exact same way as grandpa does). This is how the latest Windows integration patches were produced and I'm still waiting to hear from you about how poor quality they truly were... Should I infer then, that, when I voluntarily decided to contribute to libusb, not only did I unknowingly sign a contract that strips me from the right to use to use a tool exactly the way I see fit, and that I was instead supposed to adhere to the "one true way" to use git? I think I must have missed Git Indoctrination 101. What I did not miss however were some of the deplorable action of mindless git worshippers, such as Peter, that pretty much sent us back 6 months on libusb-devel, with regards to the obnoxious CRLF issue, with the oh-so-maintainer-commendable actions of: 1. Taking about 3 months to start looking into a patch that was clearly identified as possibly contentious with regards to git (but then again, having to wait months before any serious review started was the fate of most Windows patches). 2. Getting bitten from the git documentation when trying to prove a critical point (about how others must have simply misread the documentation) and ending up interpreting the documentation wrong. 3. When seeing their arguments disproved, resorting to a very unprofessional "I just don't want CRLF in the g
Re: [Openocd-development] git gui
On 2011.10.26 06:07, Øyvind Harboe wrote: On Wed, Oct 26, 2011 at 2:12 AM, Peter Stuge wrote: jim norris wrote: For those using a git gui, what are you using? On which system? For Windows, there is Git Extensions and TortoiseGit. The Git Extensions looked less slick than TortoiseGit last time I looked, but TortoisGit on the other hand lacked fundamental functionality. I recommend Gerrit. Gerrit makes a lot of the nastier concepts, like interactive rebasing and communication easier. From my experience TortoiseGit is a step down the wrong path. It makes things easier than possible, i.e. it tosses hard concepts out of the window. Where is the interactive rebase functionality? You mean, this [1]? For the record, I have been using TortoiseGit pretty much on a daily basis, for almost two years now and from my personal experience, not only have I found it filling pretty much all of my git needs (besides, it's based on msys-git, so commandline git is only one click away), but also, unlike Peter, I found that if there's one tool that benefits greatly from having a solid GUI, it has to be git. Who'd want to go back to using commandline for diffs, log, or branch switching, when you have a GUI with *easy* navigation at your fingertips [2]?. Also, judging from the general praise for gerrit, which also provides a solid GUI frontend albeit web based (hence more complex for regular git users to setup on their own -- I wouldn't advocate it as a solution for a user who simply wants a GUI on their machine), I can only assume that many have come to share the view that some GUI ontop of git actually does wonders. Thus, do you guys, who seem to be opposed to the use of TortoiseGit, have better evidence to back up your claims? If not, I would advise Jim to take Øyvind and Peter's advice with a grain of salt, or at least also consider the advice of someone who, through nearly two years of continuous usage, has reason to believe that using TortoiseGit has actually increased their git productivity. Of course, just like Peter and Øyvind's, this is merely an opinion. Regards, /Pete [1] http://img689.imageshack.us/img689/697/tgitinteractiverebase.png [2] http://img190.imageshack.us/img190/3281/tgitdiff.png ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Peter Stuge is now an OpenOCD maintainer
On 2011.06.10 16:12, Peter Stuge wrote: Pete Batard wrote: Peter's involvement as a maintainer has mostly been limited to rebuilding his personal (i.e. non official) git branch every 3 months or so. If this is really how things look that is bad. It is. Heck, I only have to quote you on being "confident that a release before 2011 (was) achievable", or Segher dismissing people like myself or Xiaofan as "naysayer" when we shared our pessimistic outlook about that statement, to make you realize that, by all accounts, even the libusb maintainer and "acting maintainer" should agree that the situation is bad, since they have arguably overextended their expected maximum release deadline by at least 6 months now... It won't make our users, some how whom have probably been waiting for years now for patches to be integrated in official, any good to find out how great your personal git repo is. As you have stated many times in the past, our focus should be with providing our users with libusb packages that are attractive to them for their development. Fetching source from an ever rebased personal git repo, to be able to apply months (if not years) old _small_ fixes isn't. I like to rebase my libusb repo, which makes it difficult to see if the last change was a small commit message fix or ten hours of analysis and code rework. Suggestions to make work more visible are most welcome. Then, as many people have stated, please do this work in mainline, in bitesize operations, and please accept that applying corrective commits in mainline is not the end of the world. In the schoolyard of OSS projects, nobody is going to point the finger at us from not getting everything right at once, especially when we know that we are way behind schedule on a release. It has also been suggested to you to try to break down the long awaited next release into small critical patches first (some of which, may I remind you, have been integrated into the mainline git for more than a year), and then move to more consequent items, but you have been adamant about trying to do everything at once. When exactly are you going to realize that the approach you have been trying to follow is excessively detrimental to libusb users? If you have doubts about that statement, I suggest you re-read the numerous complaints on the libusb mailing-list. Myself and others have been trying to point that out to you for the best part of one year now, but you still seem to be acting like everything is OK. Sorry to break it down to you, but it definitely isn't, so please come back to earth already, and do something that will actually benefit libusb users. I've always communicated that my libusb repo is the proposed merge queue for libusb.git. Yes, and that is not the problem. Having a merge queue with loads of commits, that never gets merged, or a mainline git tree with enough patches to warrant a release, that doesn't see one for months, is. I still offer to add libusb repos for anyone and everyone who wants one, since even before I was maintainer, sadly without many takers. :\ Yes, let's add more individual repos. Exactly what we need here... I've had one, maybe 2 users for my 9 months old hotplug repo, despite the fact that this is a feature everybody wants, so I can tell you: adding more libusb repos does not help. What we need are timely releases of libusb, with the patches that have been submitted and validated for months. action needs to be taken by the maintainer... I've found that our views often differ fundamentally. Unfortunately for you, I am only one of _many_ voicing concerns about your approach to libusb maintenance. I'm afraid it has long ceased to be a matter of conflicting views between two individuals... Have you asked Segher, Michael, Orin, Graeme or others what they thought about your release schedule lately? The perception of maintainer is curious. Even more curious is the _lack_ of perception of a single maintainer, when _many_ project users have been complaining about the lack of releases... This reinforces my belief that the *what* is more important than the *how much*, ie. level of involvement. I'll take a maintainer that has to be shown the ropes, but that is effectively able to contribute time to a project, over a maintainer that supposedly knows the ropes but can't, any time. If Linus came over and said he'd agree to be a libusb maintainer provided he can limit his contributions to 10 hours every 6 months, while somebody else came and said that, while he isn't that experienced, he is motivated enough and can devote the required amount of time to the project, then knowing full well that we have enough good people in our project to look over any maintainer's shoulders, I'd vote for the latter. condemning the libusb project to a slow death..
Re: [Openocd-development] Peter Stuge is now an OpenOCD maintainer
On 2011.06.10 14:03, Øyvind Harboe wrote: Peter won't be alone on this project. He will be one of the maintainers, perhaps that will work better for everybody? If I may (and then I'll shut up as, unless Peter has anything to say, I think I've taken enough of your time here), I don't foresee OpenOCD having a problem as long as it has 2 or more maintainers, with at least one of them expected to responsive enough. From what I could see, OpenOCD is a healthy project, with more than one person getting themselves involved in the project administrative tasks on a regular basis, and I can only wish libusb was that way. Past a certain size, a project should to have at least two active maintainers to keep everybody happy IMO. Regards, /Pete ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Peter Stuge is now an OpenOCD maintainer
On 2011.06.10 13:24, Øyvind Harboe wrote: Well, Peter has certainly refused to step down, despite everybody else on the list pretty much voicing their support to the idea that this is the right thing for him to do, if he doesn't have the time/doesn't want to be involved. Ah. This is the tricky bit. Has someone *qualified* offered to take on this work? The tricky part I believe is that someone *qualified* (Not me. I'm pretty sure I could do a better job than what Peter is doing right now, but I have expressed on the list many times that I didn't want it) would offer to take on this work, but will only do so if Peter effectively steps down. Regards, /Pete ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Peter Stuge is now an OpenOCD maintainer
Hi Øyvind. I very much appreciate the constructive advice for help. On 2011.06.10 12:21, Øyvind Harboe wrote: Seems like a good opportunity for someone in the community to step up to the plate and take over the project if they want to. Well, the only problem we have here is that Daniel Drake, the official libusb project admin (i.e. the person who can assign new maintainers), is pretty much MIA as well as he doesn't participate/monitor the mailing list at all, and therefore hasn't stepped in to add more people, even as some would be undoubtedly be willing to. Has someone obviously qualified stepped up and offered to help on libusb as a maintainer? Pretty much. Segher Boessenkool, who has some good experience on these matters, was added as an helping hand shortly after Peter became maintainer and pretty much became a second in command at some stage, but (though I cannot speak for him) he was apparently eventually driven away by the lack of releases, or possibly because he didn't want to be seen as stepping over Peter's toes when the situation demanded it. Has Peter refused such an offer? Well, Peter has certainly refused to step down, despite everybody else on the list pretty much voicing their support to the idea that this is the right thing for him to do, if he doesn't have the time/doesn't want to be involved. Has someone qualified stepped up and offered to do the work of being a release engineer? I guess Segher could fit that profile. The other option we envisioned was to split maintenance activities between Linux, OSX and Windows platforms, and in effect have 3 maintainers. This was privately proposed about 1 months ago, but we're still waiting to hear back from the project admin on that... Has someone offered to pay Peter for the time he spends on libusb so he can address these issues? I think if we need paid contributions for libusb to move forward, not that I am against it if it helps, then we have a bigger problem... I believe the project should be large enough to find volunteers willing to contribute in their spare time. Is there anything in the libusb license that stops someone from forking the project? Nope. Just people knowing that forking over a single maintainer's lack of involvement, where said maintainer should very much be aware of the predicament he is inflicting on everybody else, isn't the right thing to do for the project users and will only serve to confuse them. Regards, /Pete ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Peter Stuge is now an OpenOCD maintainer
On 2011.06.10 07:10, Xiaofan Chen wrote: The community is very fortunate that he is *able* Wow, that is great to know. Peter will be able to understand what I mean... Yes. I'm happy for Peter here, and while I apologize for the intrusion as well as the opinion I am about to provide on matters that are clearly unrelated to OpenOCD, for those who want some clarification as to what Xiaofan means above, let me provide some insight with regards to what has been happening with another project, that Peter is also a maintainer of. For those who don't know, Peter has now been the _sole_ maintainer of the libusb project [1] for about 9 months, a project that is perhaps as widely used as OpenOCD (if not more), is both experiencing and requiring new developments, and has been in _critical_ need of a release for about a year. With very old, well known and non risky fixes still not having been officialized, the libusb project has been getting complaints from our users left and right, yet, still no release appears to be on the horizon and Peter's involvement as a maintainer has mostly been limited to rebuilding his personal (i.e. non official) git branch every 3 months or so. Lately the project has even been qualified as "one of the most disheveled projects (someone) had ever seen". Hardly something a project maintainer would want to put on their resume, and clearly an indication, if there was need for one, that action needs to be taken by the maintainer... Yet, perusing various mailing lists shows that, whilst Peter seems to have plenty of time to get actively involved and take on demanding challenges in other multi-maintainers projects such as coreboot or this one, where his absence to tend to other matters could be very much excused, he still somehow manages to neglect the one project where there actually doesn't exist any other maintainer to take over, and in effect, and I am carefully weighing my words here, has been condemning the libusb project to a slow death... Therefore, it comes as unsurprising that both Xiaofan and I, and most likely other libusb contributors and users, are a bit flabbergasted by this latest announcement, since Peter being able to afford the level of involvement that is expected from a project maintainer has really been at the crux of the libusb controversy over the past few months... All I can hope then, while yet again congratulating Peter on his new maintainer position, is that, unlike what is happening with libusb right now, he will _genuinely_ be interested in performing his maintainer activities for OpenOCD, and that his actions, or lack thereof, will not cause a repeat of the disarray that has befell on the libusb project. Regards, /Pete [1] http://libusb.org/ ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
