This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2016-01-13
Channels
- # admin-announcements (6)
- # beginners (51)
- # boot (164)
- # braid-chat (49)
- # cider (10)
- # clara (17)
- # cljs-dev (13)
- # cljsjs (51)
- # cljsrn (10)
- # clojars (42)
- # clojure (195)
- # clojure-bangladesh (102)
- # clojure-berlin (8)
- # clojure-canada (1)
- # clojure-chicago (19)
- # clojure-colombia (4)
- # clojure-denmark (6)
- # clojure-russia (15)
- # clojure-ukraine (7)
- # clojurescript (257)
- # code-reviews (10)
- # community-development (292)
- # core-async (13)
- # datomic (26)
- # dirac (4)
- # dunaj (5)
- # dysphemism (5)
- # events (21)
- # funcool (15)
- # hoplon (115)
- # instaparse (31)
- # ldnclj (15)
- # mori-fork (43)
- # mount (5)
- # off-topic (18)
- # om (195)
- # onyx (13)
- # proton (9)
- # re-frame (11)
- # reagent (44)
- # slack-help (14)
- # slackpocalypse (1)
- # spacemacs (10)
- # yada (23)
@meow: howdy! What we need most atm is PRs for issues. we've been given plenty of money, but don't have time to fix everything that needs fixing
we have a list of issues "ready for work" at https://github.com/clojars/clojars-web/labels/ready
there are probably a few more that have come in recently that should be tagged with :ready as well
@meow: i want to work on a tool that can detect and fix broken maven metadata xml files
so what do we need - some kind of parse of xml that can handle misformed xml or something
like when you push a release to the repo there are multiple artifacts that need to be uploaded
there is a metadata file that describes all the versions, which can get out of sync with the actual files in the repo
so currently you can download jars from repos that don't have those versions listed in the metadata.xml file
the idea for atomic deploys, as i understand it, is to use the metadata.xml file to commit a transaction
so the release won't be live until all artifacts have been uploaded and verified according to metadata.xml
clarify for me: isn't a metadata file referencing versions that are out of sync a problem independent of atomic commits?
@meow: correct - bad metadata is its own problem, but needs to be fixed before atomic deploys can be implemented
@jonahbenton: any suggestions?
sounds like @micha has the right of it. for problems like this i like approaches like https://github.com/clojars/clojars-web/issues/226#issuecomment-142270596. having the same tool be able to handle an atomic move from a dmz-like upload area to the canonical coordinates, as well as be able to validate/clean/fix artifacts within the canonical tree, probably makes sense. the plan is to continue to keep the repo on a file system?
@jonahbenton: the plan is to move the repo off to a cloud file store in the near future
@tcrawley: cool. so a tool that verified a group of file system resources for correctness and also delivered an atomic move of said resources to cloud could be utilized to populate the cloud file store with verified artifacts from the current repo, and also handle new artifact uploads going forward?
@jonahbenton: everything in the current repo will end up in the cloud store, correct or not, though we will run a tool across the repo to fix what we can before hand