Consider migrating j-d-g to a group/organization-like project and clarify maintenance and support situation

[mika]

jenkins-debian-glue (j-d-g) is >9 years old nowadays (wow!) and certainly had its moments and gained attraction, e.g. at PostgreSQL's Apt, kamailio.sipwise.com (also see https://github.com/sipwise/kamailio-deb-jenkins), Wikimedia, FreeRDP, LLVM and Maemo, to just name a few, and internally at several companies (which I'd be more than happy if they'd show up here with their name attached :)).

My priorities and interests shifted over the last few years though and I'm no longer able to invest large amounts of my spare time into j-d-g. It might make sense to decide how to proceed from here, to not put any existing or possibly new users into a situation with false assumptions.

On the one hand I'm not sure if there's any will or need at any of the projects mentioned above or any companies relying on j-d-g to push it further. As I'm aware, some use j-d-g as a base and diverged from it, others use it as-it-is and it just works™ for them. On the other hand, it would be a shame if there actually is further interest in j-d-g and I'd be just shutting the project down.

So I'm asking for feedback from users as well as contributors, what's your point of view regarding j-d-g? Who is still interested in keeping j-d-g alive and might be even give a helping hand?

For example @df7cb (of PostgreSQL's Apt fame) volunteered to be around for consulting, as well as @parazyd (from Devuan and Maemo projects). Pinging further contributors like @linuxmaniac, @sylvestre, @hashar and @zeha what's their take on this.

tl;dr: if there is enough interest and helping hands to keep j-d-g alive and ongoing, I'm willing to put j-d-g into a group/organization(-like) project and would love to hear from users/projects/companies using j-d-g!

[taurus-forever]

Sipwise is actively using j-d-g and depends on it in a daily routine (we deploy code in only Debian packages for CI/CD).
For sure, we will continue participating in a j-d-g opensource life.
Also, Sipwise is an active maintainer of Kamailio packages and rely on j-d-g there.
We are uploading all internal changes back to j-d-g project and are planning to do it in the future.
Thank you @mika for the nice opensource product and years of support!!!

[parazyd]

Regarding Maemo Leste (and Devuan), I'd be happy if this project isn't abandoned :)

I support the option of transferring j-d-g into a separate organization. I suppose it will also be a better incentive for collaboration.
Personally, I believe I can find the time to help out with maintenance, as in Maemo Leste we're using j-d-g directly from here, and I think it would be nice to have an actual upstream where we can propagate changes and fixes rather than just "secretly" maintaining it ourselves.

[sylvestre]

For apt.llvm.org it just works! I didn't need to do changes for years.
So, well done! ;)

[df7cb]

For apt.postgresql.org I ended up adding more and more patches so at some point I rewrote the scripts because the difference had become really huge. But I guess this was mostly because I was an early adopter when we started in 2012, and looking into merging back makes sense. (My stuff is at https://git.postgresql.org/gitweb/?p=pgapt.git;a=tree;f=jenkins for those interested.)

My vision would be to have something for building Debian packages that mirrors the capabilities and usability of what SuSE's open build system (OBS) does for the RPM world. Afaict we don't have such a thing yet in Debian.

I'm hesitant to promise I can actually work on that (the list of packages with my name on in Debian has grown to over 140), but I'm definitely here for listening and discussing ideas.

[hashar]

Thank you @mika for opening the topic and I am happy to see a lot of other people and organizations are relying on j-d-g.

For the context, I work for Wikimedia Foundation, I have setup and maintain the CI infrastructure there (as well as a bunch of other duties). My first attempt at automatizing the build of a Debian package was In February 2013 and that was really just three lines of code which probably did not build much. @azatoth introduced j-d-g to our stack and surely I have never looked back. Over the years, the few issues I have encountered either: already had a fix or were rather easy to implement a fix for. One sure thing, @mika, you have always been a very reactive upstream in my opinion.

At Wikimedia, we use cowbuilder images we self provision ( https://github.com/wikimedia/puppet/tree/production/modules/package_builderhttps://github.com/wikimedia/puppet/tree/production/modules/package_builder ) with some custom hooks maintained by the SRE team to align them with our versions and inject our custom distribution when relevant. For production deployment, packages are build manually as a stop gate, otherwise the rebuilds use the exact same cowbuilder images. The use case for j-d-g is that the Jenkins jobs are made absolutely stupid, beside cloning the repository and applying the proposed patch(es), the jobs just invoke the j-d-g helpers and magic happens.

So in short, you have done an excellent job at baby sitting the project, and the stack itself seems to fulfill its purpose with little very little bugs. I guess that explains why the project is sleepy: « it just works ™ ».

Now to the point.

I have definitely interest in the project, and I can imagine I can get people at Wikimedia interested into it. Wikimedia SRE team has been grown partly by hiring Debian Developers since their profiles tend to match our culture and Wikimedia is entirely based on the Debian distribution. There might be a way to have some additional help from them.

I would myself be happy to get involved, though definitely not in any leadership capabilities since I have already a lot of things on my plate. I am in favor of migrating the maintenance to a shared organization, Github probably makes a lot of sense right now, then it might be interesting to use Debian Salsa to gain exposure to the Debian Developer community. But one thing at a time :]

[mika]

Thanks everyone for your feedback! This is very honoring for me and I'm very proud of our friendly and positive community around jenkins-debian-glue! 😊

The feedback is very clear and I'll work on making j-d-g a shared project. Please give me some time for doing so, if anything should pop up until then please feel free to reach out to me.

Thanks again! \o/

[rbott]

Hey @mika, thank you for all the work you have put into j-d-g in the past years. We have been happily using it at sipgate for the past seven years, but only recently started to migrate over to something we have build ourselfs.

We wanted to replace chroots with docker in j-d-g- but eventually figured out that we are actually only using a subset of the features available and re-implemented that subset around docker build containers. Our main reason was that we were facing more and more issues with the stability of the chroot environments (which was probably related to the amount of tiny hacks/pbuilder hooks we added here and there over time 😄). In any case, j-d-g has helped us to unify our build/delivery processes a lot, thanks again for the great work! ❤️

[linuxmaniac]

@mika so after two years. What is your position on this nowadays?