Hi Harish, TL;DR: I hoped to send a quick message, but the content kind of inflated. To summarise: I tried to gather information and entry points which I believe could be useful to you if you're interested in Quality Assurance steps involved in Debian Med (by the way to you agree to the team's policy?). After that, I attempted a time and date proposal for a Jitsi meeting tomorrow, if that's not too short a notice. I ended with an idea to help creating bonds with the Debian community. Pierre Gruet, on 2025-05-15: > Hello Harish, > > Le 15/05/2025 à 19:16, harish chavre a écrit : > > Hi Debian Med team , > > > > I am excited to formally introduce myself. My name is Harish Chavre. I > > have been a part of debian community member since 2020 and have > > previously worked on a few Debian packages, especially related to > > Node.js. I am very grateful for the opportunity to contribute through > > GSoC 2025, under the project "Quality Assurance and Continuous > > Integration for Biological and Medical Applications inside Debian." > > > > I am currently learning more about CI/CD pipelines and autopkgtests, and > > I am looking forward to improving my skills while making meaningful > > contributions to the team. Thank you for giving me this opportunity to > > be part of Debian Med. It truly means a lot. > > Welcome! It is great to have you onboard for GSoC :) Seconded, thanks for your interest in Debian and the work you started on bitseq and metaphlan autopkgtest definition! I also happen to have started regular contributions to Debian on 2020, although I've been around user community for a wee bit longer and an end user myself since 2010 or so. :) I think most of the below was already discussed in private mail exchange or on the Debian Med instant messaging channel[1], but it might be useful to have these links handy for ulterior reference, and for the benefit of others. You already received the Debian Med Team Policy[2] but I don't recall something: do you accept to follow the Debian Med Team Policy? [1]: https://app.element.io/#/room/#debian-med:matrix.org [2]: https://med-team.pages.debian.net/policy/ Having contributed to existing package, you may be already using one of pbuilder[3] or sbuild[4] to containerize your build and test environments (or maybe even something else); if not, you probably should consider trying these tools. pbuilder is codified in the Debian Med Policy and sbuild is implemented in Debian package buildd service[5]; nowadays I tend to favor sbuild over pbuilder, but opinions may vary. We're not into autopkgtest and continuous integration yet, but understanding these is in my opinion a prerequisite, from a technical perspective. [3]: https://wiki.debian.org/pbuilder [4]: https://wiki.debian.org/sbuild [5]: https://wiki.debian.org/buildd Now about autopkgtest, I have been doing a fresh tour of resources around them and rediscovered a couple of nice wiki pages describing the tool[6] and some best practices[7] around implementing them. When there is a detail about autopkgtest that is unclear to me, I also keep handy the document codifying it's specification: the wiki references the copy of the document on Salsa[8], although I tend to refer more easily to the copy available below /usr/share/doc/autopkgtest/. Autopkgtests differ from regular build time unit tests in the sense that autopkgtests' primary purpose is to automatically ensure that a package is operating as reasonably expected by their end users after having been installed on the system. Therefore, a good autopkgtest will emulate as reasonably possible how a real user will make use of the package in typical scenario; corner cases may be added if end users report bugs in specific use cases via the bug tracking system[14]. [6]: https://wiki.debian.org/ContinuousIntegration/autopkgtest [7]: https://wiki.debian.org/ContinuousIntegration/AutopkgtestBestPractices [8]: https://salsa.debian.org/ci-team/autopkgtest/raw/master/doc/README.package-tests.rst If you're into continuous integration, you might also like to learn about Salsa CI[9], although in the current continuous integration methodology in use by the Debian project, it is more of an optional or pre-approval step before upload. The "real" continuous integration and deployment is carried in part by debci[10], which implements one of the steps governing Debian packages migration from sid to testing: identification of autopkgtest regressions (which in turn will be perused by other tools to prevent migration of regressions). These steps occur after packages have been uploaded to sid. When packages implement autopkgtest like the ones you are working on, they benefit from bonuses translating into faster migration from sid to testing, and when there is an upcoming Debian stable release (like at the moment, in preparation of Debian 13 trixie), autopkgtest allow for automated migration of packages even during Hard Freeze; the freeze policy is codified in a document on the Release Team's website[11]. This information is more contextual than essential for actual autopkgtest implementation, but they can be a good motivator to implement good tests. [9]: https://wiki.debian.org/SalsaCI [10]: https://wiki.debian.org/debci [11]: https://release.debian.org/testing/freeze_policy.html Phew, that's a lot of information! =° > > As the community bonding period begins, I would appreciate the chance to > > connect with the team. If possible, I would like to schedule a Debian > > Med video conferencing meeting at a time that works for everyone. It > > would be great to meet the team, receive feedback, and better understand > > how I can contribute during the coding period. > > This is great! Additionally it would be good for team members in general to > discuss during such online meeting. During the last years, a meeting was > periodically organized on Jitsi at 7pm or 8pm CEST. Maybe this is a default > slot we could try. Right, I think long time attendants may still attempt to join on the historical Jitsi Debian Med meeting room[12] even though the room name is not a public health emergency of international concern since mid-2023. I'm not sure what day would fit best. Tomorrow 2025-05-16 at 17:00 UTC might be nice for those who can make it, but might be of short notice for others, but could be a starting point. Harish, would 2025-05-16 at 17:00 UTC work for you? If so, I will attempt to make it on time after office hours. [12]: https://jitsi.debian.social/DebianMedCovid19 On another dimension, in my experience, help triaging bugs is a good and much appreciated way to meet the community of Debian contributors. The bug tracking system (BTS)[13] inherits from a mail based design from the mid-90s and may require some getting used to. Things you can do to help, are to look for unclassified bugs affecting Debian Med packages[14], attempt to confirm you are able to reproduce them, forward the information to their upstream development teams when applicable, wrap up patches if you feel confident about your fixes, or investigate complicated issues and report your findings. Triage and bug tackling may be off your GSoC topic, but it's not forbidden if you want to do something else to change your mind from time to time. You may note some bugs affect autopkgtest regression and may be more on-topic than others. ;) [13]: https://www.debian.org/Bugs/ [14]: https://bugs.debian.org/cgi-bin/pkgreport.cgi?maint=debian-med-packaging@lists.alioth.debian.org > > I am looking forward to working with you all. > > > > Best regards, > > Harish Chavre > > All the best, Have a nice day, :) -- .''`. Étienne Mollier <emollier@debian.org> : :' : pgp: 8f91 b227 c7d6 f2b1 948c 8236 793c f67e 8f0d 11da `. `' sent from /dev/pts/1, please excuse my verbosity `-
Attachment:
signature.asc
Description: PGP signature