Haiku is proud to once again be part of the Google Summer of Code.
Over the summer, students will work on improving Haiku
and related applications, with help from our mentor team. Google gives the
students a stipend, which allows them to work full-time on the project without
the need to find another job.
This is a companion discussion topic for the original entry at https://www.haiku-os.org/news/2018-02-14_back_into_google_summer_of_code/
the topic “Google Summer of Code 2018” existing twice.
But the second one is normally for 2017. The links for the second one are right. They show to 2017 and the first one to 2018. But as I said, the second topic name is wrong.
Looks like another “reason” to delay a beta reelease.
The release will be made when it’s ready. GSoC does not make us move back in that regard. With the newly set up Gerrit tool, it is much easier to manage a separate release branch, and we may even prepare it before the GSoC coding period starts (we have about 3 months left).
If GSoC and GCI were reasons for delaying the release, we would never make any release: these two programs keep us busy year-round, anyways (this year the GSoC application period opened just as GCI students were sending their final tasks).
But Haiku isn’t a single-man project, so while I am org. admin in GSoC (and scottmc is org. admin for GCI), someone else can take care of the release work.
I’m more worried about kallisti5 moving houses, and mmlr being very busy with paid work again, as we need a little help from them to set up the package repositories for the release. Whenever they can dedicate some time to this we can start the release process.
Is this something strictly they, or another dev need to do? What skill set is needed for that task?
It’s not a matter of skills, but having ssh access to the relevant servers. The setup should be mostly boring editing of configuration files, I think.
So it’s a matter of “dad took the only set of keys to the car with him to work,” so to speak.