Consider migrating j-d-g to a group/organization-like project and clarify maintenance and support situation about jenkins-debian-glue HOT 8 OPEN

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

from jenkins-debian-glue.

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.

from jenkins-debian-glue.

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

from jenkins-debian-glue.

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.

from jenkins-debian-glue.

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

from jenkins-debian-glue.

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/

from jenkins-debian-glue.

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

from jenkins-debian-glue.

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

from jenkins-debian-glue.