Yes I shoud be back on Thursday ~ Friday - don’t hesitate to harass me if I forget about this
Same for me
Meanwhile, I’ve finished a small part of code to have a badge for each app from the CI directly, so we will have badges for each CI, stable, unstable, testing, ARM and jessie.
Of course, now, we have to wait for each test to be done before having all the badges.
For example on stable, we have these ones:
Hey guys, I’ve a question for you.
What about adding 2 protections rules for the master and testing branches of our official apps.
We already have a removing protection and a requirement of 1 approval before be able to merge a pull request.
I would like to add these 2:
- Add a second approval, to match the 2 LGTM of our PR template.
- Add a dismiss of all previous approval in case of new commit on the PR.
Ok for mee too
it’s ok for me too. It can be useful.
These are good additions. Ok for me too.
I’ve made some new developments on YunoRunner:
- we now have menu bar, wouhou!
- in reality it’s because we now have a page for all apps (instead of all jobs) https://ci-apps.yunohost.org/ci/apps/
- and one page per app that list all its jobs https://ci-apps.yunohost.org/ci/apps/opensondage/
- we also have COLORS NOW, because it’s fancy
- the homepage has been optimized, it was way too slow to load, now it loads only the latest done job per app, the running one and the scheduled ones
- yunorunner won’t silently crash if a job failed
- also did some cleaning on the job page and some links everywhere
Both the “all apps” and “per app” pages are dynamically updated like all the other pages (it was quite some job to do all of that).
I recently noticed that both the CI stable and ARM were down… And today that the CI ARM was again down…
So I implemented an alert in case one of our CI is failing too many times.
It’s not yet fully tested, but we should now have an email when a CI has issues.
It’s a good idea !
Effectively, since several days my Raspberry Pi was “inactive”, but currently it works hard for CI Package Check
Eventually, our testing/unstable CI is working.
This CI will be trigged by update of YunoHost in its branch testing or unstable. That’s precisely apt upgrades of the package which trig the CI.
Anyway, we can now check regressions on those releases.
Especially, right now, we have a series of tests running for YunoHost testing on this CI.
Feel free to have a look to it to see if there’s any regression on your own apps.
I noticed already a possible issue with the backup helper with php ini config file. Don’t know why yet.
We’re finishing our meeting this evening, there was a long discussion about what we should do with our Official apps and the Official list itself.
Mainly, the matter was about the fact that nowadays Official apps sounds for many people like apps maintained by the Apps Group. Which is clearly not true !
That leads to a situation where most of our Official Apps are not really maintained anymore.
Also, we’re not integrating any other Official Apps since a while, because we don’t want to have more apps to maintained.
This discussion started with the current will of a Featured apps list.
The conclusion was finally
- Official apps are not relevant anymore.
- We still want to highlight apps that are really well coded.
- We also want to featured apps that are interesting for the community.
So we decided many things:
- We will get rid of the Official list, and official apps. In a while…
- We will create a new list, possibly merge all apps into this new list and get rid as well of Community.
- To keep back the idea of “Featured” apps, as I had defined in my recent PR. We decided it would be better to redefined the level above 7 and make a manual level 8 with this criteria.
- Return to the idea of “Featured” apps, as Aleks as defined it, for apps that are interesting for the community. Maybe by a poll on the forum to decide which ones are going to be featured.
You’ll find the summary of this discussion on the pad.
But mainly, if I’m saying all of that here, that’s because I want you guys, member of @Apps group to tell me if you agree on the principle on this modification of our work.
Indeed, we wouldn’t have to take care of Official apps as we do now, nor reviewing PR the way we do it.
But we would have to validate demands for level 8, as they will have to be manually validated (by us), and, according to the criterion I’ve written, to validate any PR on this apps afterward.
So, it would be slightly different. And maybe, but not sure, an increase of our workload.
YunoHost 3.5 testing / Call for feedback
I thought that the “apps group” was in charge of the “Official Apps”. I took care of Dokuwiki because it was unmaintained and was hesitant to put myself as the packager and not “Yunohost organization”
The term “Official apps” leads me to believe that there were maintained by “Yunohost” and not people directly… So yes, there is a problem.
I should read again the https://yunohost.org/#/project_organization
As explain during the meeting, that a situation which is not clear. Also because at the beginning, Official apps were mainly apps from YunoHost core members. So it was sort of maintained by YunoHost.
This model doesn’t work anymore though.
An idea to add to the debate:
Should there be some “base applications” maintained by the “Group apps” or the community/app maintainers will decide which apps to maintain?
Some of the “Official applications” as defined now could become part of “base applications”. If they are maintained of course
Our concern is especially to be maintained.
I hope that maybe more maintainers will take care of apps with this new tags.
In the same time, I’m worried that many of our official apps will be unmaintained…
If someone is keeping the app to level 7. His work should be appreciated and the app should come in featured app. Otherwise it looses interest to keep the app level up to 7.
Featured app is good way to motivate every contributor.
Yep, actually the idea is even to reach the new level 8 to pretend to be a Featured app.
But the process for an app to be Featured is not yet defined.
We have discussed about a poll to ask to the community to choose for them. As we did for Official ones.
- The new app list apps.json
- The 3 states for an unmaintained app.
- The tags
- The new level 8.
- The modification of the levels, especially the level 4.
All is in the main PR, https://github.com/YunoHost/apps/pull/677
Also, I expect to talk about all those PR during the next meeting, on March 5th.