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 <grobme...@gmail.com>wrote: > On Fri, Jun 14, 2013 at 9:29 PM, Joseph Gentle <jose...@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 >
