Official topic for apps group news


#28

These are good additions. Ok for me too.


#29

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).


#30

Hey guys,

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.


#31

Hi,

It’s a good idea !
Effectively, since several days my Raspberry Pi was “inactive”, but currently it works hard for CI Package Check :slight_smile:

ppr


#32

Hey

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.


#33

Hello guys,

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
#34

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


#35

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.


#36

Alright.

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 :smile:


#37

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…


#38

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.


#39

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.


#40

@JimboJoe, @frju365, @Josue, @Kayou I would like to have your opinion about those modifications:
@kanhu already said he agree.

  • The new app list apps.json
  • The 3 states for an unmaintained app.
  • The tags featured and high_quality
  • 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.


#41

I don’t understand the difference between the two here (high quality and featured). I’m thinking that we will really be lost. One tag is for me enough. We are not a so big community to have level + tags… well it’s only my point of view.

For the rest it’s ok.


#42

That’s all the point of the meeting we had !
The tag high_quality represent the level 8, for very good apps. That’s simply a way to replace Official apps.
The tag featured is for high_quality apps we would like to highlight for a moment. Like we would do with an app like Nextcloud or Mattermost.
That 2 different things but not that much work. There’s nothing special to do about Featured apps. The only thing will be to define a way to choose them. It was discuss of a poll, which looks like a good idea to me. There’s other things to define about it.

There’s 2 tags because there’s 2 different things we would like to do.
Give a special status to very well maintained apps. Because packagers are spending a lot of time doing it. And at least, for them we can says to the community that there’s quite safe.
And, highlight apps that are really wanted by the community. That’s 2 different purposes.


#43

OK. I’m convinced :wink: Let’s go for these two tags.


#44

Just writing here what I told to @Maniack_Crudelis directly: I agree with that proposal :wink:


#45

Paving the way for the new ongoing CI ci-apps-hq, I worked on the way the CI dev is getting automatically the jobs.
Initially it was getting jobs from the branches on official apps.
But since, we’ve decided to turn official apps into high quality, we should expect more and more of those. Or at least I hope !

Nowadays, we have a strong limitation with external pull request, PR made on forked repositories and trying to be merged in the official repo. Because those PR aren’t on local branches.
Each time, one of us (me…) have to connect to the server to add it manually, so we can have a test from the CI on those PR.
We can’t expect that manual action with high quality apps, considering we would have a lot more of them.

So now the CI dev is getting its jobs from the github API, for each PR, not regarding anymore the branches themselves.
The big changes about that are:

The idea behind is first to not mixed PR from their branches, we could have many PR from testing from forked repositories. But you can’t have many time the same PR.
Second to simplify the naming of links in the PR, It would be simply the ID of the PR, and the same for each PR.

Also, we have, for example for nextcloud, a jobs https://ci-apps-dev.yunohost.org/jenkins/job/nextcloud_ynh%20PR174/, which is for https://github.com/YunoHost-Apps/nextcloud_ynh/pull/174. A PR from a forked repo. Without having to add it manually.


#46

While I’m building a new ci-apps-arm server, I update fingerprints for all raspi.

@rafi59, your raspi is unreachable on pcheck@rafi59.codelib.re -p 2244.
Same for you @jibecfed on pcheck@holcroft.fr -p 10777.
And @Gofannon on pcheck@gofannon.ynh.fr -p 62022.


#47

I moved ci-apps-arm to a new server on a scaleway VPS.
Because that way, it just works !!!

Maybe it will need a few hour for the dns to be updated.