EPICS Controls Argonne National Laboratory

Experimental Physics and
Industrial Control System

1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  <20162017  2018  2019  2020  2021  2022  2023  2024  Index 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  <20162017  2018  2019  2020  2021  2022  2023  2024 
<== Date ==> <== Thread ==>

Subject: RE: Guide needed in order to work with the EPICS related Git repositories
From: <[email protected]>
To: <[email protected]>, <[email protected]>, <[email protected]>
Date: Wed, 17 Feb 2016 10:30:29 +0000

Hi Bruce,

 

The use of feature branches on your own fork is a very good idea and I’d highly recommend it.

 

We did not want to too prescriptive in our basic areaDetector contributors workflow – at least not when it comes to managing your own fork (as it effectively belongs to your account). So we just stuck to the most basic case where a contributor modifies her/his own master branch and then issue the PR.

 

I’m happy to receive a contribution to the workflow wiki page with a section on your feature-branch workflow. The wiki is actually also git repository that you can clone on: https://github.com/areaDetector/areaDetector.wiki.git

 

Unfortunately github does not support Pull Requests to wiki-repos so you’ll have to send me your patch by email (old school :-))

 

Cheers,

Ulrik

 

From: Bruce Hill [mailto:[email protected]]
Sent: 17 February 2016 04:42
To: Pedersen, Ulrik (DLSLtd,RAL,TEC); [email protected]; [email protected]
Cc: [email protected]; [email protected]
Subject: Re: Guide needed in order to work with the EPICS related Git repositories

 

Hi Ulrik and Mark,
I was comparing my procedure for submitting patches to areaDetector to
the areaDetector-Git-Workflows wiki page and noticed that the wiki doesn't
recommend feature branches for contributors.    I found w/ my areaDetector
contributions that it was best not to make any commits directly on my forked
master branch.

While it probably works out ok if there's a simple change that gets accepted
right away, problems happen if the change isn't accepted right away, or if you
have multiple pull requests and some need more work or aren't accepted.

Here's the procedure I've been using.

# To submit a patch as a new pull request
1. Make sure your master branch is uptodate
git pull origin master
2. Switch workspace to master prior to creating each new feature staging branch!
git checkout master
3. Create feature staging branch
git checkout -b feature-name
4. Apply patch (or make changes to files directly)
patch --strip 0 -i path_to_patch_file
5. Use git diff and git status to make sure all is well
5a. Be sure to expand all tabs in any changed lines
6. Commit changes to local git repo
git commit -a -m "What this patch does"
7. Push back to orgin on github
git push -u origin feature-name
8. Go to github and submit pull request(s) to developer's fork

This has the advantage of keeping each proposed change on it's own branch
where it can be tweaked or discarded as needed w/o impacting the master branch.

What do you guys think?
Should this be added to the wiki?

Regards,
- Bruce

On 02/16/2016 03:26 AM, [email protected] wrote:

Hi Han,
 
In order to contact the developers (at least for areaDetector - but probably also for other modules) it is useful to simply create an issue-ticket on the github repository. For areaDetector this is often where contributors start by presenting a new idea or change that they would like to see and a discussion is had about how to best implement the new feature. If you start the description by volunteering to work on it then maintainers are usually happy to guide you in the right direction :-) 
 
See for example a recent ticket on areaDetector/ADCore where we had an extensive debate about a requested change: https://github.com/areaDetector/ADCore/issues/145 . I expect it is likely to be followed up with a Pull Request later on - at which point we will review and discuss the implementation details.
 
Cheers,
Ulrik
 
-----Original Message-----
From: [email protected] [mailto:[email protected]] On Behalf Of Jeong Han Lee
Sent: 15 February 2016 22:31
To: Mark Rivers; [email protected]
Cc: Jeong Han Lee
Subject: Re: Guide needed in order to work with the EPICS related Git repositories
 
Hi Mark,
 
   Thank you for your workflow. It is the exactly what I am looking for!
 
   And I should follow your comment in order to work with EPICS projects. Actually, I did them in one EPICS project without telling anyone what I would like to do, then I thought, I forgot to discuss this early with main developers and maintainers after I saw Ralph's comment.
 
   Thank you again, I will understand your workflow first, then, I should do it them again with the proper procedure.
 
 
   Thanks,
   Han
 
 
 
On 02/15/2016 10:27 PM, Mark Rivers wrote:
Hi Han,
 
I'm not sure exactly what you would like.  For the EPICS areaDetector
project there is a Github workflow guide here:
 
https://github.com/areaDetector/areaDetector/wiki/areaDetector-Git-Workflows
 
 It is probably always a good idea to talk to the main developers
early.  If you are doing a small patch then cloning and doing a pull
request back to the master branch is a typical workflow.  But if you
are doing some major change then the developer will probably want to
create a branch for you and other developers to work on, and then you
do pull requests back to that branch.
 
Mark
 
 
-----Original Message----- From: [email protected]
[mailto:[email protected]] On Behalf Of Jeong Han Lee
Sent: Monday, February 15, 2016 2:47 PM To: [email protected]
Subject: Guide needed in order to work with the EPICS related Git
repositories
 
Hi,
 
I would like to have a *nice* guide, which is always I could get in
here, in order to work with the EPICS related Git repositories at
github.com.
 
Is there any procedure which I should follow in order to do any pull
requests? Should it be better to talk plan to main developers or
maintainers before forking, doing pull requests, or both?
 
It looks like to add more features in some existent projects in near
future, but I don't have clear idea how to do this. Please guide me
to minimize any difficulties.
 
Thanks, Han
 
 



-- 
Bruce Hill
Member Technical Staff
SLAC National Accelerator Lab
2575 Sand Hill Road M/S 10
Menlo Park, CA  94025

 

-- 

This e-mail and any attachments may contain confidential, copyright and or privileged material, and are for the use of the intended addressee only. If you are not the intended addressee or an authorised recipient of the addressee please notify us of receipt by returning the e-mail and do not use, copy, retain, distribute or disclose the information in or attached to the e-mail.
Any opinions expressed within this e-mail are those of the individual and not necessarily of Diamond Light Source Ltd.
Diamond Light Source Ltd. cannot guarantee that this e-mail or any attachments are free from viruses and we cannot accept liability for any damage which you may sustain as a result of software viruses which may be transmitted in or with the message.
Diamond Light Source Limited (company no. 4375679). Registered in England and Wales with its registered office at Diamond House, Harwell Science and Innovation Campus, Didcot, Oxfordshire, OX11 0DE, United Kingdom
 


Replies:
Re: Guide needed in order to work with the EPICS related Git repositories Bruce Hill
References:
Guide needed in order to work with the EPICS related Git repositories Jeong Han Lee
RE: Guide needed in order to work with the EPICS related Git repositories Mark Rivers
Re: Guide needed in order to work with the EPICS related Git repositories Jeong Han Lee
RE: Guide needed in order to work with the EPICS related Git repositories ulrik.pedersen
Re: Guide needed in order to work with the EPICS related Git repositories Bruce Hill

Navigate by Date:
Prev: Re: Guide needed in order to work with the EPICS related Git repositories Bruce Hill
Next: RE: Cost effective solution for monitor a large number of temperatures w EPICS austen.rose
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  <20162017  2018  2019  2020  2021  2022  2023  2024 
Navigate by Thread:
Prev: Re: Guide needed in order to work with the EPICS related Git repositories Bruce Hill
Next: Re: Guide needed in order to work with the EPICS related Git repositories Bruce Hill
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  <20162017  2018  2019  2020  2021  2022  2023  2024 
ANJ, 15 Jul 2016 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·