Open Stack

On 12/14/2016 09:56 AM, Doug Hellmann wrote:
> Excerpts from Dean Troyer's message of 2016-12-14 08:15:08 -0600:
>> On Wed, Dec 14, 2016 at 7:46 AM, Doug Hellmann <doug at doughellmann.com> wrote:
>>> FWIW, some of the deployment tool communities (ansible and puppet,
>>> I think) rely on git repos without external artifacts, and we're
>>> supporting them in our release tools today. I'm not sure how
>>> downstream packagers feel about the lack of external artifacts.
>>
>> I recall zigo working hard for the Debian packaging to come strictly
>> from Git repo tags but do not recall seeing opinions from other
>> packagers.
>>
>>> Were you thinking of files other than the tarball when you say
>>> "generated files"?
>>
>> Yes, in particular, files like AUTHORS and sample config files, which
>> IIRC are generated and included in tarballs.
> 
> OK, those should be easy enough to deal with if we publish tarballs
> of golang source. Perhaps someone from one of our other projects
> that uses git tags as releases can comment on how they handle those
> things?

In oaktree, which has golang bindings, and also because of gRPC/protobuf
has generated files -  I have followed what I could see of other folks
and ... checked the generated files into git, along with a gate job to
ensure that patches that change the source of those generated files are
always accompanied by changes to the generated files (and that the
generated file content is the same)

It makes me feel dirty - but with the gate check it doesn't bother me as
much as it would have in times past. Other people theoretically wanting
to consume those go bindings as a library need to be able to do so with
go get - and that means the files need to be there.

For things we generate in pbr - like AUTHORS and ChangeLog - assuming we
want to do the same thing in go, we could likely come up with something
similar. I also think we should consider that perhaps those two files
are not needed if the primary expectation for distribution is git.