Skip to content

Commit

Permalink
Merge branch 'stable'
Browse files Browse the repository at this point in the history
* stable: (26 commits)
  (maint) COMMITTERS - EOL change to CRLF
  (doc) update CONTRIBUTING/COMMITTERS
  (GH-1241) XmlService - trace logging information
  (maint) formatting
  (GH-1241) FileSystem - move file creates directory
  (GH-1241) Explicitly handle closing
  (maint) formatting
  (GH-1292) Ensure manifest extracted on unpackself
  (log) replace_file use new lines for log
  (maint) update CHANGELOG / nuspec
  (maint) nuspec - add info links to description
  (maint) clean up lib nuspec
  (GH-1311) Install-ChocolateyPowershellCommand File/FileFullPath
aliases
  (GH-1284) ensure file/filefullpath on functions
  (maint) ReadMe updates
  (GH-1241) Use process id with update file
  (maint) restrict list start/end messages to log file
  (GH-1309) Restrict trace output
  (GH-1241) More Robust File.Replace
  (GH-1241) Use write_file for stream writing
  ...

# Conflicts:
#	CONTRIBUTING.md
#	README.md
  • Loading branch information
ferventcoder committed May 29, 2017
2 parents 237de6a + 5469ccd commit f153f21
Show file tree
Hide file tree
Showing 24 changed files with 730 additions and 247 deletions.
3 changes: 2 additions & 1 deletion .build.custom/nugetPrepare.post.step
Original file line number Diff line number Diff line change
Expand Up @@ -39,8 +39,9 @@
<exec program="${app.choco}"
workingdir="${dirs.drop.nuget}${path.separator}chocolatey${path.separator}tools${path.separator}chocolateyInstall"
commandline="${args.choco}" if="${platform::is-windows()}" />
<delete file="${dirs.drop.nuget}${path.separator}chocolatey${path.separator}tools${path.separator}chocolateyInstall${path.separator}tools${path.separator}detector.zip" failonerror="false" />
</target>

<target name="copy_legal">
<echo level="Warning" message="Copying Credits from '${dirs.current}${path.separator}${folder.documentation}${path.separator}legal${path.separator}CREDITS.md' to nuget packages"/>
<copy file="${dirs.current}${path.separator}${folder.documentation}${path.separator}legal${path.separator}CREDITS.md" tofile="${dirs.drop.nuget}${path.separator}chocolatey${path.separator}tools${path.separator}chocolateyInstall${path.separator}CREDITS.txt" failonerror="true" />
Expand Down
40 changes: 39 additions & 1 deletion CHANGELOG.md
Original file line number Diff line number Diff line change
Expand Up @@ -4,6 +4,44 @@ This covers changes for the "chocolatey" and "chocolatey.lib" packages, which ar

