Hey Siarhei,
On 11-08-15 13:43, Siarhei Siamashka wrote:
On Sun, 09 Aug 2015 21:44:00 +0200
Olliver Schinagl <[email protected]> wrote:
Hey all,
I've noticed we still have some outdated stale u-boot branches, that
ideally, we don't want people to use anyway.
Could you describe a realistic scenario, in which these outdated
branches can cause any harm or confusion for the users?
The way I figure, if people are stuck with one of our old branches,
There can be many reasons why people may be stuck with old u-boot
branches.
You misunderstand I think, al the legacy lichee stuff that users are
'stuck with', we should keep, but what purpose possible can u-boot-sunxi
hold in the future?
As a side note, people are generally reluctant to experiment with
something that already works fine for them. I doubt that many people
are keeping their u-boot (mainline or not) up to date unless they are
u-boot developers themselves or want to try a new useful feature.
There is always a non-zero chance of encountering unexpected
regressions. Not that I particularly like or endorse this, but
that's the state of affairs. And not only for sunxi.
Yeah but by keeping old cruft around, we only enable this behavior :)
because some feature is not implemented upstream, then we should see if
we can get that upstream. Though I wonder what we have downstream,
that's not upstream ...
As already mentioned by others, there are still many sunxi boards which
are not supported by the mainline u-boot. This is the actual problem
that you might want to try solving instead. By improving the
documentation, providing assistance to users, etc.
First of all, it makes sense to figure out why the owners of this
unsupported hardware do not happily work on adding mainline u-boot
support for it. Is it beyond their abilities? Not enough documentation?
Not enough time and/or motivation?
This is a fair question and until this is solved, we can keep them around.
In my case, all the Allwinner hardware that I have is already supported
by the mainline u-boot. Except for the http://linux-sunxi.org/Hyundai_A7
tablet. I could easily contribute support for it to the mainline
u-boot, but I strongly dislike the fact that it is probably a trademark
violating counterfeit product. I surely don't want to be listed as a
maintainer for this thing :-) But if anyone wants to add support for
this tablet under his own name, I'll be happy to provide assistance.
I may even post patches for this tablet *without* my S-o-b.
Therefore I suggest to make mirror/master the new default github branch,
it is a mirror of denx.de repostiory. Alternatively however, my
preference would have to use mirror/next, which is the custodian denx
repository for sunxi.
Therefore? Again, what kind of a real practical problem are you trying
to solve? What is the point of even having a mirror of denx.de
repostiory? BTW, are you going to setup a cron job to keep it properly
updated?
OK, suppose that we do this major change to the repository branches.
Who is going to update pages for many devices without mainline u-boot
support at the linux-sunxi wiki to make sure that the information is
relevant there? Right now the wiki pages are saying that all these
devices are "supported". Obviously, the current installation
instructions are going to become nonworkable and it is not nice to
claim that these devices are supported.
What I'm saying is that just reshuffling the git branches is not enough.
The one who tries to do this, *must* also provide the necessary updates
to the affected wiki pages.
The lichee branches we should keep for archival purposes. Also, did
allwinner-zh ever release those into their github at all?
If something is missing at allwinner-zh, then it may make sense to
submit a bugreport there.
Then we have some outdated branches which can all go imo:
old/sunxi-curren
sunxi-patchqueue
wip/a20
Maybe. Most likely nobody cares about these.
The sunxi branch (current default) could go into archive/sunxi but
should eventually also go.
Doing this is reasonable after the mainline u-boot gets support for
all the missing sunxi boards. Unfortunately we are not there yet.
But doing this just to cause problems for the users and "encourage"
them to start working on the mainline u-boot support for their hardware
is IMHO a dick move. Normally the developers are trying to provide a
smooth upgrade path (grub1 vs. grub2, gtk2 vs. gtk3, etc.)
Hopefully that will remove some unused cruft and reduce confusion to users.
Unless done right, in the short term this has a potential to greatly
increase confusion.
--
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.
