Hi everyone,
I’m a contributor to Picard and have been working mainly on file handling, detecting externally file change and save-pipeline correctness (recently around FileIdentity and related regression tests). I’m really enjoying working on the project and would like to continue contributing more in this area.
I’m also preparing for GSoC 2026, and Picard is the project I’m most interested in working on if it participates this year. I wanted to ask whether Picard is likely to propose a GSoC project under MetaBrainz this year, or if that’s still undecided.
In any case, I plan to keep contributing regardless — just wanted to understand the direction.
Thanks!
That’s still undecided, mainly because we don’t have much ideas about what would fit in a GSoC project. For sure it would be working on upcoming Picard 3.
Do you have any specific idea about what you would like to work on? We can figure out something if that’s the case.
I wanted to check something before I go further. Lately I’ve been working around file identity and save behavior in picard, and while doing that I noticed that Picard can still save to a file even if it was changed or replaced on disk after it was loaded.
I was thinking if improving how Picard 3.0 handles this case (detecting it reliably and then deciding what the right user-facing behavior should be(but in a review on code phw said it good if it’s only developer can know not the user)) would be considered a useful project direction, or if there’s another area you’d suggest I focus on instead. I just want to make sure I’m spending time in a direction that’s actually helpful for Picard.
@Zas Just wanted to follow up on my earlier message about possibly improvement how Picard 3 handles files that change on disk after being loaded. If that direction doesn’t seem like a good fit for a GSoC project, I’m very open to focusing on a different area for picard 3. I just like to make sure I align my proposal work with what would actually be useful for Picard.
Hi @deepak_80 . Thanks for the proposal. We actually didn’t have our own proposals for Picard related GSoC projects this year. Mainly because we are focusing on finalizing and stabilizing Picard 3. I personally also would not be fully available as a mentor as I cannot promise to have the necessary time available. But @Zas was generally willing to mentor, and I would be able to co-mentor.
For the proposal of the file overwrite behavior I think we can do additional functionality on top of your initial changes, but I actually don’t think the scope is fitting a GSoC project.
But we are open for other proposals. Do you have some idea? I’ll also think about this again and see if we can find something with the proper scope.
Sorry for the late reply. I had semester exams and was also looking into a macOS-related problem and JIRA issues, so I wanted to focus on that properly.
I agree that extending overwrite detection alone is probably too narrow for a GSoC project.
While working in file.py, I noticed that metadata comparison (update()), image state comparison, and external file identity checks (FileIdentity in the save flow) are implemented across different parts of the lifecycle. Save behavior is then determined procedurally based on these checks.
I’m wondering whether a stabilization-focused proposal around making this lifecycle and save flow more deterministic essentially building on the existing detection work and making reconciliation of metadata, images, and disk state clearer and more testable would be closer to the right scope for Picard 3.
For cover art specifically, I’ve also been looking at how ImageList and hashing interact with the save process. There might be room to improve consistency there as part of the same effort.
Does this sound like a more suitable direction? If so, I’d be happy to outline a more concrete plan.