-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Somebody in the thread at some point said: > Andy Green wrote: >> Well there was no dependency until you introduced >> it now because you knew better just by glancing at the Kconfig. > > I actually started looking for anything amiss only when I got a > build failure because the BQ27000 dependency wasn't there ;-)
Well if it's my oversight that one leaked in, we should have fixed my bug. Otherwise there's no point bothering with layered patches -- I mean no point additional to the no point caused by mokopatches merging everything out of existence and making no point doing the right thing anyway. > Agreed that the HDQ driver can be more general than just something > related to power supplies. So why is it under power supply then ? It had to go somewhere... drivers/misc or making a new protocol directory seemed less good than in the power dir. >> (and get *everyone's* contributions posted to this list before they go >> in svn > > Wrong direction. We have to make the path to the repository shorter, > not longer. As long as checkins don't break the build, violate All the patches going on the list would already be in *a* repository or a branch one way or another before posting, just like mine are. When I post them I update the public git repo at http://git.openmoko.org to my tree. You're thinking about they are kept out of the *stable* "repository" (branch) until they are poked at, well that's the idea. But the stable branch is just a branch -- one most people are interested in, but just a branch. The patches on another branch are on living, testable, buildable trees already, it doesn't hold anything up, particularly since patch contributors have to keep their branch rebased on recent "stable" in order to generate patches that will apply to it. So this method does not delay or retard availability of patched trees, in fact the patches trees exist before the posting. If we're all using git, cherrypicking things into an experimental branch is easy. > coding style all over the place, or do other hugely insane things, > we can always discuss and correct problems later. Yeah where did I hear that take before :-) Except the price for doing that with mokopatches is huge, since you ripped the original patches apart and spread them over the anonymous grey ooze metapatches. Git fits that true lightweight style perfectly, but Mokopatches Must Go, and that is a whole subject we have to explore (in .tw face to face) to find out how we can do that effectively and not defeat the possibility of providing upstream something they can digest. > So why don't you check your work directly into SVN ? Then I wouldn't > have to waste time playing patch monkey, and you wouldn't get your > code messed with on the way. Yeah that's right -- we are both wasting major amounts of time on mokopatches. I had a big patch stack in git that was fine, I posted some of it here, it got tore up and applied to mokopatch blobs with changes, when I come to rebase I have a huge freaking headache reintegrating the rest of my patches on top of mokopatches modified by (almost) the same freaking code that is being replaced from the stack! GAAAH even Sisyphus rolling his mokopatch up the hill each day didn't have yesterday's patches of his own modified and added to the burden. Just updating the mokopatch layer is a time sink. Only you know how much time that crap is eating out of your life, I bet it is ten times more than me and I am going crazy about it already. If we can just standardize on GIT everywhere my patches are used they have the same hash, they aren't anonymously merged into accretions and stuff can "just work" much more than it does now. As for putting stuff direct to svn, well, I'm not joining the Mokopatch Hell ripping my own patches apart thanks very much, but aside from that this is an Open Source project where we're meant to look at each others' code for learning to happen in one direction or the other. Particularly when we are working on files that are familiar to others eg mach-gta02.c or because you happen to have spent time in the subsystem, it has value to get what we are doing looked at because there can be insight. Poking through svn is less likely to happen than peering -- in the peer review and visual senses -- at patches with an interesting title on the mailing list. I know there are other projects that use the cvs / svn scheme but this is a Linux Kernel project particularly, it makes sense to use the conventions of upstream when we're working with the same material (and that goes for git too). Something I found from your comments on my code -- when I am elbow deep *creating* new code and full of considerations and thought about the context of the code, weird stuff can happen like return () which I thought I had whipped out of my system. Someone -- even the same person who wrote it later -- who isn't in the creative and then exhausted modes that precede posting a patch can spot things that can't be seen at the time, and that is really lost with the "do not look behind the curtain" svn mode. - -Andy -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFHs25IOjLpvpq7dMoRAv6SAKCBIMqs2WoEqhP995V8kVIjP3YFbwCfcurD ZHYEzsy32N9/9l10NRalSa4= =VBti -----END PGP SIGNATURE-----
