Torsten, > On 26 Oct 2017, at 19:12, Torsten Bergmann <asta...@gmx.de> wrote: > > Hi Sven, > > for Zinc there is a new issue: > > > 1. Zinc is using #asBytesDescription. It should not be used as it is > deprecated > > https://github.com/pharo-project/pharo/pull/401
This change was applied upstream: === Name: Zinc-HTTP-SvenVanCaekenberghe.470 Author: SvenVanCaekenberghe Time: 28 October 2017, 11:10:06.068769 am UUID: 1d831c82-f918-0d00-9306-5dc70a8677c5 Ancestors: Zinc-HTTP-SvenVanCaekenberghe.469 Follow an API change in Pharo: use #humanReadableSIByteSize instead of #asByteDescription in ZnUtils>>#signalProgress:total: === > there is also > > 2. https://pharo.fogbugz.com/f/cases/20557 which is not yet integrated. This is waiting for an integrator, I believe people are working on it. > I also proposed some simple but necessary cleanups for Zodiac in Pharo 7: > > 3. Proper categorization in Zodiac-Tests package > - to use "test" category instead of "testing" and better group the > tests written > > https://github.com/pharo-project/pharo/pull/355/files > > Also it looks like the #setUp in Zodiac tests never send a "super setUp". > Which > should be fixed too. Hmm, these are more cosmetic changes, I will have a look at them later on. > I've noticed that both Zinc/Zodiac are not hosted on STHub. You seem to use > your own custom > hosting server on > > http://mc.stfx.eu/Zodiac > http://mc.stfx.eu/ZincHTTPComponents I would not call that a custom hosting solution, it is just Monticello. Note that there are also a copies on StHub. > as well as github: > > https://github.com/svenvc/zinc > https://github.com/svenvc/zodiac > > If we just merge the changes from 3. into Pharo 7 they may later be > overwritten when > synching also Zodiac again as in 2. Yes, that is true. I have to follow upstream. The GitHub versions also lag a bit sometimes. > So how can we contribute from community side to both projects? Should I fork > https://github.com/svenvc/zodiac and send a PR to it so that you can > integrate? Zinc/Zodiac are integral parts of Pharo that are managed externally. The goal is to simultaneously support many Pharo versions, not just the latest. Most production deploys of Pharo use version 4, 5 or 6, but they still need good HTTP(S) support. That is what I am trying to do. The older MC repositories are public, so others can contribute in the proven MC way. I have nothing against git, but I have not yet fully switched, nor do I think that I can if I want to support older Pharo versions. Sven > Thanks > Torsten
