Pre-GSoC 2026 general conversation

cvvergara · December 26, 2025, 5:29pm

Hello and welcome to the potential OSGeo-GSoC-pgRouting applicants:

This thread is for a general conversation about the applications.
General questions can be posted here such as: Did OSGeo get accepted as a mentoring organization?
For particular questions such as: I have a PR here (link to PR) and I can’t fix … can you help me?
use the introduction thread you created.

As a start I will comment about the beginning of the 2026 timeline:

January 19 - 18:00 UTC Mentoring organizations can begin submitting applications to Google
February 3 - 18:00 UTC Mentoring organization application deadline
February 3 - 18 Google program administrators review organization applications
February 19 - 18:00 UTC List of accepted mentoring organizations published
- At this point in time we will know if OSGeo gets accepted as a mentoring organizations. If it is then pgRouting is participating on GSoC 2026
- Tasks and ideas might change up to this period on the GSoC Ideas 2026
  - Announcements of changes will be done in this topic.
February 19 - March 15 Potential GSoC contributors discuss application ideas with mentoring organizations
- Ideally by this time you have 100% of the tasks done
- Ideas might be added due to interest of the applicant and tasks might change for that new idea on the GSoC Ideas 2026
- All ideas and tasks covered before this period remain valid for all other applicants.
March 16 - 18:00 UTC GSoC contributor application period begins
March 31 - 18:00 UTC GSoC contributor application deadline

Basically you have 15 days to submit your application
Applications need:

100% of tasks completed
No use of AI to write the application

Note: this thread only applies for pgRouting within OSGeo, some other OSGeo projects might have different rules and means of communication.

cvvergara · December 26, 2025, 5:43pm

Hello all

Changes on task-4

Note about commits:

Use a meaningful commit message to the project

do not use: task4 … that is meaningful for the application but not for the project,

Something like: clang-tidy: check and fix cppcoreguidelines-avoid-reference-coroutine-parameters

Do a commit amend if there is a need to change the commit message and force the push

It is a commit per cppcoreguidelines that is added/fixed

Examples:

Add cppcoreguidelines-init-variables
- That is what the commit is doing
- The task is incomplete as its not fixing the warning generated
- The applicant needs to add a commit that fixes the warnings
This series of commits are very nicely redacted

Not good:

Use default member initializer for m_num_examined
- Add cppcoreguidelines-use-default-member-init & fix dijkstra_visitors.hpp would be a better choice

cvvergara · December 26, 2025, 6:39pm

About task 4

You are to keep in mind many things:

Don’t use a check that has been used by someone else

#3009 , #3011 and #3013

are using the same check cppcoreguidelines-init-variables

You will be doing double work:
Suppose that #3009 finishes all the fixes for that check. the PR will be merged and when you rebase (read bellow about keeping your branch up to date) the changes you did were useless, because the problem do not exist any more.

We need to fix everything:

git checkout upstream/develop

Edit .clang-tidy

more .clang-tidy 
Checks: >
    google-*,
    -google-readability-casting,
    clang-analyzer-*,
    clang-diagnostic-*,
    cppcoreguidelines-*

WarningsAsErrors: ''
HeaderFilterRegex: './include'
FormatStyle:     none
InheritParentConfig: true

WarningsAsErrors: ''
HeaderFilterRegex: './include'
FormatStyle:     none
InheritParentConfig: true

Note in my run.sh I have:

CXX=clang++ CC=clang cmake  -DUSE_CLANG_TIDY=ON  -DBUILD_HTML=OFF -DPOSTGRESQL_BIN=${PGBIN} ..

I execute my run.sh

