[PATCH Try#2] introduce-bq27000-battery-driver.patch

[Andy Green]

-----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-----