Now my idea: a lot of these initiatives stop when there is a complete howto. There are still many great applications that are a great addition to NethServer funtionality, but lack a 1-command or 1-click install. My proposal is to try and gather as many community members that work on these applications to get them to a state that they can be added to NethServer-Nethforge repository. That way, they also have this great 1-click install from the webadmin interface.
To make this possible we need to pick period of time, when community developers can do an interactive session. During such a SPRINT maybe we can support a permanent video support channel with the option to share screens so multiple devs can work on the same module.
I know the most productive way would be to have this in a real life session, (for instance at a community congress or at something like FOSDEM) but I also understand that this is very hard to accomplish. So the second best thing that I can think of, is an online session.
If some of the Nethesis devs can be available for feedback too during such an event, we actually could get a huge progress on this.
What do you think? Would this be an option to try? Anyone willing to help setting this up? Some points to consider?
If you want to participate with this initiative, please add your name here: @robb
I know that I havenāt developed any modules, but I think this is a great idea - I hope that there is a lot of support for it and those who have made modules are able to get together to help have it integrated into a 1-Click Install.
Not sure what I could help with, but do let me know if there is anything I can help with. Iāll also keep track of this thread and will chime in when there is something I could possibly help with.
The problem is not the development of packages; to beta state at least. Then the testing of all possible configuration, environments and so no starts. We , or I, do not have a automated test environment so for me 1 hour development is at least 2 hours testing. Note you have to install a package a dozen times to loop true different configurations. And after this your are still not sure if itās oke, due to the single environment you are testing in.
Second is the maintenance of packages, again a lot of testing.
To wrap up, i like the Idea.
Be active in giving feed back of those valuable howtoās. The starting point of a package development is two steps ahead, the configuration is tested/reviewed in different environments.
Without active support of the community in testing, we end up with a lot of broken packages.
āSprintā sounds like āagile developmentā, which left a pretty rotten taste in my mouth the last time I dealt with it. But there are a few issues keeping my acme-dns module from going much further:
Testing. I know it works for me, but I donāt know if anyone else has even installed it, much less how well itās working in the field.
Server manager integration. Iād be starting from square 1 on this, and to do it right would need a degree of interactivity.
The acme-dns RPM itself really should be built from source, rather than using the developerās pre-compiled binaryābut I donāt know enough about Go and packaging to make that happen.
Automx seems to be in a mostly-workable state (though someone who knows more Python than I is going to need to track down why LDAP is failing) --at least, as far as I can tell. Again, Iāve had no feedback from others who have used it.
I just thought of SPRINT as an event where multiple devs work together on nethserver modules. For instance a day or a week(end). If we can manage to have some additional tools so communitcation can be more direct, I think we can effectively do a lot of work.
If you have a better name than āSPRINTā please say so, and I will change it on the spotā¦
Especially your points 2 and 3 are great options for the dev event.
I think the biggest win would be learning from more experienced developers so at the end we get more skilled developers in our community.
And about your first point: we could organize a ātestathonā and try to test with as many members as possible as many as (new)modulesā¦ (and get that testing software so modules can get āautotestedā)
I like the idea, I am always available to share what I know or to help, but indeed the hardness part is the free time that I am/we are always running after.
I know this week Nethesis is closed, lets see the inputs of others developers
That is too bad to hear. Itās not only important to have such a tool for the āemployedā devs, but also for all those community devs that try to get community modules done. IMO it would be a HUGE asset to the NethServer project if there would be a test environment for modules.
I think all major distributions have such a tool and IMHO NethServer should have one too.
Nethserver already has it: the community!
So far, we are doing a really good job. For now, the resources to implement an automatic testing suits doesnāt worth the outcomes.
Also you should consider another thing: if we put in place a testing suite, all contributions must pass all tests.
As you see, for now is still hard to gather simple contributions. If you add automated testing, the entry barrier will be much much higher.
I really like the idea of an automated test suite, but we are talking about months of development and a lot of money to running the infrastructure.
Fair enough.
Then letās go by the phrase of a very famous Dutch soccer player (Johan Cruyff): Every disadvantage has itās advantage: by not having an automated test suite, more work needs to be done by hand which means, more members get the opportunity to get hands-on experience with creating and testing modules.
Just an idea, but a closed forum for dev (why not on discourse) or an instant messaging on mattermost/hangout/ā¦ could be nice.
I would like something restricted to few people that you can help rather to answer to many people. Of course the goal is to bring/help people to code, so the goal is to integrate more and more people
I think the 2 biggest āmysteriesā of creating modules for NethServer are te e-smith layer and the specfile for the module/rpm. The e-smith layer is quite well documented in the dev manual The Spec file defines more or less what commands are run by RPM. I think the spec file should be high on the list for support. Maybe some basic explanation how the spec file is structured and how it must be used with NethServer modules.
I sure will help out! And I think many others also are interested. Maybe anyone interested can explicitly say so here? Then we can make a list of members that want to help and learn about creating NethServer modules.
During the event I think we should have a reasonably direct contact with all participants. I donāt know if a constant video stream will be effective or efficient. Maybe a chat channel would be better (on mattermost/telegram/IRC)
It might be nice to prepare a short webinar at the start of the event where the specfile is explained by experienced developer(s)? At the end of the webinar every participant will assign for a certain module. It would be great if 2 learner / inexperienced ādevsā would team up with 1 experienced dev. Would that work?
Before the event starts we should have a fair idea who is going to participate and on what modules we are all going to work. We can choose several applications/features to work on.
So we need a list of participants and proposed modules to implement.
The objective would be to have one or more working modules for NethServer at the end of the eventā¦
Again, I am just brainstorming here, please add and comment.
already done, but probably it should be updated or enhanced. I did also some others documentations (I am not the author of all)
What I can say is the spec file is a low level of understanding, set permissions and put files at the right placeā¦it is all ā¦One time I even built a rpm without the srpm, taking a spec file from another rpmā¦
I say this because the spec file is not the barrier from my point of mind, NS sticks on the fedora build line, it is something well documented that you can find elsewhere on the internet.
What needs to be well understood is more from my point of view the the topology of a module (the createlink is used to expand templates, launch services, trigger actions following an event) and also the file architecture of a rpm
This was for me something high once upon a timeā¦butā¦butā¦but something harder is the GUI
This is what I learned really at the end of the learning curveā¦nethgui is an interesting beast, made in the mind of @davidep, some people hates it, I learned to love it. It is powerful, easy, scalable but undocumented
I must be honest I started with formagick, after that all is easier
Of course all above should be a course, a documentation, a howto, a support for others developers but at the end, when a dev is debuging, writing documentation, speaking on discourse, he is not coding
Thanks @stephdl for the comment. If we take into consideration that the 2 main goals are:
getting more nethserver modules
get more active developers
Focussing on the 2nd goal, the creation of a module should be explained in a language a non-devver also understands. If we can manage to make some kind of recipe, step-by-step howto that could fit a large part of (web)applications, then we could have a great way to get more members familiar with creating NethServer modules.
Especially the general php/mysql based webapplications should be possible to fit into such a howto. Or am I very far off now?
I WIKIFIED the topic. If you want to participate, please add your name at the bottom of the first post.
In fact this is the simplest starting point for a new developer, a web application is simple, create a mysql database, make a apache conf, make the web application configuration (adjust mysql settings for example). Something better is to take a web application from EPEL (you wonāt care about update, others will work for you) and just do the work to do all configurations needed
It is a really good training.
Of course you/I will spent hours to make it workable
Aw, shucks. Iām just interested in self-hosting such code as I do, rather than relying on GitHub. And Phabricator looks like it might be a bit more heavyweight than Iād have a real use for.
Iām just interested in self-hosting such code as I do, rather than relying on GitHub. And Phabricator looks like it might be a bit more heavyweight than Iād have a real use for.