solvcon sprint in COSCUP sciwork track (3rd August 2024)

[yungyuc]

solvcon will participate the sciwork track in COSCUP 2024. @YenPeiChen07 @ThreeMonth03 @tigercosmos will help lead the solvcon/modmesh sprint. This conversion is to discuss the sprint.

In the former discussion in emails, we identified the following things to do:

• Share the progress of the project so far.
• Fix minor (local) violations of the style guide.
• Encourage newcomers to ask for help in the solvcon channel on the sciwork discord server.

We would like to add straight-forward tasks (issues) for newcomers. Fixing minor style violations is one of them. It is not easy to create straight-forward issues for a scientific project like solvcon/modmesh. We need brainstorming.

[yungyuc]

@YenPeiChen07 Could you please help create an agenda for the solvcon/modmesh sprint in the track?

[YenPeiChen07]

This is an agenda in the track.

We have two parts for coding session in the track: 12:00-13:00 and 15:00-15:45. Contents in bold are still a tentative plan.

11:30 - 12:00 Project Introduction [*1]
12:00 - 12:15 (TBD) Share project progress (15 mins)
12:15 - 13:00 (TBD) Build project | Topic discussion (45 mins)
14:50 - 15:00 Project Introduction [*1]
15:00 - 15:30 (TBD) Build project | Topic discussion (30 mins)
15:30 - 15:45 (TBD) Summery and call to action (15 mins)

---

Project Introduction

We will introduce our project to all participants and maybe have a live demo during this time.

Build project | Topic discussion

Actually, for newcomers, they may spend much time to build modmesh. Therefore, we may assist in their building process and discuss some topics. If some of participants have build up the project, we could lead them start to do an easy issue.

Summery and call to action

Invite attendees to share their experience and encourage them to share their thought in our solvcon channel.

[yungyuc]

Thanks. We only have 1:45 in total for the code sprint, and the first part of 1 hour overlaps with lunch time. It is hard to get serious coding done.

And I don't really want solvcon/modmesh contributors to starve. Can we keep the first one hour light? We can grab some food and have casual discussions about the project.

It will leave us only 45 minutes for coding. It cannot accommodate a plan for serious coding, but is probably suitable for intensive brainstorming. If there is a black/white board, we can do some drawings for GUI and visualization.

I assume the agenda is still flexible for the "TBD" in it. I create a (publicly editable) Google doc. Feel free to add/remove/edit there.

[YenPeiChen07]

Yes, you are right. We can keep it light and have casual discussion during lunch time.

Also, I like a brainstorming for second part, which could have more connection with attendees. I add this in the doc.

About building project for newcomers, if we have good discussion and connection with attendees, we can help them discuss in our discord channel and follow up later. Building project may be minor part in our sprint. What do you think?

[yungyuc]

Helping newcomers to get used to the discussions in the solvcon channel sounds like a simple thing to do and maybe it fits well with the time constraints.

A sprint or F2F meeting is perfect for showing things that require interaction. F2F interaction is really helpful to ramping up someone in a discord channel.

[tigercosmos]

Some interesting things that are not hard:

• Adding RedHat into the CI
• Create DEB in the CI

[yungyuc]

Adding RHEL support and creating DEB in Github Actions does not look easy to me. Could you make a rough estimate of efforts involved?

[tigercosmos]

If we only support the core library (excluding QT), the task will be simpler.

1. For RHEL, a developer will need to download the Docker image for local testing and then verify the process of migrating the local changes to GitHub Actions.
2. For DEB, our Windows nightly build can serve as a reference. A developer may need to write a bash script to package all necessary files and publish them via GitHub Actions.

Both tasks are expected to take around 15 hours, but some preliminary results should be available within 4-5 hours.

[yungyuc]

It's a good estimate. Thanks. Something taking 4 hours may be too complex to be a simple task for a sprint taking 3 hours. We can still try, but maybe wouldn't need to expect for too much.

---

RHEL support and DEB creation do not seem to be very useful for the project at the moment. Every version of an enterprise distribution like RHEL and Suse needs specific porting efforts. RHEL support is not one-shot porting. DEB packaging is similar.

[tigercosmos]

I see. So maybe these two can be skipped.

[yungyuc]

We can probably think about other small tasks to do alone this line.

[tigercosmos]

A challenge one: remove the previous @ThreeMonth03 's hard-coded JSON with the new SerializableItem.

[yungyuc]

@ThreeMonth03 it seems that you have started to take the challenge. Maybe we can identify some derived work?