incubator-wave-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From John Blossom <jblos...@gmail.com>
Subject Re: A Call To Developers
Date Sun, 16 Jun 2013 19:34:28 GMT
Thanks for Ross' slides, I look forward to reviewing them. J
On Jun 16, 2013 3:30 AM, "Christian Grobmeier" <grobmeier@gmail.com> wrote:

> Ross Gardler was last year on the ASF board and is a well-respected
> community member. He knows a lot about driving open source projects,
> because knowing that is also his day job. On Apache Con EU he held a
> great presentation on open source risks:
>
> http://de.slideshare.net/rgardler/managing-project-risk-15725610
>
> It pretty much sums up a lot of things
>
>
> On Sat, Jun 15, 2013 at 5:22 PM, Andrew Kaplanov <akaplanov@gmail.com>
> wrote:
> > Totally agree with all, we need to get better and do more to just became
> > bigger and better.
> >
> >
> > 2013/6/15 John Blossom <jblossom@gmail.com>
> >
> >> Christian,
> >>
> >> Thanks for clarifying this. One of the factors which I hope that the
> >> developers new to Apache consider is that just because one calls their
> >> product open source does not mean that you have the resources to manage
> an
> >> open source program in a way that will lead to successful product
> >> implementations. For people to commit major development resources to a
> >> platform like Wave they will need assurances that there is a legal and
> >> administrative framework that will protect their development investment
> >> when they commit custom/bespoke assets on top of open source Wave. This
> >> sort of assurance for infrastructure like SMTP/POP email is what led to
> its
> >> explosion decades ago, as did the growth of the LAMP stack incorporating
> >> Apache's web server assets. We want to be aggressive, innovative and
> >> attract as many people as possible to the power of Wave through outlets
> >> such as Github. But at the end of the day, if we want to change the
> world
> >> with Wave, then we want to play it smart.
> >>
> >> Best,
> >>
> >> John
> >>
> >> On Sat, Jun 15, 2013 at 3:20 AM, Christian Grobmeier <
> grobmeier@gmail.com
> >> >wrote:
> >>
> >> > On Fri, Jun 14, 2013 at 9:29 PM, Joseph Gentle <josephg@gmail.com>
> >> wrote:
> >> > > On Fri, Jun 14, 2013 at 11:48 AM, Christian Grobmeier
> >> > > You mentioned that the code has to be first committed to the apache
> >> > > repositories for legal reasons. What exactly are the requirements
> >> > > there? Is it bad if I have my own local mirror of the project and
> >> > > commit there? (Technically, my local machine is a private mirror
> that
> >> > > gets my commits first).
> >> >
> >> > Please see Upayaviras response.
> >> > What I actually meant it, the official repository for the source code
> >> > needs to be the ASF one. For example, if 99% of the team works on
> GitHub
> >> > and does not reflect the changes to the ASF, one clearly cannot say
> the
> >> ASF
> >> > hosts the one canonical repository.
> >> >
> >> > Besides the social impact Upayavira has mentioned, there might be
> >> concerns
> >> > on the IP. Do we really have every ICLA on file for every GitHub pull
> >> > request?
> >> > How is it documented? If all documentation on code contributions are
> only
> >> > on GitHub, then we might not have access to that information if we
> need
> >> it.
> >> >
> >> > There is no legal problem if you commit something to a github
> repository
> >> > and later decide to contribute the code to the official repository.
> >> >
> >> > > Are the problems around public distribution?
> >> >
> >> > The ASF releases source packages in first place. Binary packages are
> >> > optional,
> >> > but many projects release them. One requirement is to provide
> >> > distributions from
> >> > an ASF server. This is done by committing the package to a specific
> svn
> >> > tree.
> >> > From there it will be mirrored.
> >> >
> >> > Optional you can release your code as maven artifact to the Maven
> >> > Grand Repository.
> >> > Its done by releasing to there: repository.apache.org/
> >> > We have a maven parent pom which deals with a lot of the specifics for
> >> > this task.
> >> >
> >> > These are our official distribution channels so far.
> >> >
> >> > In some cases you can request/build up new channels. For example, in
> the
> >> > log4php
> >> > project we wanted a pear channel, because back then it was usus to use
> >> > that.
> >> > http://pear.apache.org
> >> >
> >> > What you cannot do is to use a third party as official distributor.
> >> >
> >> > For example, consider the Chrome App Store. It's not within our
> reach, it
> >> > can't be official. But of course you can open an account there, share
> the
> >> > account details across the PMC and upload your binary to this place.
> >> > You should link to the official sources and tell the world, it is not
> >> > an official
> >> > channel but maintained by some PMC members. Then you should be fine.
> >> >
> >> > Apache OpenOffice had some special requirements to distributions too.
> >> > I don't know about the specifics, but they spoke a lot to our infra
> and
> >> > somehow
> >> > teamed up with SourceForge. Now they have an official channel there
> >> > too (I think).
> >> >
> >> > Basically you can say, i have never seen a project which wanted a
> >> specific
> >> > channel which they couldn't get.
> >> >
> >> > It is just necessary to properly fill up our own channels.
> >> >
> >> > More on releasing can be found here:
> >> > https://www.apache.org/dev/#releases
> >> >
> >> > > Does it then also matter where code review happens?
> >> >
> >> > Just consider the social impacts, then you are fine. You can make code
> >> > reviews on IRC,
> >> > if you wish. But others from the project cannot jump in, nor is it
> >> > properly documented.
> >> > You can use Hangout, but its the same there. Also consider, even when
> the
> >> > whole
> >> > team is on Hangout to review code, outsiders cannot access this and
> thus
> >> > not
> >> > join the project.
> >> >
> >> > I think there are no legal implications if you would use some Github
> >> > tools for review.
> >> > But of course, there is an social impact. Also decision making should
> >> > happen on the list.
> >> > If a code review fails, the discussion to solve the problem should
> >> > happen on list, not
> >> > on f.e. GitHub.
> >> >
> >> > > I ask because while I don't have a problem with an apache git
> >> > > repository being the ultimate source of truth, I also quite like
> >> > > github's pull requests as a system for code reviews.
> >> > >
> >> > > I'm not interested in taking the project away from apache. I
> actually
> >> > > think the community ownership model works well for this project.
> >> > > Github works much better with a benevolent dictator. But that said,
> >> > > I'd like to know what tools we can and can't use.
> >> >
> >> > Sure, that's why mentors are usually on the project and help.
> >> > The project needs to find out how we (ASF) work.
> >> >
> >> > I also believe the community model will work well for Wave.
> >> >
> >> > Its good to bring up such questions, keep them coming. Also don't be
> >> > afraid to
> >> > bring up ideas for improving the workflow. I am a bit conservative
> >> > when it comes to tooling.
> >> > Others may have different opinions. If a concrete proposal of workflow
> >> > comes in,
> >> > we also might consider to bring this question up to general@incubator
> ,
> >> > where more people
> >> > might have recommendations for us.
> >> >
> >> > Cheers!
> >> >
> >> >
> >> > >
> >> > > -J
> >> >
> >> >
> >> >
> >> > --
> >> > http://www.grobmeier.de
> >> > https://www.timeandbill.de
> >> >
> >>
>
>
>
> --
> http://www.grobmeier.de
> https://www.timeandbill.de
>

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