[rb-general] Moving the source-date-epoch spec git repo

Daniel Kahn Gillmor dkg at fifthhorseman.net
Sat Feb 25 22:49:56 CET 2017


On Thu 2017-02-23 05:46:00 -0500, Ximin Luo wrote:
> The compelling reason is to reduce overhead, to avoid having to
> remember several git URLs and to clone several repos at once. We will
> very likely publish more documents in the future (about rebuilders,
> distributing buildinfo, unified buildinfo format, etc etc etc) so this
> saves more work now.

You're driving this, so it's your call; and i won't lose any sleep if
you do decide to do the merge.  But you're asking here for feedback, so…

The more documents we plan to publish, the more i think we should keep
them in separate git repos.  If there were only two documents ever, then
i'd actually be *more* ok with merging.  If i want to know about the
history of the unified buildinfo format, i don't necessarily want to
know the history of the source-date-epoch spec.  If i want to work on
one of them, i don't want to have to fetch all the others, and if i want
to follow edits, i'd like to not have to figure out how to ignore the
changes in parts i'm not interested in.  If a future spec that i'm not
working on introduces a large or churning test corpus, should i need to
fetch those updates just to stay on top of some other spec?

You say "to reduce overhead", but it's not clear to me what overhead is
involved, other than people needing to know to check out several git
repos, which i don't think is a big deal.  Are there specific pieces of
code or test suites that you expect to be duplicated across these specs
and documentation?  if so, perhaps that code would be more widely useful
than just for r-b, and could live as a separate package on its own?  Is
there other overhead that i'm not considering?

> I checked that no visible URLs point to the repo; they all point to
> the built documentation at r-b.org. So I don't need to change any
> existing URLs.

thanks, that's good to know.

> I was thinking of simply using the source-date-epoch repo's history
> and committing on top of that, but even if this were not the case,
> it's entirely possible to merge two git histories that started from
> different repos, with different root commits.

yes, if you're going to merge, please merge in the way that preserves
both histories, this should be fine.

I think i've expressed my opinion on this enough without doing any
useful work, i'll bow out of the rest of this thread.

Thanks for working on this, Ximin!

     --dkg
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 832 bytes
Desc: not available
URL: <http://lists.reproducible-builds.org/pipermail/rb-general/attachments/20170225/5ca4aa9d/attachment.sig>


More information about the rb-general mailing list