After a PR of mine lands, I always manually press the "Delete branch" button,
so that "git branch -al" does not pile up cruft and remains an useful tool. I
guess/hope that most other people do the same?
GitHub recently added a simple config option to automate that:
Does anyone object if I enable that for our cockpit projects?
I am working on a cockpit plugin. Among some features, I would like to be able to upload some heavy binary files (# 500MB) to remote machines through cockpit web page.
Do you have some advices on how to do this ?
I am not sure the cockpit.file API is suitable for this.
Good job with this software.
I have a React-Cockpit question. I kind of stuck with no good idea of
how to implement one thing...
The scenario I want to execute:
1. User clicks a button 'Run Full Report';
2. It creates a promise and checks through '.stream()' if the execution
requires user input;
3. If it requires - Show the input modal and wait for the user press
4. When the user enters the data (which I store in state) and confirms -
continue the execution in the existing '.stream()';
5. Repeat as many times as it requires (and it is dynamic because it
depends on the actual network state)
I have a few options but I am not sure which exactly React-Cockpit tools
I can use for that...
- Can I wait inside of cockpit.stream('here') for some state change? I
can wait for the React componentDidUpdate() but I am not sure how I
can connect this with exacting cockpit.stream('here') code.
- I have an ugly option with spawning a lot of promises to fetch user
data and then using it in the final report execution... But it looks
so ugly that I'd rather search for a 'smart' way...
If you can somehow direct me to a solution, it'll be most
appreciated. I've tried to search for the solution from different
angles but apparently I miss some React-Cockpit capabilities.
as discussed in this week's meeting, it's time again  to garden our issue
tracker and clean up obsolete issues. We want to find the important and easy
issues that just fell through the cracks, clean up the noise that makes the
issue tracker less useful, and generally get an up to date impression about
what users have trouble with.
I  tagged all issues which haven't been updated in the last 90 days with the
Let's please collectively go through them, and re-triage them:
* For bug reports, make sure that they still apply to current master. If they
do, just drop the review label. If they are fixed, close the issue. If they
need more information how to reproduce, please ask the reporter for clearer
instructions, or whatever else is necessary, label the issue with "question"
and also drop the review label.
* For enhancement reports, also check if they still make sense for Cockpit.
Some of them have been open for years, and we realistically won't get to
them. Some of them may also be too big to be tracked in an issue, and they
need an entire epic about them (and then they need to be reviewed whether we
want to do it at all -- so most likely "no" for most of them).
* At least in the last review round we also had a lot of feature requests for
entirely new pages. Almost all of them should become their own project.
Point to starter-kit and our documentation, and that we are glad to help
anyone with setting up a project, CI, etc., but we can't do all that work
ourselves -- we don't want to become experts and take responsibility for
If everyone can triage 5-10 every day, we should be through in about two weeks.
Of course in the beginning we'll look at the "easy" ones and be faster, and the
pace will go down towards the end -- but then we'll already have a much better
 Similar to what we did in January:
 Well, our bots' issues-review script, of course
I am currently translating Cockpit UI into Russian and the last thing
that's left is virtual machine states (strings can be found in
'shut off': _("shut off"),
pmsuspended: _("suspended (PM)")
Can you please explain these to me or provide a link where I can read
about them? I can't find any reliable resources which would contain
*all* of the above so I can't be sure I get them right.
Dmitry Astankov (BaseALT Translation Team)
Jonathan Aquilina [2019-10-06 5:39 +0000]:
> I have a question. I understand that cockpit is still in its infancy
Software is never "done", but I daresay Cockpit is a rather mature project by
now. It has shipped in all major distros
(https://cockpit-project.org/running.html) for quite a while :-)
> but are there plans to add more apps that can be managed through cockpit?
Indeed the "cockpit ecosystem" in the sense of "other people writing
extensions" can be called infancy stage. There's UIs for composer, podman,
session-recording, Leapp, RHEL's subscription-manager, and OSTree, and some
PoCs for installing Fleet Commander and FreeIPA server through Cockpit's
Applications page (i. e. they are/were in Fedora for a while, but not e. g. in
RHEL or other distros).
The cockpit team itself doesn't currently have plans to write more, but that's
also not our primary goal. We don't want to become experts in everything, but
want to provide the tools and help for *other* teams to provide cockpit UIs for
their technology. For that we offer the Starter Kit
(https://github.com/cockpit-project/starter-kit), documentation like
https://cockpit-project.org/external/wiki/Contributing.html and the blog posts
linked from there, and are happy to get in personal touch to help teams with
coding struggles, CI setup, etc.
> Also what is the best way to start contributing to the project?
There's no general answer to that, as it really depends on who wants to get
involved and why. Usually in FOSS, someone has an "itch", a bug they want to
fix, or a feature they want, or some Cockpit UI they want/need in their
environment. For these cases, reporting a GitHub issue (bug/feature in the
cockpit project itself), or tinkering with the starter-kit and forking it to
your own UI (see above) is a great way to start.
don't have a specific itch to scratch, we have plenty of things to do that are
suitable for beginners, i. e. which don't require a comprehensive and deep
understanding of the whole cockpit project:
In either case, you are always welcome to discuss particular ideas or questions
on IRC in #cockpit, or here on the mailing list, or in GitHub.
I have a question. I understand that cockpit is still in its infancy, but are there plans to add more apps that can be managed through cockpit? Also what is the best way to start contributing to the project?