[LLVMdev] using dsa from llvm-poolalloc

[Tanya M. Lattner]

>> 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
>