Armbian developers meeting 1/11/2023

[Igor]

Event -> Video (with transcripts and comments)

 

1. Merging NEXT (Jira tickets / updated slides)

 

We discussed progress and problems. Help is needed with:

• enabling CI
• developer perspective testing -> test all boot loader, old boot loaders, especially armhf images: cubox-i, odroids, clearfog, ...
• user perspective testing
• desktop (currently is broken?)

 

2. Encourage end-users to open bugs to Jira?

 

Replacing https://www.armbian.com/bugs/ with instructions how to add a bug to Jira seems like a good idea. But this will be community managed without any obligation from Armbian team. Basically introducing a proper bug tracker. Existing AR-XXXX issues that are hardware specific should be moved there. If we have a consensus on that, we have to make a plan, write proper instructions and launch it ... or forget about.

 

3. Move developers forums to GitHub

 

We were weighting idea to try to encourage more discussion on GitHub and have forum more users oriented. For start, we can try to enable Action - if label discussion is raised, it automatically creates a topic on GitHub discussions. Or similar. If we do that, we should first deal with hardware related bugs. 

For 2 and 3 we didn't come to any common conclusions except that communication is fragmented around forum, git, irc / discord, emails, PMs ...

Comments on all topics are welcome!
 

@Contributor/Maintainer

[NicoD]

That was very infomative.
Can't add much to the discussion. I agree that forum used to be a lot better and more important. Because of the use of Discord, irc, Jira... there is more fragmentation.

We used to use the forum also to chat between devs/users/mederators. Now that is done on discord, irc or github. So the fun is out of the forum.
Nothing of what is said on discord is of value in the future. While what is said on the forum keeps its value and is easy to find.

Github is good for bugreports and discussion on how to go ahead. But it is a developers tool and not for regular users.
Discord is good to chat. It added features we didn't have on the forum like being able to do voice chats or video chat. But it takes away the focus from the forum for many.

I don't check the forum as much as I used to. Only see if there is anything interesting in the notifications. But I miss a lot because I'm not present as much. And what happens on the forum isn't communicated much about on discord.

Maybe a discord/irc room where forum posts can be seen. Just the titles would be enough to sparkle curiosity.

For me there is too much to have to keep up with. I've got my YT channel, reddit, facebook groups, forum, discord, twitter, ...
Quality decreases when too much is going on. Nobody can keep up with it maybe except Igor. (he seems to see it al )

Watched at 1.25x.

[schwar3kat]

I enjoyed watching that discussion.  Good progress on next.

I think that a Github discussion option available to developers before submitting a PR could be very useful. 
Maybe it could depend on or reference the users Github branch with a pending PR (is this possible)?

To me this particular type of development discussion seems to be very clunky on the forum.  Git Hub seems a better fit in this very specific case.
It sucks that you almost need to submit a PR that you are dubious about, in order to get advice to do it another way, or that your assumptions were misguided.  
A preview on my own branch seems a much more appealing option, rather than risk cluttering armbian build master and looking like a numpty.
I suspect that this could possibly encourage collaboration and mentoring particularly if the developer wants advice or opinions from other teams of developers. 

In this context, I don't think that moderation would be much of an issue and it would keep the discussion where it already exists on Github, just before, not after the PR.

I managed to get a few desktops to build on next.  
After Ricardo fixed the dialog issue, all remaining desktop issues that I'm encountering seem caching related.
Apt catcher ng which I didn't know about until yesterday (and therefore couldn't fix) was the biggest culprit, great to know it's not going to default to on.

[schwar3kat]

I suspect that lot of end users will not have Jira accounts, but most do have forum accounts.   Is Jira really the best option for end users?

[balbes150]

12 часов назад, NicoD сказал:

Nothing of what is said on discord is of value in the future. While what is said on the forum keeps its value and is easy to find.

 

+1

 

IMHO it is better to discuss general issues on the forum. Specifics on PR - on Github

