On Nov 15, 2013, at 8:19 AM, Abhinandan Prateek <abhinandan.prat...@citrix.com> wrote:
> Ok I will go that way till someone says that listing 175 tickets in > CHANGES file will needlessly clutter it. > Can we focus the list to blockers and criticals at least ? > How was it done for 4.1.1 ? all bugs or just blockers/citricals ? I know listing 175 tickets seems like a lot, I am just arguing for consistency and automation. > -abhi > > On 15/11/13 6:34 pm, "Daan Hoogland" <daan.hoogl...@gmail.com> wrote: > >> Abihnandan, >> >> Why not include the output of the query instead of the query? I think >> this is what Sebastien means. A list of the important ones can still >> be prepended in more readable form afaic. >> >> Daan >> >> On Fri, Nov 15, 2013 at 1:32 PM, Abhinandan Prateek >> <abhinandan.prat...@citrix.com> wrote: >>> For listing down the fixed issues, since there are ~175 of these. I will >>> list down some important fixes. >>> Followed by the query to give a exhaustive list, is that acceptable ? >>> >>> For known issues will look at the 4.3/4.2 open tickets list down the >>> important ones. >>> >>> This will go in the CHANGES in source repo and RN in code repo. >>> >>> >>> -abhi >>> >>> On 15/11/13 5:54 pm, "Abhinandan Prateek" >>> <abhinandan.prat...@citrix.com> >>> wrote: >>> >>>> To address the concern of RN we will not conclude the vote on RC (i.e. >>>> Not >>>> make a release) >>>> till the RN in general and upgrade instructions in particular are also >>>> of >>>> acceptable quality. >>>> As for other inconsistencies will work towards ironing those out. >>>> >>>> -abhi >>>> >>>> On 15/11/13 3:30 pm, "Sebastien Goasguen" <run...@gmail.com> wrote: >>>> >>>>> >>>>> On Nov 15, 2013, at 4:43 AM, Abhinandan Prateek >>>>> <abhinandan.prat...@citrix.com> wrote: >>>>> >>>>>> As a RM I had agreed to Sebatian's suggestion of fixing the docs >>>>>> specially >>>>>> the upgrade section of it. >>>>>> And off course doing a GA after the docs are fixed is on the cards. >>>>>> >>>>>> As for the list of fixed and known issues I was told that a filter is >>>>>> good >>>>>> enough but it should be pretty easy to get the listing in the docs >>>>>> itself. >>>>>> If someone has specific preferences it is easy to fix that. >>>>>> >>>>>> So it boils down to get opinion from folks on the following: >>>>>> >>>>>> 1. RC build, this does not contain docs. I have seen no complains or >>>>>> issues here. >>>>> >>>>> That's fine, but releasing something without the upgrade instructions >>>>> committed is bad. >>>>> Even if the release of such upgrade instructions happen after the >>>>> release >>>>> of the code. >>>>> >>>>>> >>>>>> 2. Putting a full listing of bug fixes in RN Vs a filter. Even I will >>>>>> think full listing is good or a query (instead of a URL?) >>>>>> >>>>> >>>>> I am in favor of consistency. Prior to 4.2 we listed all BUGS >>>>> explicitly. >>>>> We should keep doing that. >>>>> >>>>>> 3. Upgrade instructions are known to be bad and we will have to wait >>>>>> at >>>>>> least till Wednesday to get these right. >>>>>> We have some volunteers already working on those and their >>>>>> effort is >>>>>> highly appreciated. >>>>> >>>>> Right, and since there is no rush, why not wait a bit till we can all >>>>> look this with cool heads, double check the RN, bugs listing, upgrade >>>>> instructions etc... >>>>> >>>>>> >>>>>> -abhi >>>>>> >>>>>> >>>>>> On 15/11/13 2:50 pm, "Daan Hoogland" <daan.hoogl...@gmail.com> wrote: >>>>>> >>>>>>> So the -1 is because of the lack of rn and upgrade path docs, >>>>>>> right, I >>>>>>> think I proposed earlier this thread to release after the doc >>>>>>> hackathon privided that. I wasn't really explicit about it I think >>>>>>> as >>>>>>> no one commented on this strategy. Would that be acceptable to you >>>>>>> all >>>>>>> (especially David and Sebastien)? >>>>>>> >>>>>>> I agree btw that docs must be available, but I don't think these >>>>>>> have >>>>>>> to be as stable as the release. We should allow for improving the >>>>>>> docs >>>>>>> on a release if needed. The net result of what I am proposing is >>>>>>> that >>>>>>> there will be a release and a docs rc. This is what the splitting of >>>>>>> of the docs was about in my view,. Makes sense? >>>>>>> >>>>>>> If not, we should not try to make CCC Europe with 4.2.1. I think >>>>>>> this >>>>>>> is what the hurry is about >>>>>>> >>>>>>> Daan >>>>>>> >>>>>>> On Fri, Nov 15, 2013 at 9:14 AM, Sebastien Goasguen >>>>>>> <run...@gmail.com> >>>>>>> wrote: >>>>>>>> I might be behind on the discussions here, but I will veto an RC >>>>>>>> that >>>>>>>> does not have list of bugs fixed and proper upgrade path documented >>>>>>>> (minimum of a fix from 4.2.0 upgrade docs). Separate repo of the >>>>>>>> docs >>>>>>>> or >>>>>>>> not. >>>>>>>> >>>>>>>> Right now I see that the bugs fix list points to a jira filter. >>>>>>>> This >>>>>>>> is >>>>>>>> not consistent with the way it was done in prior releases (explicit >>>>>>>> listing) and in 4.2 (which pointed to the RN). We need consistency. >>>>>>>> What >>>>>>>> happens if someone changes this jira filter ? >>>>>>>> >>>>>>>> I also would like to see the results of the test matrix for 4.2.1 >>>>>>>> running within jenkins.buildacloud.org. This >>>>>>>> http://jenkins.buildacloud.org/view/cloudstack-qa/ runs against >>>>>>>> master >>>>>>>> and has been failing for a while. >>>>>>>> >>>>>>>> PS: I did test it and did the usual smoke test >>>>>>>> >>>>>>>> so -1 (binding) at this time >>>>>>>> >>>>>>>> -sebastien >>>>>>>> >>>>>>>> >>>>>>>> On Nov 14, 2013, at 4:20 PM, Chip Childers >>>>>>>> <chipchild...@apache.org> >>>>>>>> wrote: >>>>>>>> >>>>>>>>> Except that the separation only helps if it allows RC testing + >>>>>>>>> voting >>>>>>>>> during doc finalization. If we announce before docs, it hurts us. >>>>>>>>> I'm against another announcement that goes out with the docs in >>>>>>>>> poor >>>>>>>>> shape. >>>>>>>>> >>>>>>>>> On Thu, Nov 14, 2013 at 3:44 PM, Animesh Chaturvedi >>>>>>>>> <animesh.chaturv...@citrix.com> wrote: >>>>>>>>>> Unless there are objection to the RC, I would prefer to have it >>>>>>>>>> released and make the announcement sooner and showcase in collab >>>>>>>>>> conference. As Chip mentions docs were broken out separately >>>>>>>>>> anyway. >>>>>>>>>> >>>>>>>>>> Animesh >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On 14/11/13 8:12 pm, "Sebastien Goasguen" <run...@gmail.com> >>>>>>>>>> wrote: >>>>>>>>>> >>>>>>>>>>> Anyway we can wait next week to release. >>>>>>>>>>> >>>>>>>>>>> quite a few of us will be together in Amsterdam, we can >>>>>>>>>>> dedicate a >>>>>>>>>>> hackathon session to 4.2.1 , make sure RN are good, upgrade path >>>>>>>>>>> etcŠthen testŠ. >>>>>>>>>>> >>>>>>>>>>> I'd recommend keeping the vote open until then. >>>>>>>>>>> >>>>>>>>>>> -sebastien >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On Nov 14, 2013, at 5:57 AM, Radhika Puthiyetath >>>>>>>>>>> <radhika.puthiyet...@citrix.com> wrote: >>>>>>>>>>> >>>>>>>>>>>> Hi, >>>>>>>>>>>> >>>>>>>>>>>> The master has the most up-to-date RN for 4.2.1. >>>>>>>>>>>> >>>>>>>>>>>> From: Abhinandan Prateek >>>>>>>>>>>> Sent: Thursday, November 14, 2013 2:22 PM >>>>>>>>>>>> To: CloudStack Dev >>>>>>>>>>>> Cc: Radhika Puthiyetath >>>>>>>>>>>> Subject: Re: [ASF4.2.1] Release Notes >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> It seems the upgrade section of release notes will require a >>>>>>>>>>>> review, >>>>>>>>>>>> probably followed by a revamp (?). >>>>>>>>>>>> Can we have some volunteers who are familiar with various >>>>>>>>>>>> upgrade >>>>>>>>>>>> paths comment on it ? >>>>>>>>>>>> Me and Radhika will try to consolidate those comments, snippets >>>>>>>>>>>> and >>>>>>>>>>>> fix the RN for 4.2.1. >>>>>>>>>>>> >>>>>>>>>>>> -abhi >>>>>>>>>>>> >>>>>>>>>>>> RN for 4.2.1 = >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> https://git-wip-us.apache.org/repos/asf?p=cloudstack-docs.git;a= >>>>>>>>>>>> tr >>>>>>>>>>>> e >>>>>>>>>>>> e; >>>>>>>>>>>> f >>>>>>>>>>>> =re >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> lease-notes;h=8128d62c39236331492f3642914bf97b43ed2670;hb=refs/h >>>>>>>>>>>> ea >>>>>>>>>>>> d >>>>>>>>>>>> s/ >>>>>>>>>>>> 4 >>>>>>>>>>>> .2 >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>> >>>>>> >>>>> >>>> >>> >
