Mailing-List: contact dev-help@asterixdb.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@asterixdb.apache.org
MIME-Version: 1.0
References: <CALjEsF7XkvWsGG-OMA6DFgT0NBoOo_LsuwidL8gP1y2AGZ2Xpw@mail.gmail.com>
 <D583D87F-DCA3-4FD8-9774-5997CBCA7064@gmail.com> <CABytAGo-fdov0e6s1H_X=_qQebb14cqLFzZ4Mxzz+z+DHDZhFg@mail.gmail.com>
 <CAN_YF5xO53jm4AkztcG9+hk06ewB1p9B5zcezTkv0KocQg7bww@mail.gmail.com>
 <CALjEsF6jNpbN2jZuG7ApjBTHsEqh1maA5mstrAhsbc7EmJTOsw@mail.gmail.com>
 <CAHWyyRxaCKiVsRj-JcJes4muN8VxyENBpZ7Bwzao3BJ8ojGODw@mail.gmail.com>
 <fc77e908-6883-c4f7-84f6-e5a12b6dd0c9@gmail.com> <EEAF44F2-9E0E-4727-AB06-061EFF69152E@apache.org>
 <CALjEsF788W-2N5o4OXBJSMCvsLbxRTYZZZrKL7Ta+BZaJPMpEg@mail.gmail.com>
 <D2E27A2E-5CE6-43FC-A898-08A32862EEE9@gmail.com> <6B9B4359-E132-466F-B8D8-FC05EC59867D@gmail.com>
 <CAE1xAnvbvSFJ6E2017gU-sJYorxGNYtxe0URyk0Lk-rtJe3Z+A@mail.gmail.com>
 <12B311F4-7B74-4EAD-96E8-4FB32F31C4D2@apache.org> <e35982ff-b921-6b92-a8e4-9984adf1feb1@gmail.com>
In-Reply-To: <e35982ff-b921-6b92-a8e4-9984adf1feb1@gmail.com>
From: Michael Blow <mblow.apache@gmail.com>
Date: Thu, 01 Jun 2017 15:24:18 +0000
Message-ID: <CAFUTFeZwtKHwQaS_tZJpky-SeYB3G=CEEQpvWEOw=TYor1O9SQ@mail.gmail.com>
Subject: Re: Modules that could be removed?
To: dev@asterixdb.apache.org
Content-Type: multipart/alternative; boundary="94eb2c1b5926003ecb0550e7a2e6"
archived-at: Thu, 01 Jun 2017 15:24:42 -0000

--94eb2c1b5926003ecb0550e7a2e6
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

+1 on understanding the BAD issues.  CB folks are regularly making
coordinated changes across two, three+ repos, and things work pretty well.
We do have a way less painful way of linking changes instead of ref spec,
but other than that things are probably not too dissimilar mechanics-wise.

Our biggest issue is that unlike BAD breakages, there's not easy visibility
by way of the -1 vote on Gerrit for the CB extension.  If experiments does
move out (and gets an indicator on Gerrit), perhaps CB extension can
provide feedback there as well.

On Thu, Jun 1, 2017 at 10:53 AM Mike Carey <dtabass@gmail.com> wrote:

