Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

mika opened this issue Nov 6, 2020 · 7 comments


Copy link

mika commented Nov 6, 2020

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, (also see, 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!

@mika mika self-assigned this Nov 6, 2020
@mika mika added the question label Nov 6, 2020
@mika mika pinned this issue Nov 6, 2020
Copy link

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!!!

Copy link

parazyd commented Nov 6, 2020

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.

Copy link

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

Copy link

df7cb commented Nov 6, 2020

For 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;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.

Copy link

hashar commented Nov 6, 2020

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 ( ) 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 :]

Copy link
Owner Author

mika commented Nov 9, 2020

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/

Copy link

rbott commented Nov 9, 2020

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! ❤️

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
None yet

No branches or pull requests

7 participants