+1 the minimal apache cherrypick release makes sense to me. On Fri, Jul 8, 2016 at 1:14 PM, Chris Riccomini <criccom...@apache.org> wrote:
> Hey Bolke, > > A fast release with the 1.7.1.3 + cherry picks listed above sounds like the > way to go. Then, a second release in sept where we just cut from master. > > I'm +1 on this. Lets us get our Apache ducks in a row without worrying > about stabilizing everything simultaneously. > > Cheers, > Chris > > On Fri, Jul 8, 2016 at 12:32 AM, Bolke de Bruin <bdbr...@gmail.com> wrote: > > > This was my assessment as well, thus I agree. My suggestion is to start > > the process and see if we get questions about this that require us the > > change our point of view. > > > > If we do an earlier release I would like to aim for July 19, but that > > might be a bit short notice. If needed I can put myself up as release > > manager till the 21st. If we do 1.7.1.3 + cherry picks I would say > > > > * Licenses > > * Notices > > * Disclaimer > > * Highcharts -> d3 > > > > Makes sense? Anything missing here? > > > > - Bolke > > > > > Op 7 jul. 2016, om 18:04 heeft Chris Riccomini <criccom...@apache.org> > > het volgende geschreven: > > > > > >> but it's acceptable to have a soft dependency on an LGPL component, > such > > > that a user could deploy the LGPL component separately to enable > > additional > > > optional features > > > > > > This is precisely what I believe is going on with Airflow. It's under > an > > > airflow[postgres] package (so `pip install airflow` doesn't even > install > > > it). We went through a very similar exercise with Samza, where we had a > > > dependency on Paramiko (also LGPL [1]), and our (LinkedIn) lawyers > talked > > > to Apache, and agreed that it was fine. > > > > > > [1] https://github.com/paramiko/paramiko/blob/master/LICENSE > > > > > > On Wed, Jul 6, 2016 at 10:16 PM, Chris Nauroth < > cnaur...@hortonworks.com > > > > > > wrote: > > > > > >> Here are more details on Apache release requirements: > > >> > > >> http://www.apache.org/dev/release-publishing.html > > >> > > >> > > >> http://www.apache.org/dev/release > > >> > > >> > > >> To summarize, it's much more focused on compliance with licensing, > > signing > > >> and Apache infrastructure requirements. That's the kind of scrutiny > > that > > >> a release candidate will get from the Incubator PMC rather than deep > > >> testing for verification of new features or bug fixes. > > >> > > >> For that reason, I think it makes sense for a podling's first Apache > > >> release to focus on nothing but those ASF policy requirements. It's > > >> completely normal for a podling's early release candidates to have a > few > > >> false starts that get voted down, because the policies are complex the > > >> first time around. Some projects have found it helpful to write a > "How > > to > > >> Release" web page during the first release, so that they have > > step-by-step > > >> notes to follow during subsequent releases. Focusing on "latest > stable" > > >> with a few additional patches sounds like a great plan to me, because > it > > >> decouples the challenges of your first ASF release from other software > > >> development pressures, such as pressure from a user base to ship a new > > >> feature quickly. > > >> > > >> Regarding the LGPL question, in general, the answer is that we are > > >> prohibited from redistributing any LGPL component, but it's acceptable > > to > > >> have a soft dependency on an LGPL component, such that a user could > > deploy > > >> the LGPL component separately to enable additional optional features. > > >> More details are here: > > >> > > >> http://www.apache.org/legal/resolved.html#prohibited > > >> > > >> > > >> A specific example of this is Apache Hadoop's integration with LZO > > >> compression, which uses a GPL license. Hadoop does not redistribute > LZO > > >> or include any code that is tightly coupled to it, but the Hadoop > > codebase > > >> does have a notion of a pluggable CompressionCodec, with > implementations > > >> of the interface discoverable at runtime. This setup supports users > > >> downloading and installing a separate LZO integration library onto > > >> Hadoop's classpath. > > >> > > >> --Chris Nauroth > > >> > > >> > > >> > > >> > > >> On 7/6/16, 9:36 PM, "Maxime Beauchemin" <maximebeauche...@gmail.com> > > >> wrote: > > >> > > >>> Hi, > > >>> > > >>> This sounds very reasonable to me, though we may be able to do an > > earlier > > >>> release as a practice run for an Apache release with a snapshot of > our > > >>> production which would consists of the latest release plus a set of > > cherry > > >>> picked PRs. > > >>> > > >>> How does an Apache release differ from a standard release again? > > >>> > > >>> Max > > >>> > > >>> On Wed, Jul 6, 2016 at 7:59 PM, Chris Riccomini < > criccom...@apache.org > > > > > >>> wrote: > > >>> > > >>>> One other thing to note is that I'm planning to run the RCs in all > of > > >>>> our > > >>>> environments to exercise things. We should make sure that we're all > > >>>> committed (as well as the community) to burning the RCs in on our > > >>>> respective environments for a few weeks. > > >>>> > > >>>> On Wed, Jul 6, 2016 at 7:58 PM, Chris Riccomini < > > criccom...@apache.org> > > >>>> wrote: > > >>>> > > >>>>> Hey Bolke, > > >>>>> > > >>>>>> should we aim for a release 1st week of September > > >>>>> > > >>>>> Sounds good to me! > > >>>>> > > >>>>>> I would want to aim earlier, but due to holidays I guess it might > be > > >>>>> smarter to schedule it a bit after? > > >>>>> > > >>>>> So would I, personally. I'd be OK with starting RCs now, to be > frank. > > >>>> What > > >>>>> do others think? > > >>>>> > > >>>>>> Should we vote on the above? > > >>>>> > > >>>>> No need, IMO. A discuss like this is enough, assuming there are no > > >>>>> objections. > > >>>>> > > >>>>> Re: psycopg2, I don't think it's an issue, but we should probably > > >>>> file a > > >>>>> LEGAL [1] just to be sure. In any case, we don't have to be > compliant > > >>>> for a > > >>>>> release in incubator, I believe. We just need to be moving in that > > >>>>> direction. > > >>>>> > > >>>>> Cheers, > > >>>>> Chris > > >>>>> > > >>>>> [1] https://issues.apache.org/jira/browse/LEGAL > > >>>>> > > >>>>> On Wed, Jul 6, 2016 at 1:24 PM, Bolke de Bruin <bdbr...@gmail.com> > > >>>> wrote: > > >>>>> > > >>>>>> Hi, > > >>>>>> > > >>>>>> As I don¹t think there are any show stoppers to have an Apache > > >>>> release > > >>>>>> should we aim for a release 1st week of September? I would want to > > >>>> aim > > >>>>>> earlier, but due to holidays I guess it might be smarter to > schedule > > >>>> it > > >>>> a > > >>>>>> bit after? > > >>>>>> > > >>>>>> - RC last week of August giving about two weeks to have it run in > > >>>>>> production in our environments > > >>>>>> - Guess voting needs to happen at the IPMC > > >>>>>> - Release (Champagne!) > > >>>>>> > > >>>>>> Earlier there was some discussion about psycopg2 / postgres > > >>>>>> interoperability (psycopg2 being LGPL). Personally I don¹t think > > >>>> there > > >>>> is > > >>>>>> an issue as we are not redistributing psycopg2 ourselves and we > are > > >>>> not > > >>>>>> dependent on it to function. An company can choose thus what they > > >>>> want > > >>>>>> without being `tainted` by the LGPL. Any remarks on this? > > >>>>>> > > >>>>>> Should we vote on the above? > > >>>>>> > > >>>>>> - Bolke > > >>>>>> > > >>>>>> > > >>>>>> > > >>>>>> > > >>>>> > > >>>> > > >> > > >> > > > > >
