On Friday, 16 May, 2025 at 02:34:01 am IST, Étienne Mollier <emollier@debian.org> wrote:
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/builddNow 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.rstThank you so much for all the detailed information and the warm welcome. I’ve gone through the links and the team policy, and I’m happy to follow it. The tips about pbuilder, sbuild, and autopkgtests are really helpful as I get started.
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]:
SalsaCI - Debian Wiki[10]:
debci - Debian Wiki[11]:
trixie Freeze Timeline and PolicyPhew, 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
Friday’s a bit soon for me. How about Monday, May 19 2025 at 1700 hours UTC for the Jitsi meeting? Let me know if that works for everyone.
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. ;)
I will definately give it a try :)
| Bugs in packages maintained by debian-med-packaging@lists.alioth.debian.... |
|
|
| Bugs in packages maintained by debian-med-packaging@lists.alioth.debian.... |
|
|
| | Debian bug tracking system |
|
|
| | Debian bug tracking system |
|
|
| trixie Freeze Timeline and Policy |
|
|