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

Daniel Shahaf danielsh at apache.org
Sun Feb 26 13:28:13 CET 2017

Daniel Kahn Gillmor wrote on Sat, Feb 25, 2017 at 16:49:56 -0500:
> 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?

Thinking out loud: how about creating a standards.git repository that
includes both the source-date-epoch and build-path-prefix-map as git
submodules?  Then we would have our cake and eat it too, wouldn't we?

> 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?

More information about the rb-general mailing list