Closed RichardLitt closed 8 years ago
Added note about the Weekly for this week, which can be found here: https://github.com/ipfs/weekly/pull/21. Add stuff as it happens!
NEXT
go get
https://github.com/issues?utf8=%E2%9C%93&q=is%3Aopen+org%3Aipfs+label%3A%22needs+review%22
[0/6]
index.js
files into multiple parts [0/3]
[/]
[0/2]
[0/2]
[0/2]
files
: https://github.com/ipfs/http-api-spec/issues/57fs:/
handler to it. - available at fs:/ipns/glowing-bear.ipfs.ovh/You have 30 minutes for this agenda, 5 minutes before the meeting ends, consider moving the remaining items to a github discussion thread so that all the other sprint meetings can start in time.
Actionables:
ipfs commands
)go get
index.js
files into multiple partsfs:/
handler to it. - available at fs:/ipns/glowing-bear.ipfs.ovh/This week I focused on getting the API out of the door, although I also did a fair amount of other things. I updated a lot of the go-ipfs mans in the process of finishing up the API, but there is still a lot of work to do there, and the work is very difficult due to constant context switching. Hoping to keep banging away at this this week.
Radically transparent thought process ahead: My work suffered this week because I was straight out avoiding the weekly. I am not good at tackling it. Encouragement on the whole thing would be appreciated: right now I feel like it is something everyone needs, but no one wants to help make, and the need for it to be all-inclusive in content and high quality makes me want to do little doc PRs where I feel safe to keep me from engaging with the high mental cost of trying to sort out what is actually interesting for the IPFS project at a whole, something that I am still not sure about all of the time. I'm guessing the same is true for a lot of the other projects here - the cost for being a team comprised of masters is that we are all responsible for our domains: I'll try and encourage other people, too, and I'll struggle to be more responsible here. One thing I can do better is to always build it during the sync and not wait until after. That's what I'll try to do, today.
files
: https://github.com/ipfs/http-api-spec/issues/57 :star: This week didn't quite go as planned either. Looked after stability problems with docker and the go-ipfs containers which made me decide to switch to runc+runit as a runtime, which is work-in-progress. Also threw a bit of hardware at the problem (resized our vhosts).
Fixed several go-ipfs test failures, and revisions on other outstanding PRs. I can now manually set up a Go package for ipfs.io retrieval via 'go get' -- now we just need to make the changes to gx-go to do it for us and rewrite urls to use ipfs.io. Some clean-up on ipfs-hyperlog to integrate my work back into the parent hyperlog project rather than being a crude fork.
js-ipfs
js-ipfs-api
ipfs-geoip
libp2p
npm on ipfs
station
ipscend
js-ipfsd-ctl - Features that I needed for ipscend
specs
Thanks, all. Please add your starred updates to the weekly: https://github.com/ipfs/weekly/pull/21.
The next sprint is: https://github.com/ipfs/pm/issues/93.
Sprint February 16
Note that this sprint has been moved from the normal Monday February 15th sprint.
The IPFS Weekly for this week is here. Please add anything cool which happens over the course of this week to it.
Sprint Goals
Sprint Discussions
Schedule
Please take notes in a separate pad, if you can, and link it here.
Wednesday
Please add the Agenda to the Pad before the endeavour sprint starts.
Sprint Deliverables