rm -rf build/* ; bash run.sh &>> get-problems.txt

and get the problems

grep cppcore get-problems.txt | awk -F 'cppcore' '{print "cppcore"$2}' | sort | uniq
cppcoreguidelines-avoid-c-arrays]
cppcoreguidelines-avoid-const-or-ref-data-members]
cppcoreguidelines-avoid-do-while]
cppcoreguidelines-avoid-magic-numbers]
cppcoreguidelines-explicit-virtual-functions]
cppcoreguidelines-init-variables]
cppcoreguidelines-macro-usage]
cppcoreguidelines-narrowing-conversions]
cppcoreguidelines-no-malloc]
cppcoreguidelines-non-private-member-variables-in-classes]
cppcoreguidelines-owning-memory]
cppcoreguidelines-prefer-member-initializer]
cppcoreguidelines-pro-bounds-array-to-pointer-decay]
cppcoreguidelines-pro-bounds-pointer-arithmetic]
cppcoreguidelines-pro-type-const-cast]
cppcoreguidelines-pro-type-member-init]
cppcoreguidelines-pro-type-reinterpret-cast]
cppcoreguidelines-pro-type-union-access]
cppcoreguidelines-pro-type-vararg]
cppcoreguidelines-slicing]
cppcoreguidelines-special-member-functions]
cppcoreguidelines-use-default-member-init]
cppcoreguidelines-virtual-class-destructor]

So watch what others are doing so you do not do something that might be merged

First come first served

I am reviewing the Pull requests in order, first #3003 then #3004 then #3005 etc …

In the review 2 things might happen

Request work
Merge

Work requested

When you have work requested: see what is asked.
The majority either:

Did not fix a warning
- Maybe you could not figure out how to compile locally to see the warnings
- Maybe you could not figure out where to look on the CI to see the warnings
- Maybe its work pending
Fixed only one warning

The task is to fix all the warnings generated because of the new check.

Some of the checks generate 30 warnings
Some of the checks generate 4 warnings that look like 100 because the file is used everywhere
Some of the checks generate zillions of warnings.
When I made the review, for some of you I limited the files where you are to fix the warnings

Next review: first come first serve

When you think you have advanced on the work please click on the button

What will happen: I will do the best of my efforts to every Mexico morning (More or less late afternoon in India) I will review the ones that are ready for a second review.
First come first served, maybe I only find PR 3100 and 3200 as ready for review then I will review 3100 and then 3200 after.

It might happen that you get more things to do before the PR gets merged.

Careful: keeping your branch up to date

Before you start working (on any project)
Lets have the following remotes

origin: its the clone of your fork of the project
upstream: its the main repository of the project

Start your day with

git fetch upstream

In our case the modifications are to be done to develop.
If you see that the develop branch has changed do a rebase to your working branch:

git rebase upstream/develop

Fix conflicts, and when the rebase has finished continue working.

Merged

When it gets merged, you are very happy

If it never gets merged, don’t be sad, just make sure that you are following the reviews in the best of your abilities.
Not everything gets merged as an example here are some of my open PR on another project. On my closed PR some were merged and some didn’t make the cut.

cvvergara · December 27, 2025, 5:44pm

Hi all,
Some of the forks of the main repository are missing actions:
For example shows

make sure the actions run in your fork.
Probably you need to activate the github actions

cvvergara · December 30, 2025, 7:39pm

Hi all

When you make your PR to pgRouting keep in mind:

The pgRouting project has no task 4

Think over your PR and commit message:
Don’t use: " … task 4"

The projects do not care about your fork

Also don’t add commits to fix your fork actions do it in another branch, or in your fork but not on a branch that is used for a PR

Instead of image use a link:
For example this message

Could be:

As per the instructions given in discourse i enabled the github actions for running the CI workflow ->i pushed .clang-tidy adding a blank line only so that the CI workflow will run and the output is visible in my fork repo.

And remembering that we dont care about your fork that is a comment to put on your issue task so for this example: here

Don’t forget put on your the link(s) to the PR(s) (merged or not) that you create
So for example: here and here

Regards

cvvergara · January 3, 2026, 6:26pm

Important:

GSoC tasks will be reviewed as such when we know OSGeo is participating on GSoC 2026
pgRouting PR will be reviewed when the actions on your fork and a reasonable PR message written by you is on the PR.

Not so important

I would like you to add an emoji to each message in this thread that you read.

Changes on GSoC-Ideas: 2026 tasks

On both forks GSoC-pgRouting and pgRouting

Enable actions on your fork
The initial PR message must be written by you

About reviewing the PR to pgRouting

For me to review the PR’s on both repositories, spcecially on pgRouting:

The actions on your fork must be running
The first comment about the PR must be written by you

The steps I will take for the review

First step

If its a draft I will not even open it.
If its not a draft I will proceed to second step.

Second step

At the top of the PR I will click the link of the branch that wants to be merged

I will mark it as draft and wont worry to check it if the actions are not running on your fork if I see something like this.

I will proceed to the third step If I see this (or something similar) :

(Don’t forget about the first step)

Third step

I will mark as draft if I see something like this on your PR message

If I see your personal comment for example like this one I will proceed to review:

Status of PR

We have 3 status of PR

Already merged
Marked as almost ready for merge
The rest

Already merged

Make sure that the actions are running in your fork
Make sure you have a personal comment in the first comment of the PR

Marked as almost ready to be merged

There are some PR that are were reviewed before this rule that have the following labels:

Maybe they are missing:

The actions running in the fork
and/or The personal PR message

For pgRouting point of view:

The PR are almost there
They will be merged

But if they are not merged yet I will follow the steps above and fall into the category of the rest.

The Rest

We will be very happy to have your changes on pgRouting regardless of GSoC.
The tasks require to have your actions working an a personal message on the PR if you fail to do that then

for GSoC terms: We wont even bother to read your application.
for pgRouting terms: After the GSoC application ends I will review the PRs and start/continue a conversation on the steps you need to do to have the PR merged.

Regards
Vicky

cvvergara · January 5, 2026, 4:24pm

The monologue of my thoughts

I was looking at the PRs to pgRouting and the times I ask for changes and reconvert to draft.

Trying to put on the contributors shoes:

First of a all, You are contributing looking for the opportunity to participate on GSoC program, but these PR are for a software that anyone from anywhere can use.

Therefore to have the PR merged is no game, is a very serious matter.

Now because of the tasks for GSoC and having in mind that your ultimate goal is the opportunity to participate on GSoC program:

The steps where I check if the actions are running on your fork and that the you wrote a comment (besides the rabbit’s summary) is part of that GSoC mind. (these 2 requirements are part of the tasks)
The merge is not a requirement on the tasks.
When you in the future want to contribute to any other open source project: have the CI running on your fork (what ever the project use for CI) and make “nice PR”

Everything else:

do this
do that
Focus on this
Focus on that
Restore this file
Reducing scope
Fix only this
Use C++ comments
Remove comments
Do formatting
Restore .clang-tidy
etc

Are part of:
we want to merge the PR to the repository
Regardless of the message of the PR or of the actions on your fork
So if at the end of the GSoC contributor application deadline (March 31) There are still un-merged PR we can still work on the PR merge Regardless of the message of the PR or of the actions on your fork
If you close the PR then that will not be worked out at this stage.

In general:
When working for a PR of any project, create zillions of branches, with zillions of commits, once you get to the code you want to merge, create a new branch with basically the summary of changes:

For example:
For this PR from GSoC last year which has listed the zillions of branches with the zillions of commits on each one the PR is done cleanly with just few commits

end of monologue

cvvergara · January 6, 2026, 9:03pm

The conflicts have started:

Please fix them.

You can use the browser
But be very careful.

otherwise do:

git fetch upstream
git checkout upstream/develop the_offending_file.ext
git difftool -t meld -y HEAD

That will show on the left whats on upstream develop and on the right your contents

My difference is a mistake, so I can remove it

If you haven’t installed meld, please do, I use it all the time.
I don’t like to fix on the browser, because, well I always mess up, I mess up a little less using meld.

Regards

cvvergara · January 11, 2026, 7:23pm

Hi all

The contents of .clang-tidy have changed drastically
We have 3 PR pending to be merged:

Please do:

git fetch upstream  # to get the most recent changes
git rebase upstream develop # this will start applying your commits like starting from scratch

Fix the conflicts

Not clang tidy

Maybe in some other PR the files were modified on the same lines you are modifying
- Be careful

clang-tidy

Now in clang tidy: instead of adding the check, remove the check you are testing

For example:

Checks: >
    ...
    cppcoreguidelines-*,
    -cppcoreguidelines-avoid-c-arrays,
    -cppcoreguidelines-avoid-const-or-ref-data-members,
    -cppcoreguidelines-avoid-do-while,
    -cppcoreguidelines-avoid-magic-numbers,
    -cppcoreguidelines-explicit-virtual-functions,
    -cppcoreguidelines-macro-usage,
    -cppcoreguidelines-narrowing-conversions,
...

If fixing cppcoreguidelines-avoid-const-or-ref-data-members then
For example:

Checks: >
    ...
    cppcoreguidelines-*,
    -cppcoreguidelines-avoid-c-arrays,
    -cppcoreguidelines-avoid-do-while,
    -cppcoreguidelines-avoid-magic-numbers,
    -cppcoreguidelines-explicit-virtual-functions,
    -cppcoreguidelines-macro-usage,
    -cppcoreguidelines-narrowing-conversions,
...

Regards 
VIcky

cvvergara · January 13, 2026, 2:34am

Monologue about updating the PR

a,b,c,d are people that are making each one a PR to a repository

b is fixing problem x
c is fixing problem y

They both see:

class foo {
int pi;
foo(){pi = 3.1416};
}

Fixing problem x:

class foo {
int pi;
foo() : pi(3.1416) {};
}

Fixing problem y:

class foo {
static int pi = 3.1416;
foo()  {};
}

But then the fix of problem x is merged, and the fix of problem y is rebased to the latest contents