Calling all Hydra users

Hello everyone,

Lately I’ve been sending quite a number of patches to Hydra with a focus on the future: tests, schema design, etc. We’ve also merged PRs to run the tests in parallel and format the documentation with Markdown.

I’ve run in to some problems when I want to merge or upstream some patches:

  1. Who can help me review this?
  2. Will this break somebody’s important use case?

The first point is fairly easy, I test it as well as I can and ping a Perl Monger friend if I can’t find anyone else.

The second point is much trickier. Today there is no avenue to ask Hydra users about possibly breaking changes. Its fairly organic growth makes it hard to even know what the features are sometimes! Now, Hydra has been long considered to be “unreleased” software, which is the epitome of “if it breaks you get to keep both pieces” but I’d like for my own work to be in collaboration with its users.

So, Hydra users, how should we talk to each other and collaborate? Is a Discourse Category the right way to go?

Separately, what if we had a team on Hydra of users that know Perl, and PR authors could ping the team to get some review?

Note, I’m not saying this is totally changing how Hydra is developed or supported. I don’t think every change would go through a rigorous process any time soon. I don’t think its status of being “unreleased” would change any time soon, either. I’m just trying to think about ways we could collaborate a bit better when possible.

Thanks,
Graham Christensen

13 Likes

By the way, here is the PR that made me start thinking about this, a PR which changes the JSON values in RunCommand to make bools bools: RunCommand: emit the `finished` field as a boolean by grahamc · Pull Request #880 · NixOS/hydra · GitHub – if this impacts you badly, I’d be glad to know!

I’d be interested to keep an eye on any hydra discussion here on discourse. I may not be much of an active participant except in occasional bursts when I can find some bandwidth to work on it or already know that something will or will not affect our hydra usage or use-case one way or another.

2 Likes

How many of us are there, even? :slight_smile:

I know there’s some reluctance in the NixOS organization to create even more dependencies on GitHub, but I think I’d be more likely to participate in GitHub Discussions on the GitHub Hydra project page than here on Discourse. I rarely check in here.

1 Like

I just got a discourse email about this thread, so you may hear more now.

We run a hydra server, and the following two patches I’ve submitted back for issues we have run into have stalled

https://github.com/NixOS/hydra/pull/677
https://github.com/NixOS/hydra/pull/701

Are there some sub-maintainers I should have been CCing?

Thanks! -Tyson

1 Like

Yeah, I don’t think that is super likely to be honest. Maybe there is a way you could get a summary of activity from a Discourse section? I went ahead and made a Hydra subcategory of Development: Hydra - NixOS Discourse

Nice, thanks! I took a look at the javascript library update. There is a tricky issue there around deep linking, but otherwise I think it looks okay. If we can solve that issue I’d say we merge.

I’m a bit less confident reviewing the second patch, but I’ll give it a read. Thanks for sharing them!

1 Like

To make it official, I’m happy to help out as well.

I don’t think its status of being “unreleased” would change any time soon, either.

May I ask what’s the reason for this or is it mainly time constraints? I actually think that this could help decreasing the risk of breakage for Hydra users. However I’m only talking as user & code contributor here and not as developer, so I may be missing something here.


@grahamc Btw, may I ask if there’s anything I can do to help getting Add a filter for maintainers in the jobset-eval view by Ma27 · Pull Request #743 · NixOS/hydra · GitHub ready? I’m happy to resolve the merge-conflicts, though I’d prefer to do this “on-demand” (i.e. when you have time for a review). Merge-conflicts seem to happen kinda regularly here and aren’t trivial to resolve, so I don’t think it’s a good idea to do this proactively in this case :slight_smile: