bigtop-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Konstantin Boudnik <...@apache.org>
Subject Re: [DISCUSS] Working on the BOM.next (0.9.0 or 1.0?)
Date Thu, 16 Oct 2014 04:13:42 GMT
I guess I am pretty much in-line with most of your sentiment. Two things I'd
like to hash-out:
 - supporting and LTS and a bleeding edge distro: won't LTS packages normally
   cover for the newer releases?

 - as for growing community: I think our best bet is to improve the UX for
   our users. Otherwise, it all be only good for developer types. And I think
   we have plans to work on it.

Let's start a separate thread on having a BayArea meetup right after this week
is over. Andre - are you still up to host it at A9?

Thanks,
  Cos

On Sun, Oct 12, 2014 at 08:22PM, Roman Shaposhnik wrote:
> Hi!
> 
> Sorry for coming to the party rather late (but at least
> I had some time to think about it ;-)).
> 
> On Sat, Oct 4, 2014 at 4:10 PM, Konstantin Boudnik <cos@apache.org> wrote:
> > Now as 0.8.0 is practically done I want to kick of the discussion about next
> > release's scope and aim. We already have discussed a number of things that we
> > want to address in this round, including
> >     - CI improvements
> >     - build system enhancements
> >     - overhaul of the testing experience
> >     - TBD
> 
> Yup. All of the above. Personally, whatever limited cycles I've
> got I'll sink them into CI and Docker/OSv work. Not to mention
> the usual upgrades of the BOM.
> 
> Not sure what other have as the main goal for the next few months.
> 
> As a general suggestion: I'd really like to see us get together
> sometime soon (perhaps Strata or right after it in the valley)
> brainstorm some of these things that we'd like to do and put
> them on a wiki (or better yet into JIRAs).
> 
> Now, if I were a king for a day (read: I had extra resources,
> not just my copious free time) I would really like to tackle
> a problem of tracking upstream releases of various components
> and essentially offering Bigtop feedback whenever they
> do their RCs. I've tried doing that on and off with Hadoop,
> but since it was pretty time consuming had to drop it :-(
> 
> > A very important topic to cover here is, of course, the scope of the next
> > release. Bigtop has a very powerful ability to help new technologies to thrive
> > by wider promoting them across the Apache communities and beyond. However,
> > without deliberate help from the perspective projects we can not keep on
> > supporting them in the Apache Hadoop Stack: after all we are a bunch of
> > volunteers spending our own time on things we like to do. Hence, we need to
> > carefully prioritize what we realistically can or can not support.
> 
> I think historically what I've seen is that upstream communities are more
> than happy to receive feedback but most of the time they don't have
> cycles to contribute to Bigtop directly.
> 
> Currently I feel like the size of our stack (in terms of # of components)
> is not (yet) over the top. Feels like we can keep managing it just fine.
> 
> > The other side of this coin is to make this project fun where people want to
> > contribute something they feel passionate about. Let's say, I am the only one
> > contributing fixes and supporting component X. However, for whatever reason I
> > couldn't possibly care less about having component X on board. The question is
> > - shall I use my limited time on the face of this planet for something that
> > makes me tick, instead of wasting it on the dull chores around component X?
> > Let's weigh carefully on what we want to carry on and what we'll be dropping
> > this time.
> 
> That's a great point!
> 
> > Supported OS spectrum: let's drop the dead weight and carefully consider what
> > to add.
> 
> I'd say we only have to support one stable (LTS type) of OS and one cutting
> edge in every "family". But if push comes to shove, I'd rather optimize in favor
> of cutting edge since that's where the fun is (at least for me).
> 
> > Release cycle: with new docker based CI we should be better equipped for
> > regular builds testing and build environment which will be _exactly_ the same
> > for developers and official Jenkins. Hence, can we have next release in the
> > by the end of 2014? We already know that 0.8.0 has a few issues that we want
> > to improve upon quickly.
> 
> I'd very strongly suggest we try 6 months this time, but be very, very
> diligent about
> it. IOW, the next release is *guaranteed* to happen in exactly 6
> months from now.
> We may, of course, still have intermediate releases if anybody's interested.
> 
> > User facing documentation, wiki, website: let's see where we can get some help
> > with this. Shall we try recruiting fresh-grads and students who wants to start
> > in on of the projects we support, but they don't know how? How we can increase
> > the reach?
> 
> If only I knew how to recruit more users :-( I've tried everything by now and it
> still feels like we've got a core community of developers, but not so
> much users.
> 
> Thanks,
> Roman.

Mime
View raw message