ignite-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dmitriy Setrakyan <dsetrak...@gridgain.com>
Subject Re: Further community development and other thoughts
Date Sat, 03 Jan 2015 16:53:15 GMT
On Sat, Jan 3, 2015 at 3:35 AM, Branko ─îibej <brane@apache.org> wrote:

> On 03.01.2015 08:03, Konstantin Boudnik wrote:
> > Just to keep everyone in the loop...
> >
> > Dmitriy and I had a good conversation today about what else needs to be
> done
> > in the Ignite (incubating) to further lower the entrance barrier for new
> > contributors. So far we have identified the following:
> >
> >  1. need for a public CI: current CI is based on TeamCity ran privately
> by
> >     GridGain team. While it is a hassle and a disruptive one to move the
> build
> >     infrastructure to the INFRA's ran Jenkins, there's a need to publicly
> >     expose the "official" project CI & test results.
> >
> >     This effort needs to be hooked up to the artifacts publishing, that
> Roman
> >     brought up earlier. I am pretty sure that even with CI infra sitting
> >     outside of the builds.apache.org the official build producing and
> >     publishing the artifacts can be executed on the ASF build hosts.
> >
> >     Dmitriy has some ideas on how to solve it and I'll let him to chime
> in to
> >     avoid broken phone effect.
>
> I've said before that it should not be an impossible task to get a
> TeamCity instance running on an ASF-owned, infra-supported VM. IIUC cost
> of licenses is not an issue; JB offers TeamCity free for Open Source
> projects (and anything at the ASF definitely fits the bill). A slightly
> bigger concern is getting Infra to support yet another CI platform, but
> I think it's worth making the effort.
>

I agree, and we should definitely start the effort of enabling TC builds on
ASF-owned VMs. I think an INFRA ticket has to be filed (can any of the
mentors file it?). In the mean time, GridGain will dedicate several servers
for the Apache Ignite (incubating) project which will be open to public and
will be running TC builds.

Cos suggested that we can have a bot script automatically check that a
patch was added to Jira and automatically trigger a TC build. This is
definitely something very useful, as it will allow non-committers verify
their patches with CI builds. We should set it up as soon as possible.


>
> >  2. First release. I've learned that community is pretty busy finalizing
> the
> >     refactoring and changing some APIs in the project and that makes
> things a
> >     bit liquid. However, even right now the project can be build and
> deployed
> >     and old API is working as before. Hence, in my opinion, the release
> can be
> >     cut, although it won't be in the GA quality at the moment. But at
> least it
> >     will be something the users can try on. It also will create an
> invaluable
> >     experience for all involve, and will demonstrate what does and
> doesn't
> >     work in the release process.
>
> If the APIs aren't finalized yet, consider releasing a beta version.
> This is still an "official ASF release" from the point of view of legal
> requirements; IOW it's a good way to define, practice and polish the RM
> process. But you can put a big warning in the release notes about
> changing APIs and not production-ready and not supported etc.
>

This was my thinking as well. A beta release sounds good. To the least we
should be able to start publishing nightly releases.


>
> >  3. community growth: what is essential, in my opinion, is to be able to
> >     spread the word about the project and be essentially able to recruit
> new
> >     contributors to the project and the community.
> >
> >     All sorts of communication channels could be used for it: website
> updates,
> >     blogs, twitting, meetups, hackathons, and so on. I believe the dev@
> list
> >     is an important tool in this: lively discussions about the on-going
> >     development should attract more attention and participation from
> others.
> >
> >     How about start using dev@ for the engineering communication?
>
> This is something I've been meaning to write about for a while ... I see
> lots of JIRA notices popping up in the mail, and they're obviously the
> result of some discussion that's invisible to the rest of the world.
>
> The policy here is that discussion needs to happen on the dev@ list. If
> it's not on the list, it never happened; the list archives are /the/
> definitive source of info about project history. (This implies, for
> example, that discussions that happen at a hackathon must be summarized
> to the dev@ list, too.)
>
> I've found this to be one of the hardest parts of adjusting to the "ASF
> way" of doing things. The majority of incubating projects are similar to
> Ignite -- the initial PPMC consists mostly of people who work for one
> company and are used to their own communication channels. Which is fine;
> there's nothing wrong with face-to-face discussions and phone calls and
> internal mails and whatnot; however, at least the results, and
> preferably the progress of those discussions should be tracked on the
> dev@ list.
>
> I suggest the best way to adjust is to just stop using internal channels
> for technical discussions about the project, code and community, and
> simply start using the dev@ list email for that. It takes a bit of
> additional effort because you do have to consider that whatever you
> write here ends up in a public archive forever; but the sooner you start
> doing this, the easier it will be to get used to the idea. Soon enough,
> writing to dev@ will become the natural choice.
>
> >     If this is
> >     done using internal emails - it won't be much of a help to involve a
> wider
> >     audience into the community.
>
> Exactly.
>
> >     E.g. people need to learn that there's such a
> >     project and see what's going on there. They should be willing to
> spend
> >     their time on it. But it is essential that a contribution shouldn't
> come
> >     with a steep learning curve of how to make one; a new-comer should
> have an
> >     easy way to submit a patch and have it automatically validated by
> same
> >     official project CI. That's where a well-documented development
> process -
> >     Wiki or just a website - comes to mind: a simple "How To Contribute"
> page
> >     would be a great start.
> >
> >     And of course a reliable release process will help with the matter.
> >
> > Hey, I understand that I might be pushing for a lot ;) And it doesn't
> have to
> > be done over night. But these are essential steps to think about and
> make.
> > Can other mentors chime in here, pretty please? Did I miss something
> else? How
> > the "recruiting process" can be improved?
>
> I'm a dinosaur ... actually, I think we determined on general@incubator
> that I'm a sauropsid ... so I have a dim view of social networks and
> Twitter and such. But I imagine that a number of Hadoop users and
> developers might be interested in Ignite, especially if you bring in the
> "Hadoop Accelerator" code mentioned in the other thread. Writing to the
> users@hadoop and perhaps dev@hadoop lists about Ignite would probably
> generate a fair amount of interest.
>

I also agree with all of the above. Specifically like the idea of writing
to hadoop email lists.


>
>
> TL;DR: +1 to everything you wrote.
>
> -- Brane
>

D.

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message