> I recommend that you stick with the release_19 branch of both llvm and > llvm-poolalloc. I and others are actively using these branches, so > llvm-poolalloc bug fixes will most likely be made to this branch in > addition to mainline CVS for the forseeable future. The release_19 > branch of llvm-poolalloc is designed to always work with the release_19 > branch of LLVM, which has a fixed API and bytecode format.I did not realize that you guys were checking in changes to the release_19 branch. I have to disagree with this as release_19 is supposed to match the release 1.9 that we have on our website. This release has been tested on all platforms (that we support) and by changing the files in CVS I can no longer guarantee that same level of quality if someone checks out release_19. We do allow and suggest that people check out the release_19 from CVS (in the Getting Started Guide) so they should be getting the same files as in the tar. I would suggest creating your own branch if you do not plan to keep up with mainline cvs. In the future, I would hope that you would talk to me (the Release Manager) or email the list about changes to the policy regarding the release branches. -Tanya
Tanya M. Lattner wrote:>>I recommend that you stick with the release_19 branch of both llvm and >>llvm-poolalloc. I and others are actively using these branches, so >>llvm-poolalloc bug fixes will most likely be made to this branch in >>addition to mainline CVS for the forseeable future. The release_19 >>branch of llvm-poolalloc is designed to always work with the release_19 >>branch of LLVM, which has a fixed API and bytecode format. >> >> > >I did not realize that you guys were checking in changes to the release_19 >branch. I have to disagree with this as release_19 is supposed to match >the release 1.9 that we have on our website. This release has been tested >on all platforms (that we support) and by changing the files in CVS I can >no longer guarantee that same level of quality if someone checks out >release_19. We do allow and suggest that people check out the release_19 >from CVS (in the Getting Started Guide) so they should be getting the same >files as in the tar. > >I don't believe I've changed any policy that we've had (at least, not significantly), and I think you may misunderstand what I am changing and where I'm making the changes. Here's my explanation of what I did: 1) According to the policy I set forth when I did release management, there is a difference between RELEASE_19 and release_19. RELEASE_19 is a tag that denotes what we released in LLVM 1.9; it should never change. The release_19 tag is a branch tag that denotes the branch for the 1.9.x releases. To date, we've only created one release per release branch, but we should be able to make subsequent releases on the branch (e.g. 1.9.1, 1.9.2, etc) if we want. The purpose of this policy was to ensure that we could make bug fixes to multiple LLVM releases should the need arise. 2) I marked RELEASE_19 before changing anything in the release_19 branch of llvm (you never tagged RELEASE_19). Assuming no one else modified anything in the release_19 branch, RELEASE_19 represents what is in the LLVM 1.9 tarball. 3) The only changes in the llvm release_19 branch is the removal of DSA and (maybe) some minor autoconf changes. I did this to ease merges on DSA between the release_19 branch and mainline of the llvm-poolalloc CVS module. 4) The only new development I've been doing is in the release_19 branch of the llvm-poolalloc and safecode CVS modules. llvm-poolalloc is, as far as I can tell, not part of the LLVM releases, and safecode is still an internal project, so I don't think I've broken any of our release policies by creating and developing in the release_19 branches for these two CVS modules.>I would suggest creating your own branch if you do not plan to keep up >with mainline cvs. > >In the future, I would hope that you would talk to me (the Release >Manager) or email the list about changes to the policy regarding the >release branches. > >I don't think I've changed any policies of which I am aware. However, I do apologize for not asking you whether you had changed the policy when I noticed that the RELEASE_19 tag was missing; I probably should have asked you first before fixing it. -- John T.>-Tanya > >_______________________________________________ >LLVM Developers mailing list >LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu >http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > >
On Feb 13, 2007, at 11:08 AM, John T. Criswell wrote:> there is a difference between RELEASE_19 and release_19.I have not tried, but I won't be surprised if CVS itself gets confused between this two on systems like Darwin which is case insensitive but case preserving. - Devang -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20070213/be7f6924/attachment.html>
On Tue, 13 Feb 2007, John T. Criswell wrote:>>> I recommend that you stick with the release_19 branch of both llvm and >>> llvm-poolalloc. I and others are actively using these branches, so >>> llvm-poolalloc bug fixes will most likely be made to this branch in >>> addition to mainline CVS for the forseeable future. The release_19 >>> branch of llvm-poolalloc is designed to always work with the release_19 >>> branch of LLVM, which has a fixed API and bytecode format.>> I did not realize that you guys were checking in changes to the release_19 >> branch. I have to disagree with this as release_19 is supposed to match >> the release 1.9 that we have on our website. This release has been tested> 1) According to the policy I set forth when I did release management, > there is a difference between RELEASE_19 and release_19. RELEASE_19 is > a tag that denotes what we released in LLVM 1.9; it should never > change. The release_19 tag is a branch tag that denotes the branch for > the 1.9.x releases. To date, we've only created one release per release > branch, but we should be able to make subsequent releases on the branch > (e.g. 1.9.1, 1.9.2, etc) if we want.I think the real problem here is that the current policy is either not documented, or is inadequately documented. Please pick a policy and stick with it, but describe it somewhere in the release guide or in the new 'Developer Policy' section. I think having a sub-release branch makes sense for dot releases.> 3) The only changes in the llvm release_19 branch is the removal of DSA > and (maybe) some minor autoconf changes. I did this to ease merges on > DSA between the release_19 branch and mainline of the llvm-poolalloc CVS > module.Regardless of the policy, I don't think this is acceptable. Your stated goal for the release_19 branch is for it to be a host for 1.9.1. Removing an entire library does not sound like a ".1" change. If you wanted to do this, having a separate branch would make sense, instead of taking over the 'release' branch. I don't care about correcting this for the 1.9 release, and I don't really think that overloading RELEASE_19 and release_19 is a good idea, but please work together and figure out a policy that makes sense. -Chris -- http://nondot.org/sabre/ http://llvm.org/
>> I did not realize that you guys were checking in changes to the release_19 >> branch. I have to disagree with this as release_19 is supposed to match >> the release 1.9 that we have on our website. This release has been tested >> on all platforms (that we support) and by changing the files in CVS I can >> no longer guarantee that same level of quality if someone checks out >> release_19. We do allow and suggest that people check out the release_19 >> from CVS (in the Getting Started Guide) so they should be getting the same >> files as in the tar. >> >> > > I don't believe I've changed any policy that we've had (at least, not > significantly), and I think you may misunderstand what I am changing and > where I'm making the changes.Ok. I think there are 2 issues here. First, I was not aware that I was to tag the release branch as it wasn't a part of the how to release LLVM document. So thats is my mistake. Since we had never done X.X.X releases (lets call them subreleases) it never became an issue. In the future, we may decide to do this, so you are right that it makes sense to tag the release branch and work from there. I think we need to figure out how we want to do this as RELEASE_19 may be a bit confusing since its the same as the release branch name. We should also discuss if we are branching off the branch for subreleases. Hopefully that made sense. Second, for the subreleases we should only be checking in critical patches. This is where it gets a bit tricky because we have no formal policy in place as to what is deemed critical because we have never had a need to do subreleases. I think it would be better if the pool-alloc team had a branch off the release branch to do your development. That way you can make any changes you wish and merge in any patches you wish without having to have them "formally" approved (whatever the LLVM team defines that to be). What do you think? -Tanya> > Here's my explanation of what I did: > > 1) According to the policy I set forth when I did release management, > there is a difference between RELEASE_19 and release_19. RELEASE_19 is > a tag that denotes what we released in LLVM 1.9; it should never > change. The release_19 tag is a branch tag that denotes the branch for > the 1.9.x releases. To date, we've only created one release per release > branch, but we should be able to make subsequent releases on the branch > (e.g. 1.9.1, 1.9.2, etc) if we want. > > The purpose of this policy was to ensure that we could make bug fixes to > multiple LLVM releases should the need arise. > > 2) I marked RELEASE_19 before changing anything in the release_19 branch > of llvm (you never tagged RELEASE_19). Assuming no one else modified > anything in the release_19 branch, RELEASE_19 represents what is in the > LLVM 1.9 tarball. > > 3) The only changes in the llvm release_19 branch is the removal of DSA > and (maybe) some minor autoconf changes. I did this to ease merges on > DSA between the release_19 branch and mainline of the llvm-poolalloc CVS > module. > > 4) The only new development I've been doing is in the release_19 branch > of the llvm-poolalloc and safecode CVS modules. llvm-poolalloc is, as > far as I can tell, not part of the LLVM releases, and safecode is still > an internal project, so I don't think I've broken any of our release > policies by creating and developing in the release_19 branches for these > two CVS modules. > >> I would suggest creating your own branch if you do not plan to keep up >> with mainline cvs. >> >> In the future, I would hope that you would talk to me (the Release >> Manager) or email the list about changes to the policy regarding the >> release branches. >> >> > I don't think I've changed any policies of which I am aware. However, I > do apologize for not asking you whether you had changed the policy when > I noticed that the RELEASE_19 tag was missing; I probably should have > asked you first before fixing it. > > -- John T. > >> -Tanya >> >> _______________________________________________ >> LLVM Developers mailing list >> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu >> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >> >> > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >