Bug#883529: ITA: buildbot,buildbot-slave -- Build automation system
Quoting Robin Jarry : Yes absolutely. The web ui itself makes use of the rest api: https://docs.buildbot.net/latest/developer/rest.html I personally use this api extensively from command line tools at work. It should be completely possible to have an official console client. ...or integrate some REST call into other software, e.g. Trac, GitLab... I had not thought about that. Why not, but I don't know how this works. Do I need to join this team first? To enter the PAPT (Python Applications Packaging Team), you need to read the Debian Python policy (which is a good idea anyway, because it describes how Python things work in Debian): https://www.debian.org/doc/packaging-manuals/python-policy/ Then write an email to the publich mailing list debian-pyt...@lists.debian.org and ask for membership in PAPT. Mention, that you like to package buildbot and that you have read the Python policy :~) For now, the source for buildbot Debian packaging is hosted on github: https://github.com/buildbot/debian-buildbot/ https://github.com/buildbot/debian-buildbot-worker/ And I have a fork with my work-in-progress: https://github.com/rjarry/debian-buildbot/ Thanks. In the next two weeks I will probably not have enough time to look at your work, but maybe later... Cheers
Bug#883529: ITA: buildbot,buildbot-slave -- Build automation system
2018-02-14, W. Martin Borgert: > Robin, many thanks for working on buildbot! > Very much appreciated! Don't mention it. It is a good thing to have it in Debian, it gives a lot of visibility and good reputation to the project. I'm glad to help! > At least for Node I reject the term ecosystem. Toxic waste dump? > > Sorry, just kidding. Hehe, so that is not only for java :) > Very good! If server and web ui are separated cleanly, it should > be possible to write alternative UIs, right? Like a console one > for us terminal aficionados. Yes absolutely. The web ui itself makes use of the rest api: https://docs.buildbot.net/latest/developer/rest.html I personally use this api extensively from command line tools at work. It should be completely possible to have an official console client. > If there are Python depends, that are not in Debian or too old, > do not hesitate to ask me, maybe I can burn some time. So far, the missing depends are projects that have not seen much activity since a long time. I am in the process of making them optional for building docs and running tests. > Btw. maybe you want to maintain buildbot (at least the parts mainly > written in Python) within the Python Applications Packaging Team > ? It is also at salsa: > https://salsa.debian.org/python-team/applications, but the packages > have not yet been migrated. I had not thought about that. Why not, but I don't know how this works. Do I need to join this team first? For now, the source for buildbot Debian packaging is hosted on github: https://github.com/buildbot/debian-buildbot/ https://github.com/buildbot/debian-buildbot-worker/ And I have a fork with my work-in-progress: https://github.com/rjarry/debian-buildbot/
Bug#883529: ITA: buildbot,buildbot-slave -- Build automation system
Robin, many thanks for working on buildbot! Very much appreciated! On 2018-02-14 21:38, Robin Jarry wrote: > This is hard for me to estimate the repercussions as I lack good > knowledge of the JS ecosystem. It does not look like a trivial task in > any case :) At least for Node I reject the term ecosystem. Toxic waste dump? Sorry, just kidding. > For now, I am focusing in having only the server and worker packages > (without any web ui) updated in debian with the latest upstream release. Very good! If server and web ui are separated cleanly, it should be possible to write alternative UIs, right? Like a console one for us terminal aficionados. > There is a small limitation in pybuild regarding building multiple > binary packages from the same source package (each located in > subdirectories). I talked with p1otr on #debian-python and he told me he > may have a fix uploaded soon(tm). That's good news! > In the meantime, I am struggling to make the tests run and docs build > with only debian dependencies. If there are Python depends, that are not in Debian or too old, do not hesitate to ask me, maybe I can burn some time. Btw. maybe you want to maintain buildbot (at least the parts mainly written in Python) within the Python Applications Packaging Team ? It is also at salsa: https://salsa.debian.org/python-team/applications, but the packages have not yet been migrated. signature.asc Description: PGP signature
Bug#883529: ITA: buildbot,buildbot-slave -- Build automation system
Hi Martin, 2018-02-14, W. Martin Borgert: > did the discussion about coffeescript vs ECMA6 already lead to something? We mentioned it a few times during the weekly meetings we have on tuesdays. We have been busy lately with the 1.0.0 release! https://medium.com/buildbot/buildbot-1-0-0-38c6208ac7d7 This is hard for me to estimate the repercussions as I lack good knowledge of the JS ecosystem. It does not look like a trivial task in any case :) I'll try to bring this up next tuesday to see when/if this can be considered. > In any case, I suggest mass-file RFPs/ITPs for all needed node packages. > Then package as many as you feel like. Maybe others will help, let's see. > I cannot promise any help, because I'm already busy with other tasks. > > I recommend to package all node libraries under the umbrella of the > Debian Javascript Maintainers > They have their git repo here: https://salsa.debian.org/js-team That's very nice to know. Thanks! I was afraid I might need to do all that myself :D For now, I am focusing in having only the server and worker packages (without any web ui) updated in debian with the latest upstream release. There is a small limitation in pybuild regarding building multiple binary packages from the same source package (each located in subdirectories). I talked with p1otr on #debian-python and he told me he may have a fix uploaded soon(tm). In the meantime, I am struggling to make the tests run and docs build with only debian dependencies. Once this is done, I will work on web ui packages. Hopefully, buildbot-www* packages will have gotten rid of some dependencies which would make debian integration easier. I'll surely shime in #debian-js to ask for guidance. Cheers, -- Robin
Bug#883529: ITA: buildbot,buildbot-slave -- Build automation system
Dear Robin, did the discussion about coffeescript vs ECMA6 already lead to something? In any case, I suggest mass-file RFPs/ITPs for all needed node packages. Then package as many as you feel like. Maybe others will help, let's see. I cannot promise any help, because I'm already busy with other tasks. I recommend to package all node libraries under the umbrella of the Debian Javascript Maintainers They have their git repo here: https://salsa.debian.org/js-team Thanks for caring! Cheers
Bug#883529: ITA: buildbot,buildbot-slave -- Build automation system
Hi, I had a look at the current state of the buildbot and buildbot-slave source packages. It looks like the choice was made to have one source package per binary package. https://tracker.debian.org/pkg/buildbot https://tracker.debian.org/pkg/buildbot-slave All buildbot related code is under source control in a single git repository. If I understand correctly the way Debian packaging works, there can be multiple bin packages produced from a single source package. This would make sense for buildbot. Even more now that there are multiple web ui plugins that can be installed separately. No need to maintain multiple packages would be simpler. There is one major problem: all www plugins require building coffeescript and jade templates into pure javascript. This requires nodejs and a ton of dependencies (managed by gulp). Simevo created a page on debian wiki to track these: https://wiki.debian.org/Javascript/Nodejs/Tasks/guanlecoja Also, there is an on-going discussion to replace coffeescript by native ECMA6 javascript and switching from gulp to webpack which would remove a lot of these dependencies. Unfortunately, this will take some time to land as this almost means rewriting the whole frontend plugins. In the meantime, I feel that we should drop the buildbot-slave source package and build both buildbot and buildbot-worker binary packages from the buildbot source package. The www plugins can be added later when building them is actually feasible with debian dependencies. Martin, Matthias, what do you think? I'd like your opinion before proceeding in any direction. -- Robin
Bug#883529: ITA: buildbot,buildbot-slave -- Build automation system
retitle 883529 ITA: buildbot,buildbot-slave -- Build automation system owner 883529 ! thanks Hi, I am willing to adopt both buildbot and buildbot-slave (which should maybe be renamed to buildbot-worker). Cheers, -- Robin