I think you both mean the same thing :) Daniel, I guess you just meant closing the release to updates by group members? The original plan was April 21st - April 30th for testing. So assuming anyone who wanted to merge their code to the release have done so (original deadline was Sunday 21st), we may call it a release and start the testing phase till end of Month, only adding minor bug fixes from now.

On Fri, Apr 19, 2013 at 10:35 AM, Ben Webb ben@salilab.org wrote:

> On 4/19/13 10:29 AM, Daniel Russel wrote: > >> The only issue that is in the release milestone relates to the web pages. >> > > I would prefer to let the nightly build run first to make sure no horrible > problems have cropped up, then update master from that revision. Otherwise > it would seem that the release hasn't even been tested to compile > everywhere, which is less testing than the nightly builds themselves. > > Ben > -- > ben@salilab.org http://salilab.org/~ben/ > "It is a capital mistake to theorize before one has data." > - Sir Arthur Conan Doyle > > ______________________________**_________________ > IMP-dev mailing list > IMP-dev@salilab.org > https://salilab.org/mailman/**listinfo/imp-devhttps://salilab.org/mailman/listinfo/imp-dev >

On Apr 19, 2013, at 10:35 AM, Ben Webb ben@salilab.org wrote:

> On 4/19/13 10:29 AM, Daniel Russel wrote: >> The only issue that is in the release milestone relates to the web pages. > > I would prefer to let the nightly build run first to make sure no horrible problems have cropped up, then update master from that revision. Otherwise it would seem that the release hasn't even been tested to compile everywhere, which is less testing than the nightly builds themselves. Sure. I practice, I think that and what I am suggesting are identical (in that we will continue to patch the release and there will be plenty of lag between declaring a version the release and getting everything ready for people to take).

On Apr 19, 2013, at 2:06 PM, Yannick Spill yannick@salilab.org wrote:

> Le 19/04/13 20:18, Daniel Russel a écrit : >> On Apr 19, 2013, at 10:35 AM, Ben Webb ben@salilab.org wrote: >> >>> On 4/19/13 10:29 AM, Daniel Russel wrote: >>>> The only issue that is in the release milestone relates to the web pages. >>> I would prefer to let the nightly build run first to make sure no horrible problems have cropped up, then update master from that revision. Otherwise it would seem that the release hasn't even been tested to compile everywhere, which is less testing than the nightly builds themselves. >> Sure. I practice, I think that and what I am suggesting are identical (in that we will continue to patch the release and there will be plenty of lag between declaring a version the release and getting everything ready for people to take). >> > If by release you mean a release branch (see first figure of http://nvie.com/posts/a-successful-git-branching-model/), which implies to freeze functionality and only correct warnings and bugs, I agree. There are still warnings in the isd module so I would like to get rid of them before we commit everything to master. The original plan, from what I recall, had been to release today, but we can slip a bit :-) I don't see much reason to wait for things like warning suppressions are quite reasonable to patch into the master afterwards anyway and there are an infinite number of such changes that we want to make.

> > Just to be sure: we *are* following the git-flow model as described in this link, are we? With feature branches, release, hotfix, and develop and master, right? At least for feature branches. I haven't end up using git flow release for the release so far because it didn't play well with having an svn repository and, since we are feeling things out a bit, I wanted to get a reasonable IMP state into the master branch sooner rather than at the end. I don't have much experience with hotfixes yet, so we shall see about those. They require that you specify the version manually, which is a bit annoying, but being able to search by tags for point release versions might be nice.

On Apr 19, 2013, at 3:43 PM, Barak Raveh barak.raveh@gmail.com wrote:

> So now that the SVN may rest in peace, how about to make life simple, everybody will use the git flow diagram (either they use master or develop, either they are advanced developers or simple folks) - it would make life easier if everybody work along the same guidelines. You can't really use git flow if you are working off of master (since you shouldn't commit anything to master, so most of the git flow steps don't make sense).

And modules like isd2 don't fit in that model (due to permissions being per-repository).

And it isn't always worth the effort to make a another branch (fundamentally, your develop is a separate branch from the github develop, it is just that you configured git to easy move things between the two). Each extra branch is something you need to keep in sync, with main. And each extra step and decision to be made requires attention that is pulled from something else.

And with those exceptions, you pretty much end up at the page we have, I think, at least in terms of content.

> It is something like: whatever you do, clone and checkout a branch (develop or master), if you want to add your own code, just follow the diagram. If you just work on your own code, doesn't matter - just start a feature and commit locally (or publish and push once in a while if you like a backup)

It might make sense to push people towards using github forks for this model, but I haven't investigated those enough to understand how well they would work.

On Apr 20, 2013, at 2:29 AM, Yannick Spill yannick@salilab.org wrote:

