[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