User Details
- User Since
- Sep 7 2015, 3:25 PM (333 w, 3 d)
- Roles
- Administrator
Yesterday
Now that I've written it out loud, of course, Releases don't have extra_headers so the package loaders can't make use of this workaround/hack for now.
From merged tasks, this would also be useful for some package loaders, e.g. npm, that support multiple authors in their packaging metadata.
Practically, we could be storing the metadata on additional authors *now* in the extra_headers field (make them a bunch of (b'author', b'XXX <yyy@zzz.ttt>') entries). Of course, that doesn't solve the question of presenting the information.
Is this information fully intrinsic, or can it be modified without the revision id changing ?
Wed, Jan 26
Tue, Jan 25
I wonder if that'd be worth a warning. May end up being a bit noisy though.
Thanks! (and sorry for the hash algo ping-pong)
I'm not 100% convinced we need to recheck the objects at every addition (within a transaction that can still fail to commit) instead of afterwards, but it doesn't /hurt/ either. We'll make a full pass on all objects again later anyway.
Mon, Jan 24
Oof. I guess that's one more reason to be wary of TODOs in tests.
Fri, Jan 21
Neat, thanks.
thanks!
Thanks!
Thanks!
Thanks!
On most forges, 403 errors are used in place of 404 errors (so you're not able to do discovery of private repositories by checking the return code). I think treating them as not found is correct.
Either way, I think this is good to go, thanks!
We still query the fields out of the Postgres database (to ignore them in the db -> model object conversion), right? Should we stop doing that too?
Sounds good to me, thanks!
Thu, Jan 20
Awesome, thanks!
The buffer bits look reasonable to me. I'm not so sure about the validator bits, as we're not actually storing the id fields for these objects, afaik?
Update tfstate after provisioning the machine
Could we create this script, for each kafka cluster, on the kafka management host rather than on individual brokers, so we can have all the management in a single place?
Any chance you could add a couple of tests for this?
Wed, Jan 19
softwareheritage=# alter table revision add constraint revision_date_offset_not_null check (date is null or date_offset_bytes is not null) not valid, add constraint revision_committer_date_offset_not_null check (committer_date is null or committer_date_offset_bytes is not null) not valid; ALTER TABLE
Gotta love rebasing
Add hints on how to deploy the storage db externally
*shrug*
Tue, Jan 18
The code for the gauges feels like something that would be usefully handled with a context manager.
I'm kinda wondering if this import stuff should move to a common module - I think we do kind of the same thing with entrypoints?
All revisions (supposedly) have been migrated to bytes offsets. I'll wait for the ongoing base backup and vacuum to complete before adding the constraints on the production database.
Great, thanks!
Sounds good. I don't think we need to make them unique though (and it might make stuff confusing if writes get rejected by this index rather than the primary one)
Mon, Jan 17
Thanks!
This all looks fine to me, thanks!
Fri, Jan 14
Awesome, thanks.
Great, thanks!