> >>> So now that the SVN may rest in peace, how about to make life simple, everybody will use the git flow diagram (either they use master or develop, either they are advanced developers or simple folks) - it would make life easier if everybody work along the same guidelines. >> You can't really use git flow if you are working off of master (since you shouldn't commit anything to master, so most of the git flow steps don't make sense). >> >> And modules like isd2 don't fit in that model (due to permissions being per-repository). > I don't think that's a problem. What I mean, is that isd2 can't really be just a branch in the main IMP repo, since then it would be public. > >> The original plan, from what I recall, had been to release today, but we can slip a bit I don't see much reason to wait for things like warning suppressions are quite reasonable to patch into the master afterwards anyway and there are an infinite number of such changes that we want to make. >> And it isn't always worth the effort to make a another branch (fundamentally, your develop is a separate branch from the github develop, it is just that you configured git to easy move things between the two). Each extra branch is something you need to keep in sync, with main. And each extra step and decision to be made requires attention that is pulled from something else. > I think, similar to Barak, that we should just stick to the full git flow model. Let's just adopt something that is done and that has been proven to work, and on which we can hang onto. If later on (in a few weeks) we see that it's cumbersome, we can amend things a bit and simplify them. Let's not be too inventive at first since we just changed for git, which in itself is already a huge jump in the ocean. > And with those exceptions, you pretty much end up at the page we have, I think, at least in terms of content. Given that, for the most part, Ben and I are the only people who would do release/hotfix sorts of things, I don't see that it makes any practical difference. And since hotfixes have to have specified version numbers (from what I understand), they have to be managed in a fairly centralized manner anyway.

> > > >> It might make sense to push people towards using github forks for this model, but I haven't investigated those enough to understand how well they would work. > that involves clicking somewhere, right? Who uses a mouse these days?... :-)

wow! 6 levels of nested replies, good for us :) I copied your questions with my two cents of an answer. *Yannick: *okay, so now, concretely, if I want to make some tests for isd to behave better, what do I modify, and how? master or develop (since I don't see a release branch) ? branch or inline ? *Barak:* When changing tests, I work on develop, commit there and send a patch to Daniel / Ben by e-mail / github issue so he applies it into master (*"git format-patch <revision-before-yours> --stdout > PATCH.txt*"). You can also just work on master without committing anything, prepare the patch there ("*git diff HEAD > PATCH.txt*") and send to Daniel / Ben. But perhaps we should be just granted commit privileges to master ourselves too, assuming we only intend to check in such minor commits. No point in centralizing things that much.

On Sun, Apr 21, 2013 at 8:19 AM, Yannick Spill yannick@salilab.org wrote:

> > The original plan, from what I recall, had been to release today, but >>>> we can slip a bit I don't see much reason to wait for things like warning >>>> suppressions are quite reasonable to patch into the master afterwards >>>> anyway and there are an infinite number of such changes that we want to >>>> make. >>>> And it isn't always worth the effort to make a another branch >>>> (fundamentally, your develop is a separate branch from the github develop, >>>> it is just that you configured git to easy move things between the two). >>>> Each extra branch is something you need to keep in sync, with main. And >>>> each extra step and decision to be made requires attention that is pulled >>>> from something else. >>>> >>> I think, similar to Barak, that we should just stick to the full git >>> flow model. Let's just adopt something that is done and that has been >>> proven to work, and on which we can hang onto. If later on (in a few weeks) >>> we see that it's cumbersome, we can amend things a bit and simplify them. >>> Let's not be too inventive at first since we just changed for git, which in >>> itself is already a huge jump in the ocean. >>> And with those exceptions, you pretty much end up at the page we have, I >>> think, at least in terms of content. >>> >> Given that, for the most part, Ben and I are the only people who would do >> release/hotfix sorts of things, I don't see that it makes any practical >> difference. And since hotfixes have to have specified version numbers (from >> what I understand), they have to be managed in a fairly centralized manner >> anyway. >> >> >> >> okay, so now, concretely, if I want to make some tests for isd to behave > better, what do I modify, and how? master or develop (since I don't see a > release branch) ? branch or inline ? > > ______________________________**_________________ > IMP-dev mailing list > IMP-dev@salilab.org > https://salilab.org/mailman/**listinfo/imp-devhttps://salilab.org/mailman/listinfo/imp-dev >

some other comments... > The original plan, from what I recall, had been to release today, but we can slip a bit :-) I don't see much reason to wait for things like warning suppressions are quite reasonable to patch into the master afterwards anyway and there are an infinite number of such changes that we want to make. I think if we are to do a 2.0 release, let's try to have one without compile warnings. I mean: it's been so long anyway since the 1.0 we can afford to do something right and provide people with a clean compilation. So I'd put it in a release branch, work on the warnings, and then push it to master when it's ready.

> I don't have much experience with hotfixes yet, so we shall see about those. They require that you specify the version manually, which is a bit annoying, but being able to search by tags for point release versions might be nice. By the way, how do you want to do this naming? 2.0 for a major release 2.0.x++ for a hotfix 2.1 for the next release, in 6 months what do you think?

Le 20/04/13 17:19, Ben Webb a écrit : > On 4/20/13 2:36 AM, Yannick Spill wrote: >> I think if we are to do a 2.0 release, let's try to have one without >> compile warnings. > > I agree with Daniel that it could take forever to get to a release if > we insist on that. (If you really want to spend your time on cosmetic > cleanups before a release, the isd module examples don't work. The > typical user is much more likely to notice that than some random > compile warnings, which most people have been conditioned to ignore > anyway. Almost all of the test failures right now are in isd too, but > that's less important. But if I had to choose between fixing tests and > fixing compile warnings, I'd fix tests, since those are what should be > telling you if you screwed up something when you tried to fix the > compile warnings!) > hmm. okay. that sounds incriminating for IMP.isd. >> By the way, how do you want to do this naming? >> 2.0 for a major release >> 2.0.x++ for a hotfix >> 2.1 for the next release, in 6 months >> what do you think? > > I thought we'd already agreed on exactly that, but if not, that sounds > reasonable. ;) > remember I only talk to you guys per email :)

> Ben