Prepare the repo for open sourcing

[michaelklishin]

From legal:

1) copyright headers on all files:

Copyright (C) [START_DATE]-2015 Pivotal Software, Inc. 

All rights reserved. This program and the accompanying materials
are made available under the terms of the under the Apache License, 
Version 2.0 (the "License”); you may not use this file except in compliance 
with the License. You may obtain a copy of the License at

http://www.apache.org/licenses/LICENSE-2.0

Unless required by applicable law or agreed to in writing, software
distributed under the License is distributed on an "AS IS" BASIS,
WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
See the License for the specific language governing permissions and
limitations under the License.

2) LICENSE and NOTICE file in top-most directory

- LICENSE should be the full text of the Apache 2.0 license 
- NOTICE should look like this:

[PRODUCT_NAME]

Copyright (c) [START_DATE]-2014 Pivotal Software, Inc. All Rights Reserved. 

This product is licensed to you under the Apache License, Version 2.0 (the "License").  
You may not use this product except in compliance with the License.  

This product may include a number of subcomponents with separate copyright notices 
and license terms. Your use of these subcomponents is subject to the terms and 
conditions of the subcomponent's license, as noted in the LICENSE file.

3) Scrub any/all comments for unnecessary content (developer communications, names, informal or internal Pivotal references, customer/competitor references, proprietary information about internal workings of Pivotal, etc) - basically, if a comment isn’t intended for a public audience it should be removed or revised.

• Add LICENSE and NOTICE files
• Add a new README without Pivotal-specific bits
• Add copyright headers
• Fix UTF-8 character rendering in Markdown
• Scrub any sensitive content if necessary
• Get legal permission to open source
• Create a new public repository and push the latest commit only to it

[dumbbell]

Does "Scrub any sensitive content if necessary" cover the content of the repository only, or the commit log as well?

[michaelklishin]

Everything. I doubt we have anything sensitive, though, given that the site has always been public.

[michaelklishin]

We can also consider open sourcing a new repo (with a single initial commit).

[videlalvaro]

What @michaelklishin suggest seems reasonable, otherwise reading every commit log will take for ever. While that entrails losing the repo history, at the same time this is not a code repo, so most probably we won't need to be reviewing commit history.

[dumbbell]

I agree, but we can copy the history to another private repository so we don't loose anything.

[videlalvaro]

@dumbbell sure. We keep the old repo somewhere, private.

[michaelklishin]

The only thing that's left is the potential sensitive content audit. I believe all source file that we still use (read: not change log files which are text and cannot have comments anyway) now have ASL 2.0 headers and render fine.

Feel free to take a look at what may need scrubbing :)

[dumbbell]

I'm working on squashing commits. To clarify the "Create a new public repository and push the latest commit only to it" step, in fact, it will be one commit per branch we keep. We will keep:

• master
• stable
• stage
• live

[dumbbell]

Here is what I prepared:

1. Created an empty repository with the content of the live branch
2. Committed this content to make one single commit on this live branch
3. Created the stage, stable and master branches, based on live
4. Committed the diff between live and master in a single commit in the new master branch

The result has:

• a live branch (stage and stable points to live)
• a master branch with one commit beyond live

The rabbitmq-website-17 branch is not merged yet to any branch. @michaelklishin, do you think it's ready to be merged to live?

Another question is: what do we do about the current issues?

• Either we move the full history to a new private repository, push the squashed history to this one and make it public (current issues are made public)
• or we push the squashed history to a new public repository (current issues remain private).

There are also the links to website issues/PRs in other projects (issues, PRs, commits). Only the second solution above keeps those links working.

I prefer the second solution, even if we have to copy the open issues to the new repository manually (there are 8 issues beside this one). What do you think?

[michaelklishin]

I vote for pushing this repository into a new private "archive" one, force-pushing trimmed down history to this one and open sourcing it together with issues.

[michaelklishin]

I'll merge rabbitmq-website-17 into live and master and once we are ready to make the repo public, will notify legal to do a final review.

[dumbbell]

@michaelklishin, so, you prefer solution n°1? This will break all the links in other repositories

[michaelklishin]

@dumbbell yes, but I think it won't affect our (or anybody else's) work much. I'd rather keep the list of issues. But I'd be OK with creating a new repo and moving issues there by hand.

[dumbbell]

The full history was copied to a separate private repository and a squashed history was pushed to this repository.

[dumbbell]

The repository is now public.