[ALIGMSTEN]

Very interesting and insightful to the work being done, thank you.

 

It does reflect that meaningful dialog on the forums today is missing, when compared to older posts.

 

I agree discussions after merging seems pointless.

 

I would vote github mechanism's for developer's work.

 

[schwar3kat]

@rpardini one of the actions on the slides: "testing on other architectures (armhf, riscv64)"

 😀 For a lark, I thought I would give it a try on armhf, seeing as I have access to an orangepi-pc running Armbian Jammy

I mounted an external drive on it.
Armbian-next build was not successful, and because I don't think that armhf is a significant option, I didn't try too hard but here are the results. 
I suspect that the gcc-riscv64-linux-gnu package could be excluded if not cross compiling to riskv64, but I didn't investigate further.

First, I tried the same method that  I used on Intel, and it failed:

[🌱] Preparing [ host ]
[🌿] Please read documentation to set up proper compilation environment
[🌿] https://www.armbian.com/using-armbian-tools/
[💥] error: Running this tool on non x86_64 or arm64 build host is not supported  [  in prepare_host() at /mnt/storage/armbian-build/armbian-next/build/lib/functions/host/prepare-host.sh:63 ]
[💥] Build terminating... wait for cleanups...

I added this into lib/functions/host/prepare-host.sh at line 60 to include armhf in the permitted architectures:
    elif [[ $(dpkg --print-architecture) == armhf ]]; then
        :

Native build failed again:

[👉]    Package gcc-riscv64-linux-gnu is not available, but is referred to by another package.
[👉]    This may mean that the package is missing, has been obsoleted, or
[👉]    is only available from another source
[👉]    E: Package 'gcc-riscv64-linux-gnu' has no installation candidate
[👉]    --> 🧽   28: 13096 - 13096 - 13096: hBE: trap: main_trap_handler [ ERR and 100 trap_manager_error_handled: short_stack:/mnt/storage/armbian-build/armbian-next/build/lib/functions/logging/runners.sh:186 ]

I installed docker:

Docker build failed for the same reason:

[👉]    Get:18 http://ports.ubuntu.com/ubuntu-ports jammy-security/universe armhf Packages [491 kB]

...

[👉]    Package gcc-riscv64-linux-gnu is not available, but is referred to by another package.
[👉]    This may mean that the package is missing, has been obsoleted, or
[👉]    is only available from another source
[👉]    E: Package 'gcc-riscv64-linux-gnu' has no installation candidate

[Igor]

2 hours ago, schwar3kat said:

For a lark, I thought I would give it a try on armhf,

 

I think we don't need armhf support.

[going]

11 часов назад, schwar3kat сказал:

For a lark, I thought I would give it a try on armhf, seeing as I have access to an orangepi-pc running Armbian Jammy

I mounted an external drive on it.
Armbian-next build was not successful

What I am observing here is not a lack of support for this particular armhf architecture.
This is an incorrectly constructed construction algorithm in the assembly system itself.
The analysis of the architecture that needs to be built and the architecture on which the build system started working looks pretty trivial and it already exists.
To do this analysis and upload only what is required for this task does not look like something complicated.

P.S. This also applies to the master.

[Werner]

Finally I found some time to watch the video.

 

In the past we indeed followed the concept trying to centralize stuff and build it around forums which I have to agree is not ideal environment for developers.

While increasing fragmentation I think giving Github discussion a try is worth it.

 

To limit the freshly created fragmentation the cheapest solution would be to mark all  other communication platforms Discord/IRC as exclusively community only. No developer talk or discussion. Same for forums but including the business stuff.

 

Regarding moderation I don't think Github will need much moderation. Not in first place at least. Also here I'd say give it a try and see how it goes. Nothing we could not handle by yourselves.

 

Regarding discussions in PR after merge I suggest to lock conversation in those once the Github discussions are in place. I like the idea to automate that.