Hi Developers, This is to clarify which patches may be merged into the 3.5 branch. * All doc changes may go in. In fact, you’re encouraged to update the branch's ReleaseNotes.rst file! :-) * All non-documentation patches should first receive approval from the appropriate code maintainer. (A blanket approval is acceptable for the first phase of testing.) * If your patch fixes a major bug, it may go in. * If your patch is to complete an *existing* feature, then it may go into the 3.5 branch. However, this feature must be completed by Phase II of testing. Once Phase II testing starts, we will be accepting only those patches that fix major bugs. Share and enjoy! -bw
One more things… To ease merging the patches into the 3.5 branch, you may use the ‘utils/release/merge.sh’ script. -bw On Jul 22, 2014, at 9:50 AM, Bill Wendling <isanbard at gmail.com> wrote:> Hi Developers, > > This is to clarify which patches may be merged into the 3.5 branch. > > * All doc changes may go in. In fact, you’re encouraged to update the branch's ReleaseNotes.rst file! :-) > > * All non-documentation patches should first receive approval from the appropriate code maintainer. (A blanket approval is acceptable for the first phase of testing.) > > * If your patch fixes a major bug, it may go in. > > * If your patch is to complete an *existing* feature, then it may go into the 3.5 branch. However, this feature must be completed by Phase II of testing. > > Once Phase II testing starts, we will be accepting only those patches that fix major bugs. > > Share and enjoy! > -bw >
Bill,
Can you clarify on 'existing feature'? Does this allow for addition
of
missing functionality for the openmp support such as…
http://llvm.org/viewvc/llvm-project?view=revision&revision=213639
Almost all of the remaining commits for clang-omp support will be
implementing missing functionality in the openmp support.
Jack
On Tue, Jul 22, 2014 at 12:50 PM, Bill Wendling <isanbard at gmail.com>
wrote:
> Hi Developers,
>
> This is to clarify which patches may be merged into the 3.5 branch.
>
> * All doc changes may go in. In fact, you’re encouraged to update the
> branch's ReleaseNotes.rst file! :-)
>
> * All non-documentation patches should first receive approval from the
> appropriate code maintainer. (A blanket approval is acceptable for the
> first phase of testing.)
>
> * If your patch fixes a major bug, it may go in.
>
> * If your patch is to complete an *existing* feature, then it may go into
> the 3.5 branch. However, this feature must be completed by Phase II of
> testing.
>
> Once Phase II testing starts, we will be accepting only those patches that
> fix major bugs.
>
> Share and enjoy!
> -bw
>
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20140722/3196259d/attachment.html>
I normally expect a feature to be a standalone bit of functionality — like a new optimization pass or some refactoring work. The openmp work is much bigger in nature. How many more patches will you need to commit? Are the features self contained (i.e., it doesn’t modify other parts of the compiler)? -bw On Jul 22, 2014, at 10:32 AM, Jack Howarth <howarth.mailing.lists at gmail.com> wrote:> Bill, > Can you clarify on 'existing feature'? Does this allow for addition of missing functionality for the openmp support such as… > > http://llvm.org/viewvc/llvm-project?view=revision&revision=213639 > > Almost all of the remaining commits for clang-omp support will be implementing missing functionality in the openmp support. > Jack > > > On Tue, Jul 22, 2014 at 12:50 PM, Bill Wendling <isanbard at gmail.com> wrote: > Hi Developers, > > This is to clarify which patches may be merged into the 3.5 branch. > > * All doc changes may go in. In fact, you’re encouraged to update the branch's ReleaseNotes.rst file! :-) > > * All non-documentation patches should first receive approval from the appropriate code maintainer. (A blanket approval is acceptable for the first phase of testing.) > > * If your patch fixes a major bug, it may go in. > > * If your patch is to complete an *existing* feature, then it may go into the 3.5 branch. However, this feature must be completed by Phase II of testing. > > Once Phase II testing starts, we will be accepting only those patches that fix major bugs. > > Share and enjoy! > -bw > > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20140722/6d78f2fd/attachment.html>