**NOTE**: If you have a licensed edition of Chocolatey ("chocolatey.extension"), refer to this in tandem with [Chocolatey Licensed CHANGELOG](https://github.com/chocolatey/choco/blob/master/CHANGELOG_LICENSED.md).

## [0.10.6](https://github.com/chocolatey/choco/issues?q=milestone%3A0.10.6+is%3Aclosed) (unreleased)

### BUG FIXES

* Fix - Chocolatey config changes in 0.10.4+ - The process cannot access the file because it is being used by another process - see [#1241](https://github.com/chocolatey/choco/issues/1241)
* Fix - PowerShell sees authenticode hash as changed in scripts that are UTF8 (w/out BOM) that contain unicode characters - see [#1225](https://github.com/chocolatey/choco/issues/1225)
* Fix - Chocolatey timed out immediately when execution timeout was infinite (0) - see [#1224](https://github.com/chocolatey/choco/issues/1224)
* Fix - choco list / search / info - Some packages can't be found - see [#1004](https://github.com/chocolatey/choco/issues/1004)
* Fix - chocolatey.config gets corrupted when multiple processes access simultaneously - see [#1258](https://github.com/chocolatey/choco/issues/1258)
* Fix - Update ShimGen to 0.8.x to address some issues - see [#1243](https://github.com/chocolatey/choco/issues/1243)
* Fix - Trace logging should only occur on when trace is enabled - see [#1309](https://github.com/chocolatey/choco/issues/1309)
* Fix - RefreshEnv.cmd doesn't set the correct PATH - see [#1227](https://github.com/chocolatey/choco/issues/1227)
* [API] Fix- chocolatey.lib nuget package has incorrect documentation xml - see [#1247](https://github.com/chocolatey/choco/issues/1247)
* [API] Fix - Chocolatey file cache still adds a 'chocolatey' directory on each install - see [#1231](https://github.com/chocolatey/choco/issues/1231)
* [API] Fix - List and Count should implement similar functionality as run - see [#1298](https://github.com/chocolatey/choco/issues/1298)
* Pro/Business - [API] Fix - Ensure DLL can work with licensed code - see [#1287](https://github.com/chocolatey/choco/issues/1287)

### IMPROVEMENTS

* Default package push url now uses push subdomain - see [#1285](https://github.com/chocolatey/choco/issues/1285)
* Report process id in the log files - see [#1239](https://github.com/chocolatey/choco/issues/1239)
* choco info / list / search - Include summary on detailed view - see [#1253](https://github.com/chocolatey/choco/issues/1253)
* choco info / list /search - Include release notes on detailed view - see [#1263](https://github.com/chocolatey/choco/issues/1263)
* choco list / search - Option to list packages only by name - see [#1237](https://github.com/chocolatey/choco/issues/1237)
* choco list / search - Allow sorting package results by relevance - see [#1101](https://github.com/chocolatey/choco/issues/1101)
* choco list / search - Search by tags only - see [#1033](https://github.com/chocolatey/choco/issues/1033)
* choco outdated - Option to leave out pinned packages - see [#994](https://github.com/chocolatey/choco/issues/994)
* Install-ChocolateyPackage and other functions should alias File/File64 - see [#1284](https://github.com/chocolatey/choco/issues/1284)
* Install-ChocolateyPowerShellCommand should alias File/FileFullPath for PsFileFullPath - see [#1311](https://github.com/chocolatey/choco/issues/1311)
* Logging - capture more information about a user (user name, domain, remote?, system?) - see [#615](https://github.com/chocolatey/choco/issues/615)
* Stop saying "0 packages failed." - see [#1259](https://github.com/chocolatey/choco/issues/1259)
* [API] provide a way to see ChocolateyConfiguration - see [#1267](https://github.com/chocolatey/choco/issues/1267)
* [API] Attempt to get ChocolateyInstall environment variable prior to extraction - see [#1297](https://github.com/chocolatey/choco/issues/1297)
* [API] Expose Container directly - see [#1294](https://github.com/chocolatey/choco/issues/1294)
* Pro/Business - Support for Package Audit (who installed packages) - see [#1238](https://github.com/chocolatey/choco/issues/1238)
* Pro/Business - [API] Ensure configuration retains base info between uses - see [#1296](https://github.com/chocolatey/choco/issues/1296)


## [0.10.5](https://github.com/chocolatey/choco/issues?q=milestone%3A0.10.5+is%3Aclosed) (March 30, 2017)

### BUG FIXES
Expand All @@ -12,7 +50,7 @@ This covers changes for the "chocolatey" and "chocolatey.lib" packages, which ar

### IMPROVEMENTS

* Show machine readable output with `choco outdated -r` - see [#1222](https://github.com/chocolatey/choco/issues/1222)
* Show machine readable output with `choco outdated -r` - see [#1222](https://github.com/chocolatey/choco/issues/1222)


## [0.10.4](https://github.com/chocolatey/choco/issues?q=milestone%3A0.10.4+is%3Aclosed) (March 30, 2017)
Expand Down
164 changes: 88 additions & 76 deletions COMMITTERS.md
Original file line number Diff line number Diff line change
@@ -1,76 +1,88 @@
Committers
============

## Branch Targeting

* Stable currently targeting 0.9.9.x
* Master currently targeting 0.9.10.x

Depending on where your fix/enhancement goes, please target the proper branch. Community members always target master, but committers should know where the fix they are presenting goes. It makes it much easier to push the shiny green button on a pull request. If you are not sure where to target, ask.

## Summary

We like to see folks contributing to Chocolatey. If you are a committer, we'd like to see you help from time to time with triage and the pull request process.

In all cases politeness goes a long way. Please thank folks for contributions - they are going out of their way to help make the code base better, or adding something they may personally feel is necessary for the code base.

Please be VERY familiar with [CONTRIBUTING](https://github.com/chocolatey/choco/blob/master/CONTRIBUTING.md) and follow the process as well.

## Terminology

**contributor** - A person who makes a change to the code base and submits a change set in the form of a pull request.

**change set** - A set of discrete commits which combined together form a contribution. A change set takes the form of git commits and is submitted in the form of a pull request. Used interchangeably with "pull request".

**committer** - A person responsible for reviewing a pull request and then making the decision what base branch to merge the change set into.

## Review Process

#### Receive new PR (pull request)

* A contributor sends a pull request (usually against master).
* A committer typically reviews it within a week or less to determine the feasibility of the changes.

#### Initial PR Review

* Has the user signed the Contributor License Agreement (CLA)?
* Did the user create a branch with these changes? If it is on their master, please ask them to review [CONTRIBUTING](https://github.com/chocolatey/choco/blob/master/CONTRIBUTING.md).
* Did the user reformat files and they should not have? Was is just white-space? You can try adding [?w=1](https://github.com/blog/967-github-secrets) to the URL on GitHub.
* Are there tests? We really want any new contributions to contain tests so unless the committer believes this code really needs to be in the code base and is willing to write the tests, then we need to ask the contributor to make a good faith effort in adding test cases. Ask them to review the [contributing document](https://github.com/chocolatey/choco/blob/master/CONTRIBUTING.md) and provide tests. **Note:** Some commits may be refactoring which wouldn't necessarily add additional test sets.
* Is the code documented properly? Does this additional set of changes require changes to the [wiki](https://github.com/chocolatey/choco/wiki)?
* Was this code warranted? Did the contributor follow the process of gaining approval for big change sets? If not please have them review the [contributing document](https://github.com/chocolatey/choco/blob/master/CONTRIBUTING.md) and ask that they follow up with a case for putting the code into the code base on the mailing list.

#### Review the Code
* Does the code meet the naming conventions and formatting (need link)?
* Is the code sound? Does it read well? Can you understand what it is doing without having to execute it? Principal of no clever hacks (need link).
* Does the code do what the purpose of the pull request is for?

#### Accepting a PR

Once you have reviewed the initial items, and are not waiting for additional feedback or work by the contributor, give the thumbs up that it is ready for the next part of the process (merging).

Unless there is something wrong with the code, we don't ask contributors to rebase against master. They did the work to create the patch in the first place, asking them to unnecessarily come back and try to keep their code synced up with master is not an acceptable process.

## Merging

Once you have reviewed the change set and determined it is ready for merge, the next steps are to bring it local and evaluate the code further by actually working with it, running the tests locally and adding any additional commits or fix-ups that are necessary in a local branch.

When merging the user's contribution, it should be done with `git merge --log --no-ff` to create a merge commit so that in case there is an issue it becomes easier to revert later, and so that we can see where the code came from should we ever need to go find it later (more information on this can be found [here](https://www.kernel.org/pub/software/scm/git/docs/git-merge.html) and also a discussion on why this is a good idea [here](http://differential.io/blog/best-way-to-merge-a-github-pull-request)).

### Merge Retargeting to Stable

Because we ask contributors to target master, sometimes a fix/enhancement may need to be retargeted to stable. This process is somewhat easy thanks to git. In most cases you won't even need to ask the user to do this for you.

* Add the user's remote.
* `git fetch user`
* `git checkout branch_from_user`
* `git rebase --onto stable master` - this uses the local branch, starts with latest stable and reapplies the commits from the branch to it, removing all commits that were only on the master.
* `build.bat` - build and test
* `git checkout stable`
* `git merge branch_from_user --log --no-ff`
* `git branch -d branch_from_user`

References

* http://pivotallabs.com/git-rebase-onto/
* http://git-scm.com/book/ch3-6.html
Committers
============

<!-- TOC -->

- [Branch Targeting](#branch-targeting)
- [Summary](#summary)
- [Terminology](#terminology)
- [Review Process](#review-process)
- [Receive new PR (pull request)](#receive-new-pr-pull-request)
- [Initial PR Review](#initial-pr-review)
- [Review the Code](#review-the-code)
- [Accepting a PR](#accepting-a-pr)
- [Merging](#merging)
- [Merge Retargeting to Stable](#merge-retargeting-to-stable)

<!-- /TOC -->

## Branch Targeting
* Stable currently targeting 0.10.x
* Master currently targeting 0.11.x

**NOTE:** The above may be out of date. The best way to determine what branch is being targeted for stable is to run `git describe`. Stable and master are typically different on minor version (`x.y.z` - the `y`).

Depending on where your fix/enhancement goes, please target the proper branch. Community members always target master, but committers should know where the fix they are presenting goes. It makes it much easier to push the shiny green button on a pull request. If you are not sure where to target, ask.

## Summary
We like to see folks contributing to Chocolatey. If you are a committer, we'd like to see you help from time to time with triage and the pull request process.

In all cases politeness goes a long way. Please thank folks for contributions - they are going out of their way to help make the code base better, or adding something they may personally feel is necessary for the code base.

Please be VERY familiar with [CONTRIBUTING](https://github.com/chocolatey/choco/blob/master/CONTRIBUTING.md) and follow the process as well.

## Terminology
**Contributor** - A person who makes a change to the code base and submits a change set in the form of a pull request.

**Change Set** - A set of discrete commits which combined together form a contribution. A change set takes the form of git commits and is submitted in the form of a pull request. Used interchangeably with "pull request".

**Committer** - A person responsible for reviewing a pull request and then making the decision what base branch to merge the change set into.

## Review Process
#### Receive new PR (pull request)
* A contributor sends a pull request (usually against master).
* A committer typically reviews it within a week or less to determine the feasibility of the changes.

#### Initial PR Review
* Has the user signed the Contributor License Agreement (CLA)?
* Did the user create a branch with these changes? If it is on their master, please ask them to review [CONTRIBUTING](https://github.com/chocolatey/choco/blob/master/CONTRIBUTING.md).
* Did the user reformat files and they should not have? Was is just white-space? You can try adding [?w=1](https://github.com/blog/967-github-secrets) to the URL on GitHub.
* Are there tests? We really want any new contributions to contain tests so unless the committer believes this code really needs to be in the code base and is willing to write the tests, then we need to ask the contributor to make a good faith effort in adding test cases. Ask them to review the [contributing document](https://github.com/chocolatey/choco/blob/master/CONTRIBUTING.md) and provide tests. **Note:** Some commits may be refactoring which wouldn't necessarily add additional test sets.
* Is the code documented properly? Does this additional set of changes require changes to the [wiki](https://github.com/chocolatey/choco/wiki)?
* Was this code warranted? Did the contributor follow the process of gaining approval for big change sets? If not please have them review the [contributing document](https://github.com/chocolatey/choco/blob/master/CONTRIBUTING.md) and ask that they follow up with a case for putting the code into the code base on the mailing list.

#### Review the Code
* Does the code meet the naming conventions and formatting (need link)?
* Is the code sound? Does it read well? Can you understand what it is doing without having to execute it? Principal of no clever hacks (need link).
* Does the code do what the purpose of the pull request is for (and only that)?

#### Accepting a PR
Once you have reviewed the initial items, and are not waiting for additional feedback or work by the contributor, give the thumbs up that it is ready for the next part of the process (merging).

Unless there is something wrong with the code, we don't ask contributors to rebase against master. They did the work to create the patch in the first place, asking them to unnecessarily come back and try to keep their code synced up with master is not an acceptable process.

## Merging
Once you have reviewed the change set and determined it is ready for merge, the next steps are to bring it local and evaluate the code further by actually working with it, running the tests locally and adding any additional commits or fix-ups that are necessary in a local branch.

When merging the user's contribution, it should be done with `git merge --log --no-ff` to create a merge commit so that in case there is an issue it becomes easier to revert later, and so that we can see where the code came from should we ever need to go find it later (more information on this can be found [here](https://www.kernel.org/pub/software/scm/git/docs/git-merge.html) and also a discussion on why this is a good idea [here](http://differential.io/blog/best-way-to-merge-a-github-pull-request)).

### Merge Retargeting to Stable
Because we ask contributors to target master, sometimes a fix/enhancement may need to be retargeted to stable. This process is somewhat easy thanks to git. In most cases you won't even need to ask the user to do this for you.

* `git fetch upstream pull/<github_pull_id>/head:pr<github_pull_id>` - `upstream` is `[email protected]:chocolatey/choco.git`
* `git checkout pr<github_pull_id>`
* `git rebase --onto stable master` - this uses the local branch, starts with latest stable and reapplies the commits from the branch to it, removing all commits that were only on the master.
* `build.bat` - build and test
* `git checkout stable`
* Any addtional changes or testing here.
* `git merge pr<github_pull_id> --log --no-ff`
* `git branch -d pr<github_pull_id>`
* `git checkout master`
* `git merge stable`
* Make any last checks to ensure the git logs look good. The next step sets the commits in stone and unable to be changed.
* `git push upstream`

References

* http://pivotallabs.com/git-rebase-onto/
* http://git-scm.com/book/ch3-6.html
Loading

0 comments on commit f153f21

Please sign in to comment.