Thanks for Ross' slides, I look forward to reviewing them. J On Jun 16, 2013 3:30 AM, "Christian Grobmeier" <grobme...@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 <akapla...@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 <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 > >> > > >> > > > > -- > http://www.grobmeier.de > https://www.timeandbill.de >
