Totally agree with all, we need to get better and do more to just became bigger and better.
2013/6/15 John Blossom <jblos...@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 <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 > > >
