> On Oct 25, 2016, at 7:33 AM, Eric Friedrich (efriedri) <[email protected]> > wrote: > > Traffic Control has traditionally released binary RPMs for all components > including Traffic Server. For all of these components, the source has been > available in Github. > > With Traffic Control 1.7, what is the best way for me to obtain the source > used to re-create or audit the release artifacts? If we’re are going to > distribute a binary RPM, we’ll need to provide some way to obtain the source > for that. > > Options, in no order: > 1) Continue to periodically commit a diff into Git (I’m sure this is hard to > maintain, and places a burden on the release manager to track the diff down) > 2) Distribute a Source RPM for traffic server as one of the release > artifacts. This could work as the same build process that produces the > release builds could also produce the SRPM. I’m not sure how this would work > on non-Comcast build infrastructure though. > 3) Don’t distribute a binary traffic server RPM, although this will > complicate the “quick start” path we’ve been talking about. > 4) Document which ATS commits are required for which Traffic Control > features. How to express bug fixes as part of this because fixes may not > always fit cleanly into a single feature? >
My gut feeling would be that having one ASF project release binaries for another ASF project is slightly unusual. But, I don’t see a real problem with it, as long as you vote, sign and distribute the artifacts as per the ASF requirements. You shouldn't (can’t) announce this as an official ATS release though, I’m fairly certain only the ATS community can do an official ATS release in any form. Cheers, — leif > Any other suggestions? How do other Apache projects handle cross-project > dependencies like this? > > —Eric > > > > >