> Likewise - I thought so too - so we should figure out what isn't working
> with the extensions model!
>
> (We do need a good model for things that don't belong in the main open
> source system but that we want to run tests on regularly so that we're
> hyper-aware of breakages.)
>
> Note that I've always anecdotally gotten the impression that the
> experiments package is kind of a mess/hack and makes use of things that
> aren't necessarily intended to be used.  I would much much, much rather
> that performance-related packages live outside the system and be banned
> from doing things that normal clients cannot do...  I think this would
> be a lot better for the integrity of the system (as otherwise it creates
> weird dependencies, non-guaranteed assumptions/contracts, and also keeps
> us from having a good/safe answer to outside cries for ways to replicate
> our reported performance results).
>
> Just my $0.005.
>
> Cheers,
>
> Mike
>
>
> On 5/31/17 10:39 PM, Till Westmann wrote:
> > Hmm, I thought that the BAD model wasn=E2=80=99t working too badly =E2=
=80=A6 little do I
> > know.
> >
> > On the other hand it seems that the module isn=E2=80=99t actually used =
- at
> > least it
> > seems that there were no changes in the module related to experiments
> > since
> > we merged repositories. Is that right? Or has somebody worked on that
> > module
> > recently?
> >
> > Cheers,
> > Till
> >
> > On 31 May 2017, at 22:20, Steven Jacobs wrote:
> >
> >> My two cents on this is that the BAD model doesn't work well, so I'd
> >> personally be against following it. I would vote to keep it inside as
> >> well.
> >> Steven
> >>
> >> On Wed, May 31, 2017 at 10:02 PM abdullah alamoudi <bamousaa@gmail.com=
>
> >> wrote:
> >>
> >>> If that is the case (which makes sense), then keeping it inside and
> >>> cleaning it up might be the better approach.
> >>>
> >>>
> >>>> On May 31, 2017, at 8:45 PM, Ildar Absalyamov <
> >>> ildar.absalyamov@gmail.com> wrote:
> >>>>
> >>>> The real challenge is that separate repo should not the treated as
> >>> /dev/null for old code.
> >>>> I believe that committing changes, that causes this repo to be broke=
n
> >>> *must* be treated as -1 Jenkins bit.
> >>>>
> >>>>> On May 31, 2017, at 16:41, Yingyi Bu <buyingyi@gmail.com> wrote:
> >>>>>
> >>>>> +1.
> >>>>>
> >>>>> Best=EF=BC=8C
> >>>>> Yingyi
> >>>>>
> >>>>> On Wed, May 31, 2017 at 4:22 PM, Till Westmann <tillw@apache.org>
> >>> wrote:
> >>>>>
> >>>>>> I read this discussion that Ildar=E2=80=99s suggestion to move
> >>> asterix-experiments
> >>>>>> to a different repo would be a solution that works for everybody.
> >>>>>>
> >>>>>> Did I read that correctly or did someone disagree with such an
> >>> approach?
> >>>>>>
> >>>>>> Cheers,
> >>>>>> Till
> >>>>>>
> >>>>>>
> >>>>>> On 31 May 2017, at 16:14, Mike Carey wrote:
> >>>>>>
> >>>>>> This should be decided by more knowlegeable folks than me - it jus=
t
> >>> seems
> >>>>>>> "weird" to me that that's in the main code base and not outside
> >>>>>>> (as a
> >>> super
> >>>>>>> useful client package).
> >>>>>>>
> >>>>>>>
> >>>>>>> On 5/31/17 4:12 PM, Chris Hillery wrote:
> >>>>>>>
> >>>>>>>> If we move asterix-experiments out, we would need to change the
> >>> current
> >>>>>>>> Perf job at Couchbase. However I think the change would
> >>>>>>>> actually make
> >>>>>>>> that
> >>>>>>>> job less complicated, at least if that allowed one to use a
> >>> pre-compiled
> >>>>>>>> Asterix distribution for experiments rather than requiring the
> >>>>>>>> full
> >>>>>>>> source
> >>>>>>>> code to be available.
> >>>>>>>>
> >>>>>>>> Ceej
> >>>>>>>> aka Chris Hillery
> >>>>>>>>
> >>>>>>>> On Wed, May 31, 2017 at 2:53 PM, Yingyi Bu <buyingyi@gmail.com>
> >>> wrote:
> >>>>>>>>
> >>>>>>>> The code in asterix-experiments is not well organized, e.g.:
> >>>>>>>>>
> >>>>>>>>> https://github.com/apache/asterixdb/tree/master/asterixdb/
> >>>>>>>>>
> >>> asterix-experiments/src/main/java/org/apache/asterix/experiment/build=
er
> >>>>>>>>> https://github.com/apache/asterixdb/tree/master/asterixdb/
> >>>>>>>>>
> >>> asterix-experiments/src/main/java/org/apache/asterix/experiment/repor=
t
> >>>>>>>>>
> >>>>>>>>> Can anyone who actively uses asterix-experiments clean up the
> >>>>>>>>> code?
> >>>>>>>>>
> >>>>>>>>> An alternative approach would be to put it in a separate github
> >>> repo,
> >>>>>>>>> if
> >>>>>>>>> it is relatively independent of AsterixDB.
> >>>>>>>>>
> >>>>>>>>> Best,
> >>>>>>>>> Yingyi
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> On Wed, May 31, 2017 at 12:31 PM, Ian Maxon <imaxon@uci.edu>
> >>>>>>>>> wrote:
> >>>>>>>>>
> >>>>>>>>> I also would vouch for keeping asterix-experiments in.
> >>> 'asterix-tools'
> >>>>>>>>>> and the others could probably go.
> >>>>>>>>>>
> >>>>>>>>>> On Wed, May 31, 2017 at 11:58 AM, Taewoo Kim
> >>>>>>>>>> <wangsaeu@gmail.com>
> >>>>>>>>>> wrote:
> >>>>>>>>>>
> >>>>>>>>>>> @Ildar: +1
> >>>>>>>>>>>
> >>>>>>>>>>> Best,
> >>>>>>>>>>> Taewoo
> >>>>>>>>>>>
> >>>>>>>>>>> On Wed, May 31, 2017 at 11:57 AM, Ildar Absalyamov <
> >>>>>>>>>>> ildar.absalyamov@gmail.com> wrote:
> >>>>>>>>>>>
> >>>>>>>>>>> I found Young-Seok=E2=80=99s asterix-experiment package usefu=
l for
> >>> everyone,
> >>>>>>>>>>>>
> >>>>>>>>>>> who
> >>>>>>>>>
> >>>>>>>>>> is doing any kind of experiments.
> >>>>>>>>>>>> Can we instead make an =E2=80=98asterix-contrib=E2=80=99 rep=
o and move it
> >>>>>>>>>>>> there,
> >>> the
> >>>>>>>>>>>>
> >>>>>>>>>>> same
> >>>>>>>>>>
> >>>>>>>>>>> way we did with asterix-bad?
> >>>>>>>>>>>> We can also launch an automated build in Jenkins to verify i=
t
> >>> builds
> >>>>>>>>>>>> against master, again the same way BAD is working. This
> >>>>>>>>>>>> package
> >>> does
> >>>>>>>>>>>>
> >>>>>>>>>>> not
> >>>>>>>>>
> >>>>>>>>>> have a lot of dependencies, so it will be fairly painless to
> >>> maintain
> >>>>>>>>>>>>
> >>>>>>>>>>> it.
> >>>>>>>>>>
> >>>>>>>>>>> On May 31, 2017, at 09:06, Yingyi Bu <buyingyi@gmail.com>
> >>>>>>>>>>> wrote:
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> Hi dev,
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>   I wonder if the following potentially obsolete modules
> >>>>>>>>>>>>> could
> >>> be
> >>>>>>>>>>>>>
> >>>>>>>>>>>> moved
> >>>>>>>>>>
> >>>>>>>>>>> out of the AsterixDB code base:
> >>>>>>>>>>>>>   -- asterix-experiment
> >>>>>>>>>>>>>   -- asterix-tools
> >>>>>>>>>>>>>   -- hyracks-dist
> >>>>>>>>>>>>>   -- hyracks-sever
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>   Any thoughts?
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> Best,
> >>>>>>>>>>>>> Yingyi
> >>>>>>>>>>>>>
> >>>>>>>>>>>> Best regards,
> >>>>>>>>>>>> Ildar
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>
> >>>> Best regards,
> >>>> Ildar
> >>>>
> >>>
> >>>
>
>

--94eb2c1b5926003ecb0550e7a2e6--