Hi,
On 13-04-15 23:37, Paul Kocialkowski wrote:
Hi Hans,
Le lundi 13 avril 2015 à 21:30 +0200, Hans de Goede a écrit :
[snip]
2) The defconfig names in u-boot I would rather not change unnecessarily
in some cases there may be good reasons, but in general once we've
picked a name we should just stick with it.
So I take it from that that you don't think this is a good reason?
Lets say I'm not 100% convinced, I'm not saying no before hand, also
depending on how much renames we actually end up with.
The way I see it, this looks like a big and ugly mistake we're not even
trying to fix. So sticking with it doesn't seem to be appropriate IMO.
Lets start with defining a policy for new boards, and document that, and
then see what that means for the old boards. Bonus-points if the policy
is such that it mostly matches what we've already.
Note that Luc Verhagen went through a similar exercise with all the board
wiki pages a while back and the result was not uniformly liked.
E.g. the mk802 and mk802ii boards are now at:
http://linux-sunxi.org/Format_MK802
http://linux-sunxi.org/Rikomagic_mk802ii
Which is just pure nonsense (as I've said before) these are generic
brandless devices which everyone just calls mk802 / mk802ii for
exactly that reason. Luc just picked 2 more or less random vendors
who happen to ship the generic design and prefixed the wiki pages
with $random_vendor which is not helpful IMHO.
Likewise the olinuxino and cubieboard / cubietruck boards are so
well known, and more or less contain the vendor name in the boardname
that prefixing them with the vendor name is not useful. That would
be the same as calling the Raspberry Pi defconfig:
RaspberryPiFoundation_RaspberryPi_defconfig
I'll make sure that all the wiki pages are updated according to the
changes, so that nobody has to suffer from it (that is, except for a few
build scripts that have the targets hardcoded).
3) I would prefer for you to focuc your time on moving more (all?)
sunxi boards in u-boot to device model, the merge window has just
opened and it would be nice if we can get that done for the next
u-boot cycle.
Well, what's great with free software is that I can actually do whatever
I want with my development time, I don't owe it to anybody to do
anything. As most of us, I'm doing this on my free time and so I work on
what I'm interested in.
ACk, sorry if I gave the impression that I was telling you what you
must do, that was not my intention.
Of course, I agree about moving to device model and I will most
certainly work on improving the situation on that side as soon as I have
the time for it.
Ok, note since I would like to get the dm move done this merge window I
will likely start working on this real soon (tonight already perhaps),
so for now lets say that I'm working on it and if you've time and want
to help please contact me so that we can coordinate things.
But I also like to fix things that annoy me in the software I use and
boy oh boy does this annoy me. This kind of lack of consistency is what
gives an overall impression of untidiness and lack of seriousness and it
bothers me a lot (this is of course just an impression, the technical
side matches high quality standards IMO).
I understand, but I'm also a big fan of Linus' "no regressions" policy,
so lets take this one step at a time, first write up a decent naming
proposal for the defconfig and dts files (put it up on e.g. the
linux-sunxi.org wiki) and get some consensus on that (or if there is
no consensus acked by me or Ian for the u-boot side and acked by
Maxime for the dts side).
Then at least we can do the right thing for new boards, if we've
a clear policy I'm also ok with doing a flag day rename of the
existing defconfig files (but not the existing dts files).
Note that if you also want to rename the wiki pages (as in the
URL pointing to them) that you will need to coordinate this with Luc
Verhagen otherwise he will likely just undo your changes.
Regards,
Hans
--
You received this message because you are subscribed to the Google Groups
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
For more options, visit https://groups.google.com/d/optout.