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

Reply via email to