#docker-dev meetings are held twice a week in the #docker-dev irc group on Freenode. This irc channel is logged all the time, so you can always refer to it.
Held at 10:30am Thursday, San Francisco time.
Please remember that there are now 2 meetings, one in an Asia-Pacific timezone, and this one in the SF timezone.
build - shykes
shykes:
Pretty straightforward, I promised I would look into 'docker build -f' after my
vacation, so I'm going to do that. That, and the fact that we need help on that
general area. A dedicated maintainer, or two, would be great until then, things
are bound to be slow erikh did a really nice job with the parser refactor, but
he's busy on lots of other stuff.
here's what being a maintainer means:
"my subsystem has no bugs, no PR backlog, the code is clean and everyone loves it." --> proud
OR "my subsystem is a piece of shit dirty mess" -> ashamed
if you don't feel one of these 2 emotions very strongly about the subsystem within 1 hour of waking up - you're not really a maintainer (rule of thumb)
see also The Docker Maintainer manual
nested build - proppy
shykes: I like it. Except the hyphens. /builder makes more sense I think
But that means supporting nested image names. Shouldn't be too hard
shykes:
Anyway, maybe we can take this to the PR thread. Short answer is that design
makes sense, no major red flags, just some interface details to work out
proppy:
#proposalinfomercial if you "liked" nested build proposal, please check out:
gh#8240, less ONBUILD moar TRIGGER
project workflow - shykes
shykes:
In the last few months most of the core maintainers (pushed by me) have focused
a lot of their time working on cool new features And I've focused a lot of my
time designing those features with them
The result will be awesome, but A side-effect, in my opinion, is that the overall maintenance flow has fallen behind. So I'm going to focus on fixing that I'm not sure what the fix will entail yet. But it will be a combination of process improvements, and better tools And it will involve me asking for help from a bunch of you - either for ideas, feedback on ideas, or contributing to implementing them This is a pretty massive project, and we have an opportunity to improve the state of the art for distributed dev It'd be silly to not take advantage of that Ideally we get to a point where our flow is so awesome, other projects can use it to be more productive
Lots more discussion in the irc log, including mentions of README and diff driven proposals.
docker secret - vbatts
First up, a general discussion trying to work out what the good bits are, and wasn't liked, so it can be re-done to only include the good bits.
erikh pointed out a similar proposal:
- Proposal: Dockerfile QUESTION and ANSWER verbs which would need some non-interactive way to proceed.
API for supported parameters - vbatts
vbatts:
so this feature i feel like is need for the daemon to self-document, and to some extent introspect
not from container to daemon, but client to daemon
since it involves daemon api updates i wouldn't mind a bit of feedback
more discussion, and generally very positive response.