Bug#883529: ITA: buildbot,buildbot-slave -- Build automation system

2018-02-15 Thread W. Martin Borgert

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-15 Thread Robin Jarry
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

2018-02-14 Thread W. Martin Borgert
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

2018-02-14 Thread Robin Jarry
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

2018-02-14 Thread W. Martin Borgert

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

2017-12-15 Thread Robin Jarry
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

2017-12-13 Thread Robin Jarry
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