From: Kirk, B. (JSC-EG311) <ben...@na...> - 2012-12-11 00:04:47
|
libMesh users & developers: Effective immediately, we are moving our development source tree to GitHub. https://github.com/libMesh/libmesh You can check out the current source tree via $ git clone https://github.com/libMesh/libmesh.git Future file releases will occur through the GitHub files mechanism, and we will be moving all forum and tickets to their interface as well. The libMesh sourceforge website and mailing lists will be maintained for the foreseeable future. Due to some unexpected technical difficulties, this move was more sudden than we anticipated. As such, the installation documentation is in the process of being updated to reflect new best practices - I will follow up with more details shortly, but wanted to let everyone know that as of now the libMesh development trunk is moving! Thanks, -libMesh developers |
From: Paul T. B. <ptb...@gm...> - 2012-12-11 00:12:29
|
Replying to devel only. On Mon, Dec 10, 2012 at 6:04 PM, Kirk, Benjamin (JSC-EG311) < ben...@na...> wrote: > > > Future file releases will occur through the GitHub files mechanism, and we > will be moving all forum and tickets to their interface as well. > Is this "permanent" - i.e. there's no planned change to move from GitHub to something else? In particular, I've been waiting to see where it will end up because I want to start using (and promote the use of) the ticketing system both to help me remember what I need to do, but also to see what else is needing to be done. Would also give a place for would be developers to start. Right now, it seems to be only maintained in the developers' heads. Best, Paul |
From: Kirk, B. (JSC-EG311) <ben...@na...> - 2012-12-11 00:18:14
|
On Dec 10, 2012, at 6:12 PM, "Paul T. Bauman" <ptb...@gm...> wrote: > Would also give a place for would be developers to start. Right now, it seems to be only maintained in the developers' heads. Permanent, at least for the next 9 years until something better comes along. ;-) I've just closed the one ticket there and created a v0.9.0 milestone, under which I plan to start adding tickets, so feel free to add what you will. I've got some learning to do insofar as linking commits to tickets ala redmine, but gotta start somewhere! -Ben |
From: John P. <pet...@cf...> - 2012-12-11 21:22:24
|
On Mon, Dec 10, 2012 at 5:04 PM, Kirk, Benjamin (JSC-EG311) <ben...@na...> wrote: > libMesh users & developers: > > Effective immediately, we are moving our development source tree to GitHub. > > https://github.com/libMesh/libmesh > > You can check out the current source tree via > > $ git clone https://github.com/libMesh/libmesh.git > > Future file releases will occur through the GitHub files mechanism, and we will be moving all forum and tickets to their interface as well. > > The libMesh sourceforge website and mailing lists will be maintained for the foreseeable future. > > Due to some unexpected technical difficulties, this move was more sudden than we anticipated. As such, the installation documentation is in the process of being updated to reflect new best practices - I will follow up with more details shortly, but wanted to let everyone know that as of now the libMesh development trunk is moving! Before things get super-crazy with git, I thought I'd comment on what a developer's workflow (with write access) can be. (Note that this is not the *only* way to work with git, but it will maintain a linear history, which is similar to SVN, and is recommended by our local git guru David Andrs.) The following assumes that you are already using branches for your work, and not working directly in master. To create a branch, you can do "git co -b branch_name" and start making commits to it. Then the work flow is as follows: 1.) <finish work on branch_name> 2.) git co master 3.) git fetch 4.) git merge origin/master 5.) git co branch_name 6.) git rebase master 7.) git co master 8.) git merge branch_name 9.) git push Notes: .) Steps 2-4 pull down the most recent changes from github, and merge them onto your local master branch. Steps 3 and 4 can be combined into one command, 'git pull' .) Steps 5-6 "rebase" your patches on top of the most recent changes from github. At this point you can end up with conflicts you'll need to resolve. (See techniques for resolving conflicts, and 'git rebase --continue'.) On the other hand, if nothing new was pulled down in steps 2-4, there will be no work to do. .) Steps 7-9 merge the changes from your branch back into the main line and finally push them all back to github. The next time someone does a 'fetch', they'll pull down these changes... -- John |
From: Paul T. B. <ptb...@gm...> - 2012-12-11 21:37:24
|
On Tue, Dec 11, 2012 at 3:21 PM, John Peterson < pet...@cf...> wrote: > > Before things get super-crazy with git, I thought I'd comment on what > a developer's workflow (with write access) can be. > > (Note that this is not the *only* way to work with git, but it will > maintain a linear history, which is similar to SVN, and is recommended > by our local git guru David Andrs.) > > The following assumes that you are already using branches for your > work, and not working directly in master. > > To create a branch, you can do "git co -b branch_name" and start > making commits to it. > > Then the work flow is as follows: > > 1.) <finish work on branch_name> > 2.) git co master > 3.) git fetch > 4.) git merge origin/master > 5.) git co branch_name > 6.) git rebase master > 7.) git co master > 8.) git merge branch_name > 9.) git push > > > Notes: > .) Steps 2-4 pull down the most recent changes from github, and merge > them onto your local master branch. Steps 3 and 4 can be combined > into one command, 'git pull' > > .) Steps 5-6 "rebase" your patches on top of the most recent changes > from github. At this point you can end up with conflicts you'll need > to resolve. (See techniques for resolving conflicts, and 'git rebase > --continue'.) On the other hand, if nothing new was pulled down in > steps 2-4, there will be no work to do. > > .) Steps 7-9 merge the changes from your branch back into the main > line and finally push them all back to github. The next time someone > does a 'fetch', they'll pull down these changes... > As a git noob - thanks very much. I think this will be very helpful for me. How does this workflow interact with "pull requests" (if at all)? I was wondering if it might be a good idea to have the commits to the libMesh master go through a pull request and have one of the "core" developers have a look before it gets committed (even if the committer is another developer). TIA, Paul |
From: Kirk, B. (JSC-EG311) <ben...@na...> - 2012-12-11 21:57:49
|
On Dec 11, 2012, at 3:37 PM, "Paul T. Bauman" <ptb...@gm...> wrote: >> >> .) Steps 7-9 merge the changes from your branch back into the main >> line and finally push them all back to github. The next time someone >> does a 'fetch', they'll pull down these changes... > > As a git noob - thanks very much. I think this will be very helpful for me. Thanks very much John. Any interest in updating http://libmesh.sourceforge.net/subversion.php to a git-equivalent? I'm also wondering if it is possible to have some untracked files in a branch - basically, I'd like to create a branch off of master but leave all the checked-in Makefile.in's out of the branch… -Ben |
From: John P. <pet...@cf...> - 2012-12-11 22:18:08
|
On Tue, Dec 11, 2012 at 2:57 PM, Kirk, Benjamin (JSC-EG311) <ben...@na...> wrote: > On Dec 11, 2012, at 3:37 PM, "Paul T. Bauman" <ptb...@gm...> wrote: > >>> >>> .) Steps 7-9 merge the changes from your branch back into the main >>> line and finally push them all back to github. The next time someone >>> does a 'fetch', they'll pull down these changes... >> >> As a git noob - thanks very much. I think this will be very helpful for me. > > Thanks very much John. > > Any interest in updating > > http://libmesh.sourceforge.net/subversion.php > > to a git-equivalent? Absolutely. Once I've nailed things down a bit more (we can probably do things in less than 9 steps with pull --rebase) I will document it. > I'm also wondering if it is possible to have some untracked files in a branch - basically, I'd like to create a branch off of master but leave all the checked-in Makefile.in's out of the branch… I believe that's just fine. Untracked files are just that... you can switch branches, merge, rebase etc. and they will just go along for the ride. -- John |
From: John P. <pet...@cf...> - 2012-12-11 22:20:41
|
On Tue, Dec 11, 2012 at 2:37 PM, Paul T. Bauman <ptb...@gm...> wrote: > On Tue, Dec 11, 2012 at 3:21 PM, John Peterson > <pet...@cf...> wrote: >> > > As a git noob - thanks very much. I think this will be very helpful for me. > > How does this workflow interact with "pull requests" (if at all)? I was > wondering if it might be a good idea to have the commits to the libMesh > master go through a pull request and have one of the "core" developers have > a look before it gets committed (even if the committer is another > developer). TIA, So, as I understand it, a pull request would come from someone else (Joe, say) who has a github account but does not have write access to the libmesh repo. It would be in the form of a URL and a branch name to pull. When you receive the request, you could (haven't tried this) git co -b joes_branch git pull joes_url joes_branch At this point you are ready to do the steps 1-9 previously mentioned to incorporate Joe's branch into a linear history and push it into the repo if all is well. We are testing this now, and I'll let you know more details. -- John |
From: John P. <pet...@cf...> - 2012-12-11 22:37:11
|
On Tue, Dec 11, 2012 at 3:20 PM, John Peterson <pet...@cf...> wrote: > On Tue, Dec 11, 2012 at 2:37 PM, Paul T. Bauman <ptb...@gm...> wrote: >> On Tue, Dec 11, 2012 at 3:21 PM, John Peterson >> <pet...@cf...> wrote: >>> >> >> As a git noob - thanks very much. I think this will be very helpful for me. >> >> How does this workflow interact with "pull requests" (if at all)? I was >> wondering if it might be a good idea to have the commits to the libMesh >> master go through a pull request and have one of the "core" developers have >> a look before it gets committed (even if the committer is another >> developer). TIA, > > So, as I understand it, a pull request would come from someone else > (Joe, say) who has a github account but does not have write access to > the libmesh repo. > > It would be in the form of a URL and a branch name to pull. > > When you receive the request, you could (haven't tried this) > > git co -b joes_branch > git pull joes_url joes_branch > > At this point you are ready to do the steps 1-9 previously mentioned > to incorporate Joe's branch into a linear history and push it into the > repo if all is well. > > We are testing this now, and I'll let you know more details. Yep, that seems to work just fine. All the maintainers should have gotten an email notifying them of the pull request? Note: If you follow the instructions in the email you get from the pull request, you will pull the changes directly in to whatever branch you are currently working on, so it might be best to check out a new branch just for the purpose of dealing with the pull request (as mentioned above) first. -- John |
From: John P. <pet...@cf...> - 2012-12-11 23:10:49
|
On Tue, Dec 11, 2012 at 2:21 PM, John Peterson <pet...@cf...> wrote: > On Mon, Dec 10, 2012 at 5:04 PM, Kirk, Benjamin (JSC-EG311) > <ben...@na...> wrote: >> libMesh users & developers: >> > Then the work flow is as follows: > > 1.) <finish work on branch_name> > 2.) git co master > 3.) git fetch > 4.) git merge origin/master > 5.) git co branch_name > 6.) git rebase master > 7.) git co master > 8.) git merge branch_name > 9.) git push As you might have hoped, this process can be simplified somewhat! Let's say you have made some commits on a branch named branch_name, it's currently checked out, and you want to pull down the most recent changes from github (similar to an svn up). You'd then just do git pull --rebase I should note that this is slightly dangerous. It can fail if there are any conflicts, and I don't have enough experience to describe the process of fixing those and continuing on (but I will test that now). So the workflow above becomes: 1.) <finish work on branch_name> 2.) git pull --rebase 3.) git co master 4.) git merge branch_name 5.) git push -- John |
From: John P. <pet...@cf...> - 2012-12-11 23:51:03
|
By the way, you may also want to put the following in your ~/.gitconfig file. It sets us some nice color coding for looking at logs and sets up a few two letter abbreviations that are handy. [user] name = Your Name email = you...@yo... [color] diff = auto status = auto branch = auto interactive = auto ui = true pager = true [alias] co = checkout di = diff st = status ci = commit stat = status br = branch lg = log --stat -- John |
From: John P. <pet...@cf...> - 2012-12-13 17:11:39
|
On Tue, Dec 11, 2012 at 4:10 PM, John Peterson <pet...@cf...> wrote: This workflow is correct, but it isn't complete... > 1.) <finish work on branch_name> > 2.) git pull --rebase > 3.) git co master > 4.) git merge branch_name > 5.) git push In order for the pull --rebase request to work properly, you have to create the branch with the proper tracking in the first place. Hence, please also add a step zero: 0.) git co --track -b branch_name origin/master -- John |
From: John P. <pet...@cf...> - 2012-12-12 00:15:23
|
On Tue, Dec 11, 2012 at 4:10 PM, John Peterson <pet...@cf...> wrote: > On Tue, Dec 11, 2012 at 2:21 PM, John Peterson > <pet...@cf...> wrote: >> On Mon, Dec 10, 2012 at 5:04 PM, Kirk, Benjamin (JSC-EG311) >> <ben...@na...> wrote: >>> libMesh users & developers: >>> >> Then the work flow is as follows: >> >> 1.) <finish work on branch_name> >> 2.) git co master >> 3.) git fetch >> 4.) git merge origin/master >> 5.) git co branch_name >> 6.) git rebase master >> 7.) git co master >> 8.) git merge branch_name >> 9.) git push > > As you might have hoped, this process can be simplified somewhat! > > Let's say you have made some commits on a branch named branch_name, > it's currently checked out, and you want to pull down the most recent > changes from github (similar to an svn up). > > You'd then just do > > git pull --rebase > > I should note that this is slightly dangerous. It can fail if there > are any conflicts, and I don't have enough experience to describe the > process of fixing those and continuing on (but I will test that now). So the process for resolving conflicts during pull --rebase is exactly the same as it is during a normal rebase. I'll discuss the steps below if you want to play along at home: 1.) Generate a conflict on purpose: branch from the commit just prior to the current HEAD, and on the new branch, create a commit that deliberately conflicts with the most recent commit in master: a.) git co master b.) git co <previous hash> c.) git co -b test_branch d.) git co test_branch e.) <make commit which conflicts with most recent on master> f.) git pull --rebase https://github.com/libMesh/libmesh.git master You should get something like the following error message: > From https://github.com/libMesh/libmesh > * branch master -> FETCH_HEAD > First, rewinding head to replay your work on top of it... > Applying: Generate deliberate conflict before git pull --rebase. > Using index info to reconstruct a base tree... > Falling back to patching base and 3-way merge... > Auto-merging README > CONFLICT (content): Merge conflict in README > Failed to merge in the changes. > Patch failed at 0001 Generate deliberate conflict before git pull --rebase. > > When you have resolved this problem run "git rebase --continue". > If you would prefer to skip this patch, instead run "git rebase --skip". > To check out the original branch and stop rebasing run "git rebase --abort". > > ((64556fb...)|REBASE)$ In particular, note my prompt has been changed to tell me the current hash and to let me know that I'm in the midst of a rebase. You can do this by sourcing the git completion and prompt files https://raw.github.com/git/git/master/contrib/completion/git-completion.bash https://raw.github.com/git/git/master/contrib/completion/git-prompt.sh in your .bash_profile, and following the instructions therein. 2.) Run git status to see more about the nature of the problem ((64556fb...)|REBASE)$ git st > # Not currently on any branch. > # Unmerged paths: > # (use "git reset HEAD <file>..." to unstage) > # (use "git add/rm <file>..." as appropriate to mark resolution) > # > # both modified: README 3.) So it tells us that both commits modified the README file! Let's resolve the conflict. Open up README in a text editor, the conflicts look the same way they did in SVN. In one commit (the one from github) there is a blank line, while in my local branch I put 'aaa' on that same line, hence the conflict. <<<<<<< HEAD ======= aaa >>>>>>> Generate deliberate conflict before git pull --rebase. 4.) Resolve the conflict by going with the version from HEAD (manually deleting the conflict markers.) 5.) Now, re-add the file (don't forget this step!!) ((64556fb...)|REBASE)$ git add README 6.) Continue the rebasing ((64556fb...)|REBASE)$ git rebase --continue In this particular case, we get another error: > Applying: Generate deliberate conflict before git pull --rebase. > No changes - did you forget to use 'git add'? > If there is nothing left to stage, chances are that something else > already introduced the same changes; you might want to skip this patch. > > When you have resolved this problem run "git rebase --continue". > If you would prefer to skip this patch, instead run "git rebase --skip". > To check out the original branch and stop rebasing run "git rebase --abort". Oops, yes, git is correct. After resolving the conflict, our patch is now empty, so we should skip it! 7.) ((64556fb...)|REBASE)$ git rebase --skip At this point your prompt should be back to normal. If you have multiple conflicts, you will deal with them one at a time in the same manner. If you get too confused, you can always back out of the whole process with 'git rebase --abort'. -- John |
From: Kirk, B. (JSC-EG311) <ben...@na...> - 2012-12-12 02:24:45
|
On Dec 11, 2012, at 6:14 PM, John Peterson <pet...@cf...> wrote: > So the process for resolving conflicts during pull --rebase is exactly > the same as it is during a normal rebase. I'll discuss the steps > below if you want to play along at home: thanks John. WRT this: > Yep, that seems to work just fine. All the maintainers should have > gotten an email notifying them of the pull request? Did anyone? I did not, and it looks like I am set up to get GitHub email notifications. Hmm… So… your preferred workflow is to do all development on a branch that is then periodically synced to master? Does that branch ever live at the GitHub level or is it just in your own filesystem working copy? The reason I'm asking is because I will definitely want access across different filesystems to 'in progress' features. And if they don't live at the libMesh/libmesh.git level, I'm thinking the preferred path is for developers to fork the central repo if they need network access to in-progress branches - along the lines of this: http://git-scm.com/book/en/Distributed-Git-Distributed-Workflows#Integration-Manager-Workflow -Ben |
From: John P. <pet...@cf...> - 2012-12-12 05:11:14
|
On Tue, Dec 11, 2012 at 7:24 PM, Kirk, Benjamin (JSC-EG311) <ben...@na...> wrote: > On Dec 11, 2012, at 6:14 PM, John Peterson <pet...@cf...> wrote: > >> So the process for resolving conflicts during pull --rebase is exactly >> the same as it is during a normal rebase. I'll discuss the steps >> below if you want to play along at home: > > thanks John. > > WRT this: > >> Yep, that seems to work just fine. All the maintainers should have >> gotten an email notifying them of the pull request? > > Did anyone? I did not, and it looks like I am set up to get GitHub email notifications. Hmm… Roy mentioned he did not receive anything either. So, you might want to check that you have a verified email on file with github. I actually just clicked through and verified mine the other day. > So… your preferred workflow is to do all development on a branch that is then periodically synced to master? > > Does that branch ever live at the GitHub level or is it just in your own filesystem working copy? It should definitely be on github if you want to easily share with yourself and others... gives you the ability to have others pull your code and check it out without emailing around patches. I haven't taken advantage of this myself since I haven't used github before (and you probably don't want to put export controlled software on github!). > The reason I'm asking is because I will definitely want access across different filesystems to 'in progress' features. And if they don't live at the libMesh/libmesh.git level, I'm thinking the preferred path is for developers to fork the central repo if they need network access to in-progress branches - along the lines of this: > > http://git-scm.com/book/en/Distributed-Git-Distributed-Workflows#Integration-Manager-Workflow Right, I think anyone who wants to do libmesh development can fork the repo and create as many branches as they want on github. Then if they have a feature they'd like others to try they can just send a pull request. -- John |
From: Roy S. <roy...@ic...> - 2012-12-12 04:53:36
|
On Tue, 11 Dec 2012, Kirk, Benjamin (JSC-EG311) wrote: > http://git-scm.com/book/en/Distributed-Git-Distributed-Workflows#Integration-Manager-Workflow Who volunteers to be integration manager? If it's not the most prolific developer then they're not going to be able to keep up (I'm recalling the FIN-S branches/kitchen-sink situation here); but the identity of "the most prolific developer" has probably swapped between three or four different people back and forth a dozen times over the years. I was picturing something not too far off from the centralized development model, but with one added step: the distinction between a Testing and Master branch. Developers can commit any change sets between Master and their private branch that pass a --enable-everything "make check" to Testing. Any newer-than-Master version of Testing that passes the continuous integration tests can (and should) be synched by any developer (or by buildbot itself eventually) to Master. Any newer-than-Master version of Testing that fails the continuous integration tests can be either: A) given another patch designed specifically to fix the failed tests, B) reverted to any other newer-than-Master revision that hasn't been tested (in cases where multiple patches were added too fast for buildbot to test) C) reverted completely by a developer who can't fix someone else's breakage but wants to then test his own new patch. Thoughts? --- Roy |
From: Kirk, B. (JSC-EG311) <ben...@na...> - 2012-12-12 12:26:07
|
On Dec 11, 2012, at 10:53 PM, "Roy Stogner" <roy...@ic...> wrote: > A) given another patch designed specifically to fix the failed tests, > B) reverted to any other newer-than-Master revision that hasn't been > tested (in cases where multiple patches were added too fast for > buildbot to test) > C) reverted completely by a developer who can't fix someone else's > breakage but wants to then test his own new patch. I really like that approach for the core development team that has write access to the repository. I was going to suggest we have a 'stable' which tracks 'master', but the same idea.. A nice thing about either approach is that the blessed branch could contain all the generated automake files, and we could keep those out of the daily (or hourly!) churn branch. Rebasing would cause no conflicts wrt generated files that lived only on the derived branch, AFAICT. Would that be an acceptable compromise? -Ben |
From: John P. <pet...@cf...> - 2012-12-12 15:28:38
|
On Tue, Dec 11, 2012 at 9:53 PM, Roy Stogner <roy...@ic...> wrote: > > On Tue, 11 Dec 2012, Kirk, Benjamin (JSC-EG311) wrote: > >> >> http://git-scm.com/book/en/Distributed-Git-Distributed-Workflows#Integration-Manager-Workflow > > > Who volunteers to be integration manager? If it's not the most > prolific developer then they're not going to be able to keep up (I'm > recalling the FIN-S branches/kitchen-sink situation here); but the > identity of "the most prolific developer" has probably swapped between > three or four different people back and forth a dozen times over the > years. > > I was picturing something not too far off from the centralized > development model, but with one added step: the distinction between a > Testing and Master branch. Developers can commit any change sets > between Master and their private branch that pass a > --enable-everything "make check" to Testing. Any newer-than-Master > version of Testing that passes the continuous integration tests can > (and should) be synched by any developer (or by buildbot itself > eventually) to Master. Any newer-than-Master version of Testing that > fails the continuous integration tests can be either: A) given another patch > designed specifically to fix the failed tests, > B) reverted to any other newer-than-Master revision that hasn't been > tested (in cases where multiple patches were added too fast for > buildbot to test) > C) reverted completely by a developer who can't fix someone else's > breakage but wants to then test his own new patch. > > Thoughts? My first thought was extreme confusion... But then I read a bit more and decided I was only moderately confused by the A, B, and C options :-/ I'm willing to work with any development process that develops organically, but to start with I'd suggest we have just 1 branch, similar to what we did with SVN. As people become more comfortable with using git and handling pull requests (btw, I just received one from a random developer this morning, did anyone else?) we might eventually go to two branches: "stable" and "development". The development branch can be periodically merged into stable, perhaps automatically by buildbot whenever tests pass. So core developers would primarily work with the development branch, and users who lie somewhere between "core developer" and "downloader of release tarballs" would use the stable branch. -- John |
From: Kirk, B. (JSC-EG311) <ben...@na...> - 2012-12-12 16:32:16
|
On Dec 12, 2012, at 9:28 AM, John Peterson <pet...@cf...> wrote: > The development branch can be periodically merged into stable, perhaps > automatically by buildbot whenever tests pass. > > So core developers would primarily work with the development branch, > and users who lie somewhere between "core developer" and "downloader > of release tarballs" would use the stable branch. I like that model, at least as a point of departure. Would there be consensus then in (1) treating 'master' as the place for stable code, along the lines of Roy's suggestion, (2) creating 'devel' where the core developers live. Follow a nearly-centralized model (for now anyway as we wean from subversion), where anyone can push anything that compiles and passes 'make check' into devel. Most libMesh CI instances would follow devel, to help spot things like compiler compatibility, PETSc backwards compatibility, etc… before syncing to master, and (3) again, per Roy's suggestion, any of the core developers (or buildbot) can sync devel to master whenever it is sufficiently mature and tested. The only additional thing I'd push for is that automatically generated files live only in master. Any core developer working on devel should be sufficiently proficient to make sure they have the autotools and can bootstrap. In this way there is no need to everyone to have identical autotools versions when working on devel, or living with the dreaded -# Makefile.in generated by automake 1.12.4 from Makefile.am. +# Makefile.in generated by automake 1.12.5 from Makefile.am. noise. Whenever someone merges devel back to master they are responsible for updating the generated files with that commit, but there should be no conflicts. If we can converge on this I'll create a 'devel' branch off master and we can start trying this out... -Ben |
From: Roy S. <roy...@ic...> - 2012-12-12 17:04:54
|
On Wed, 12 Dec 2012, Kirk, Benjamin (JSC-EG311) wrote: > (1) treating 'master' as the place for stable code, along the lines of Roy's suggestion, > (2) creating 'devel' where the core developers live. My concern here is that then the core developers don't get the main benefit of the "devel"->"master" split. If you're updating your personal branch (or your personal checkout, to start) from devel, then you're going to get every insufficiently-tested patch from everyone else. Whereas if you pull from master and push to devel, you can be more certain that any breakage in your own sandbox isn't someone else's fault. The only trouble with pulling from master and pushing to devel is the "two people committed to devel before either single patch could be tested and pushed to master, and it broke" case, which is what I was trying to sort out with my convoluted alphabetized list earlier. > The only additional thing I'd push for is that automatically > generated files live only in master. Any core developer working on > devel should be sufficiently proficient to make sure they have the > autotools and can bootstrap. In this way there is no need to > everyone to have identical autotools versions when working on devel, > or living with the dreaded > > -# Makefile.in generated by automake 1.12.4 from Makefile.am. > +# Makefile.in generated by automake 1.12.5 from Makefile.am. > > noise. This I'm going to need to think about. --- Roy |
From: John P. <pet...@cf...> - 2012-12-12 17:44:56
|
On Wed, Dec 12, 2012 at 9:32 AM, Kirk, Benjamin (JSC-EG311) <ben...@na...> wrote: > On Dec 12, 2012, at 9:28 AM, John Peterson <pet...@cf...> wrote: > >> The development branch can be periodically merged into stable, perhaps >> automatically by buildbot whenever tests pass. >> >> So core developers would primarily work with the development branch, >> and users who lie somewhere between "core developer" and "downloader >> of release tarballs" would use the stable branch. > > I like that model, at least as a point of departure. > > Would there be consensus then in > > (1) treating 'master' as the place for stable code, along the lines of Roy's suggestion, > (2) creating 'devel' where the core developers live. Follow a nearly-centralized model (for now anyway as we wean from subversion), where anyone can push anything that compiles and passes 'make check' into devel. Most libMesh CI instances would follow devel, to help spot things like compiler compatibility, PETSc backwards compatibility, etc… before syncing to master, and > (3) again, per Roy's suggestion, any of the core developers (or buildbot) can sync devel to master whenever it is sufficiently mature and tested. Sounds fine. > The only additional thing I'd push for is that automatically generated files live only in master. I don't know if this is possible in exactly the way you state it. I'm picturing devel as a (remote) branch off of master that periodically gets merged back in to master. Since the Makefile.in's already exist in master, they will also exist in the "devel" branch which is created from it. Hence if you modify the Makefile.in's on devel (through running bootstrap) they'll show up as files with local modifications (not untracked files). You can't rebase or checkout different branches if you have local modifications... you have to deal with them somehow. One way is to temporarily 'git commit' the files, switch branches, rebase, etc., and then 'git reset HEAD~1' to undo your temporary commit. It'll be up to you, as you mentioned, to determine when they really have changed in a non-trivial way and need to be updated (actually pushed to devel). -- John |
From: Derek G. <fri...@gm...> - 2012-12-12 17:06:22
|
I am not against this model... (it is VERY close to how we do things with MOOSE... and our "stable merge" is automated by Bitten) however, can we have a small "cooling off" period for a moment while everyone gets up to date with using the new build system and pulling from Git? MOOSE still doesn't even work with the new build system yet (John is getting close). At the very least, I don't think we should move to a separate branch from master with "stable merging" until we have a public BuildBot up and running that is tracking libMesh development. I would rather not have individuals making decisions about when to merge to stable without being backed by some automated system telling them that the current stuff is good. Let's just move to Git and work in master for a little while and let everyone catch their breath... Derek On Wed, Dec 12, 2012 at 9:32 AM, Kirk, Benjamin (JSC-EG311) < ben...@na...> wrote: > Would there be consensus then in > > (1) treating 'master' as the place for stable code, along the lines of > Roy's suggestion, > (2) creating 'devel' where the core developers live. Follow a > nearly-centralized model (for now anyway as we wean from subversion), where > anyone can push anything that compiles and passes 'make check' into devel. > Most libMesh CI instances would follow devel, to help spot things like > compiler compatibility, PETSc backwards compatibility, etc… before syncing > to master, and > (3) again, per Roy's suggestion, any of the core developers (or buildbot) > can sync devel to master whenever it is sufficiently mature and tested. > > The only additional thing I'd push for is that automatically generated > files live only in master. Any core developer working on devel should be > sufficiently proficient to make sure they have the autotools and can > bootstrap. In this way there is no need to everyone to have identical > autotools versions when working on devel, or living with the dreaded > > -# Makefile.in generated by automake 1.12.4 from Makefile.am. > +# Makefile.in generated by automake 1.12.5 from Makefile.am. > > noise. > > Whenever someone merges devel back to master they are responsible for > updating the generated files with that commit, but there should be no > conflicts. > > If we can converge on this I'll create a 'devel' branch off master and we > can start trying this out... > > -Ben > > > > ------------------------------------------------------------------------------ > LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial > Remotely access PCs and mobile devices and provide instant support > Improve your efficiency, and focus on delivering more value-add services > Discover what IT Professionals Know. Rescue delivers > http://p.sf.net/sfu/logmein_12329d2d > _______________________________________________ > Libmesh-devel mailing list > Lib...@li... > https://lists.sourceforge.net/lists/listinfo/libmesh-devel > |
From: Roy S. <roy...@ic...> - 2012-12-12 17:17:28
|
On Wed, 12 Dec 2012, Derek Gaston wrote: > I am not against this model... (it is VERY close to how we do things > with MOOSE... and our "stable merge" is automated by Bitten) > however, can we have a small "cooling off" period for a moment while > everyone gets up to date with using the new build system and pulling > from Git? I think John already made this point, and I didn't respond then, but I agree completely. I'm still figuring out the subtle differences between "git pull" and "svn update" and I have no desire to jump ahead to more sophisticated development workflows this month, despite my excitement when talking about it. > At the very least, I don't think we should move to a separate branch > from master with "stable merging" until we have a public BuildBot up > and running that is tracking libMesh development. The PECOS CI server actually is publicly accessible. It's so hammered right now that I'd rather not subject its interface to even more usage until we get some new hardware going, but email me privately if you want the URL to peek at occasionally. --- Roy |
From: Kirk, B. (JSC-EG311) <ben...@na...> - 2012-12-12 17:24:40
|
On Dec 12, 2012, at 11:17 AM, Roy Stogner <roy...@ic...> wrote: > On Wed, 12 Dec 2012, Derek Gaston wrote: > >> I am not against this model... (it is VERY close to how we do things >> with MOOSE... and our "stable merge" is automated by Bitten) >> however, can we have a small "cooling off" period for a moment while >> everyone gets up to date with using the new build system and pulling >> from Git? > > I think John already made this point, and I didn't respond then, but I > agree completely. I'm still figuring out the subtle differences > between "git pull" and "svn update" and I have no desire to jump ahead > to more sophisticated development workflows this month, despite my > excitement when talking about it. My only urgency is that we have some minimal documentation & discussion to guide us - not that we define some Byzantine process with which to intimidate strangers and ridicule friends. What was supposed to be a very deliberate move was hastened by the Allura svn import fiasco, so I feel a little guilty about pushing this faster than I intended. >> At the very least, I don't think we should move to a separate branch >> from master with "stable merging" until we have a public BuildBot up >> and running that is tracking libMesh development. Understood, so then for the foreseeable future 'master' will continue to be at least my sandbox (to the same extent trunk was as of last week) - which seemed to be maybe what sparked the best practices discussion in the first place? -Ben |
From: Derek G. <fri...@gm...> - 2012-12-12 17:27:30
|
On Wed, Dec 12, 2012 at 10:17 AM, Roy Stogner <roy...@ic...>wrote: > The PECOS CI server actually is publicly accessible. It's so hammered > right now that I'd rather not subject its interface to even more usage > until we get some new hardware going, but email me privately if you > want the URL to peek at occasionally. > Sounds good. Is there any way we could run a build bot "slave" (I don't know the BuildBot parlance) here at INL that would report our test status back to your Build Bot server? If so, we could definitely set that up. Also, I have some libMesh changes that I'm going to be making today, so I was thinking about my Git workflow a little bit. I think even _I_ am going to clone the libMesh Git repo on GitHub over into my own workspace and work on my own changes there and then submit a pull request when those changes are ready. "Submit a pull request" is essentially akin to emailing a patch so others can ok your work. Now, if I submit a pull request and everyone is ok with it... I can do my own pull into the officially libMesh git clone on my workstation and merge to master and push on my own. I just like the idea of ok'ing my patches with a pull request first. For small things, I might not do that (just little bug fixes) but for anything adding or changing API I think it might be a good idea. Note though, that this is a personal decision that I don't expect everyone to follow. What do you guys think? Derek |