Sponsored Content
Full Discussion: Open source project
Top Forums Shell Programming and Scripting Open source project Post 302652181 by pludi on Wednesday 6th of June 2012 04:29:26 PM
Old 06-06-2012
A very simple start: pick the open source software you use most often, register with their bug tracking system, and start testing the newest builds. When something breaks, try to repeat it, and send it in with instructions on how to reproduce, what happens, ...

Over time you might start looking at the code to see why it breaks, or how to improve the documentation.
 

2 More Discussions You Might Find Interesting

1. UNIX for Advanced & Expert Users

Recruiting for an open source project

I am posting this gauge the level of interest among the community in forming an open source team to work on an automation harness I am about to make available. I already have a working POC running at my place of work, but it is not secure enough for production environments. However, I am about... (6 Replies)
Discussion started by: steadyonabix
6 Replies

2. Shell Programming and Scripting

Feedback on "withsome" open source project

I have been developing an open source UNIX project for a few years and am looking for feedback on whether further development of the "withsome" project is of interest to other programmers. One simple example to give an idea of the project is: withsome ./pugs vi Pugs.pm 1)... (0 Replies)
Discussion started by: ronaldxs
0 Replies
GIT-REQUEST-PULL(1)						    Git Manual						       GIT-REQUEST-PULL(1)

NAME
git-request-pull - Generates a summary of pending changes SYNOPSIS
git request-pull [-p] <start> <url> [<end>] DESCRIPTION
Generate a request asking your upstream project to pull changes into their tree. The request, printed to the standard output, begins with the branch description, summarizes the changes and indicates from where they can be pulled. The upstream project is expected to have the commit named by <start> and the output asks it to integrate the changes you made since that commit, up to the commit named by <end>, by visiting the repository named by <url>. OPTIONS
-p Include patch text in the output. <start> Commit to start at. This names a commit that is already in the upstream history. <url> The repository URL to be pulled from. <end> Commit to end at (defaults to HEAD). This names the commit at the tip of the history you are asking to be pulled. When the repository named by <url> has the commit at a tip of a ref that is different from the ref you have locally, you can use the <local>:<remote> syntax, to have its local name, a colon :, and its remote name. EXAMPLE
Imagine that you built your work on your master branch on top of the v1.0 release, and want it to be integrated to the project. First you push that change to your public repository for others to see: git push https://git.ko.xz/project master Then, you run this command: git request-pull v1.0 https://git.ko.xz/project master which will produce a request to the upstream, summarizing the changes between the v1.0 release and your master, to pull it from your public repository. If you pushed your change to a branch whose name is different from the one you have locally, e.g. git push https://git.ko.xz/project master:for-linus then you can ask that to be pulled with git request-pull v1.0 https://git.ko.xz/project master:for-linus GIT
Part of the git(1) suite Git 2.17.1 10/05/2018 GIT-REQUEST-PULL(1)
All times are GMT -4. The time now is 01:25 PM.
Unix & Linux Forums Content Copyright 1993-2022. All Rights Reserved.
Privacy Policy