New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add High Quality tag for some apps #678

Open
wants to merge 2 commits into
base: master
from

Conversation

Projects
None yet
3 participants
@maniackcrudelis
Copy link
Contributor

maniackcrudelis commented Feb 1, 2019

Following #677, here a proposition for some apps which can be the first to be tag as Featured. So we could start the new feature.
That's only a proposition to begin with this new tag.

Those apps are only apps maintained by members of apps group, considering that one of the requirement is to accept that the group will have a look to each PR. It seems to me that it would be better to start with apps from the group itself.
Obviously one would notice that most of them are my own apps. Indeed, I don't need a long and harassing review to know what the status of my own apps. And I know that they already respect the requirements.
Also, I intentionally removed apps which used too much factorization in _common.sh, since I'm again such way to code apps here. I'm still in favor of keeping scripts clear and simple, and to stick to the template.

I notice also that cachet, garradin and hubzilla miss a testing branch.

This PR is only a proposition to start a list of Featured apps. It could be discussed.
And, finally, this PR has only a meaning if #677 and the global idea of this tag is accepted.

This PR should be merged after #677

@maniackcrudelis maniackcrudelis requested a review from YunoHost/apps Feb 1, 2019

@Josue-T

This comment has been minimized.

Copy link
Contributor

Josue-T commented Feb 1, 2019

Also, I intentionally removed apps which used too much factorization in _common.sh, since I'm again such way to code apps here. I'm still in favor of keeping scripts clear and simple, and to stick to the template.

Why ?? I don't really think that duplicating the code is the best idea...

@maniackcrudelis

This comment has been minimized.

Copy link
Contributor Author

maniackcrudelis commented Feb 1, 2019

I was expecting that, especially from you :)
The reason is quite simple, our apps scripts have a standard template, which make packages so easy to create.
That template is also what makes reviews and fixes easy and painless, we don't have to navigate between multiple files to find what going on.
Obviously, as developers we all have learned that it's better to factorize the code as much as possible to reduce maintenance. But here, we're in a specific situation, where we often have to review code from others devs. Really often ! And there's nothing worse than to have to understand how the code is built to be able to review, especially as we're supposed to have a clear template, used by everyone.
As I have often reviewed packages, as well as I've fixed them. I know perfectly how painful it is to have to jump from file to file and from function to function to retrace the (initially) straight flow of the script. Even more when I have to use git blame, it's then a real pain in the ass since git blame doesn't work with multiple files.
I loose an incredible amount of time struggling with that kind of code.

So for all those reasons, I keep thinking that factorizing the code in app packages is not a good idea. And honestly, we're not changing those parts of the code every day, duplicating them is just better for all other devs who will have to review your code.

@maniackcrudelis maniackcrudelis changed the title Add featured tag for some apps Add High Quality tag for some apps Feb 20, 2019

@Josue-T

This comment has been minimized.

Copy link
Contributor

Josue-T commented Feb 20, 2019

I still think that there are no reason to discriminate the factorized apps. I see nowhere a specification for app packaging which say that code factorization is not authorized. All software factorize the code, so I don't see any reason to disallow this practice for this code.

@YunoHost/apps what do you think about that ?

@JimboJoe

This comment has been minimized.

Copy link
Member

JimboJoe commented Feb 20, 2019

I'm not opposed myself to code factorization. Considering example_ynh provides an example/guide/template without using factorization, I do think that people using factorization will have a greater chance to know what they're doing, and I'm not in favour of opposing to that practice.
We'll still have to review the changes, but the main idea of the process change is based on the fact we don't have much time, so we'll have to be a little more trustful toward featured apps maintainters I guess 😉

@maniackcrudelis

This comment has been minimized.

Copy link
Contributor Author

maniackcrudelis commented Feb 20, 2019

I had to work on our official apps, and I'll continue to do so for next days/weeks.
That's a fucking hell to have to work on apps with factorization. You can't rely to the template, you have to go through multiple files and functions to find what's going on.

I wouldn't oppose if packagers were working on their own only on their apps. But that's not what happens. We have really often to work on the code of someone else. Using a template is really easier when you have to check an app and find what's not working or what to update.
I was able to work really fast on apps that respect the template, but I loose a lot of time and serenity figuring out how some apps were working.
That's for the first part, about packagers who know how to deal with bash. But don't want to loose time figuring out how the fuck another guy made his package. (Where we're supposed to have a clear and easy template)

The other part we have to consider is all our newbies packagers who start or will start.
With a clear and easy template, any new packager willing to help will be able to take back any unmaintained package and fix it or to propose any update on a maintained package.

If you really prefer to code every one on its side, I can also stop restraining myself when I code an app and just code as I want. Like some of my helpers.
But I don't think it would be really clever to just think about how it could convenient for ourselves to code as we want.
We have to think globally about our packages.

Otherwise I could also stop doing the shitty job of rewriting all those shitty apps with non standard code, and let you loose your time trying to have easy apps to maintain.
Or just stop trying to have a clear template for everyone, stop trying to have apps that are easy to build and maintain.
If you don't care, why should I !?

@maniackcrudelis

This comment has been minimized.

Copy link
Contributor Author

maniackcrudelis commented Feb 20, 2019

Sorry if I'm a "little bit" upset about that. But I really do loose a lot of time and serenity dealing with those kind of apps. And that happens too often.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment