[Arm-netbook] Flashing the NAND

Aaron J. Seigo aseigo at kde.org
Fri Dec 13 11:02:56 GMT 2013

On Friday, December 13, 2013 03:23:35 Siarhei Siamashka wrote:
> Because the opengl issue,
> provided as an example, had absolutely nothing to do with being "hidden"
> or "nobody working on it”. 

a) look at the mailing list i sent it to
b) point me to the roadmap showing what work is scheduled
c) given the progress in the last year, it’s evident very little manpower is 
on this set of issues
d) i’m mostly concerned with upstream interactions; again: not everything is 
about you or linux-sunxi

Now, evidently you are working on integration of the drivers. So *somebody* is 
working on it. That’s great to know, and I was wrong in saying “nobody”.

The issue that is obviously there is that what work is being done is very 
opaque to anyone not you or the 2-3 other people deeply involved. Other people 
I talked to who also use A10/A20 devices similarly had no idea what was up.

That communication and documentation barrier is what I want to see addressed. 
It’d be much nicer to improve the situation than throw spears at each other. 

Instead of getting pissy about "nobody", step back and think why that is: 
maybe it’s because the visibility of work being done is very low. Your users 
are unable to see through the "fog of war” to gain perspective on what *is* 
happening . Then think about how to improve that. 

Because then, instead of arguing with me, you’d be able to solve this issue 
for every single person who comes along in the future. I’d go so far as to 
suggest that by doing so you’ll have more people who come along in the future 
as well.

> This all was happening at the very same time,
> when we were trying to identify the root cause of it together with
> Marco Martin, who reported the issue only about a day before.

I’ll belabour the point: where is the bug tracker, task list, etc. we can 
consult to know this?

> Now it's understandable that the real work is being done by Marco
> Martin and you are just acting as a middleman. 

Not really, but it’s also irrelevant.

> About my (over)reaction. The arm-netbook mailing list is not even the
> right place to report the issues like this (they are outside of the
> scope of EOMA-68).

I agree; however, there is so much overlap and the barriers between the 
various projects that ought to work together well are large enough that 
knowing who, where and when to communicate is utterly unclear. That can be 
improved on, but we can’t fault people for hitting the “wrong” communication 
channel when there is utterly unclear lines.

> That felt like I was bad mouthed behind my back.

Not only did you read that incorrectly, but you then lashed out instead of 
asking questions to gain information that would have cleared it up. That is 
not cool.

> Then instead of silently holding a grudge against you, I decided that
> it would be much better to request for explanations and clear all
> misunderstandings.

By being aggressive and accusing me of various things? Look, I appreciate that 
you didn’t just sit on it. That indeed would have been worse. Perhaps instead 
of responding as you did, you could have asked me what was meant by things 
instead of going off and *rampantly* misinterpreting things I wrote on G+ 
(e.g.) that had *nothing* *at* *all* to do with you or linux-sunxi. Better 
yet, let’s try and put together the communication and documentation 
infrastructure to prevent such problems in future.

My instinctive reaction is “this community is very volatile and puts very 
little value on coordination and communication ... I should be looking for a 
different SoC family to work with.”

That’s the kind of reaction a lot of people will have which limits 
participation and growth. This is not unique to linux-sunxi, it’s common to 
many open projects with similar attributes.

> Another somewhat unexpected thing is how little people from around here
> know about linux-sunxi. I can't find any posts from you, joem or
> freebirds in the linux-sunxi mailing list. Yet linux-sunxi is providing
> *software* support for Allwinner SoCs (unless you are using the Android
> SDK from Allwinner). The *hardware* projects and the companies working
> on them, such as RhombusTech, OLIMEX, CubieTech and the others all
> depend on linux-sunxi. Ignoring the linux-sunxi existence is just
> asking for communication troubles. Where do you get your kernel sources
> for Allwinner hardware? Are the EOMA-68 people assuming that all this
> work is somehow being magically done by elves while nobody is looking?

This is exactly why I want to have some coordination meetings in January. I’m 
glad we’re seeing the same issues now :)

> Now it became clear that the people around here are likely under the

Not really; it’s more like:

* lkcl talks to people and reaches out beyond his borders
* the lack of documentation and scatter shot of information sources makes it 
very difficult to connect with the most effective sources

Perhaps instead of blaming lkcl et al you could instead ask yourself why 
linux-sunxi isn’t more visible or providing a set of resources that are useful 
enough to people that they gravitate towards that source.

> So is everyone going to be happy now? This would be great.

We’ll get there :)

> > Sadly, There has been no response to my emails from a couple days ago on
> > this list, although Siarhei apparently had time to respond to Freebird’s
> > email. That is disappointing, as I’d really rather resolve the issues
> > than have people choose sides.
> > 
> > Siarhei: can you please acknowledge what I wrote on Monday? Thanks in
> > advance.
> In fact I don't have that much free time to waste on this mostly
> pointless discussion anymore :(

It’s not pointless to figure out the sources of the challenges you outlined 
above and figure out how to address them.

> I'll only reply to this part, because I think it is relevant:
> > That said, the “WTF” is due to the binary blob that is the mali driver we
> > have to work with today. You have very little to do with that, last time
> > I checked. Why are you taking this so personally?
> We can't blame the binary blob for all the problems.My take on this is
> that xf86-video-fbturbo has to work at least as good as xf86-video-mali.

.. and I wasn’t referencing fbturbo. You are reading things as if they are 
about you when they aren’t.

> If *anything* happens to work worse, that's *my* problem without doubt.
> And I want bugs to be reported to me, just to see whether anything can
> be done.

That’s completely fair; where is your bug tracker at?

Aaron J. Seigo

More information about the arm-netbook mailing list