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

[Ximin Luo]

Daniel Kahn Gillmor:
> 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…
> 

Thanks for the feedback everyone, I think I'll leave it for the time being. I might come back and revisit this idea later though, once we have more documents.

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

The original picture I had in my head was something like the Tor spec repository [1] where they keep all the documents in one repo. However, after trying out the merge in practice, your arguments here, plus thinking about it a bit more, I realise the situations are different.

- Tor does a lot of spec-related work and discussion on their mailing lists and it's more fast-paced. Less discussion is done "in the git repo" via side branches.
- It's smaller in scope, whereas we'll have things like pu/* branches for various different suggestions to deal with a wider variety of software subjects (I expect).
- It's easier to tag specific versions if the documents are separated. source-date-epoch.git already has a 1.0 version tag, I'd have to rename this and the pu/* branches too.

[1] https://gitweb.torproject.org/torspec.git

> 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?
> 
> [..]

There might be more overhead in the future, so I'll revisit this if that happens.

At the moment it's just the docbook-related buildscripts, which aren't big but could get bigger if people want to do more complex things. (XSLT is very very annoying to deal with.)

At the moment the prefix-map test cases are adhoc shell scripts but we might want to do a "proper" testing system in the future. We would probably use an existing test runner, but have shared build scripts across different spec documents, so "a separate package" probably wouldn't be appropriate since these scripts would still be something specific to the R-B project.

But I'll leave this for the future.

X

-- 
GPG: ed25519/56034877E1F87C35
GPG: rsa4096/1318EFAC5FBBDBCE
https://github.com/infinity0/pubkeys.git