TCK testing takes long, but runs alone - once it runs ;-) I will run it as soon as we have the RC, because I do not want to bring unnecessary delay to the final release in case there are problems with TCK. I only managed to get it running with Sun1AS, and if my machine finally breaks down because of memory consumption I don't know if I can switch to another AS in reasonable time ;-) No problem to do it twice if we have a RC2.
-Manfred 2005/9/27, Sean Schofield <[EMAIL PROTECTED]>: > Manfred, > > Lets hold off on the RC candidate until this weekend. It will give us > a few more days to take on the important issues. Since so much work > goes into a release lets try and fix all of the major outstanding > issues we can by that time. > > Also, I would suggest doing TCK testing late next week after the RC > has been out for a few days. No sense in doing all of that work until > the users have also tested since we may need a second RC. If you > don't mind testing twice then no worries though. > > sean > > On 9/27/05, Manfred Geiler <[EMAIL PROTECTED]> wrote: > > As mentioned on friday I prefer #3 anyway. So, no objection from my > > side, of course. > > > > If you could manage to build the release today (tuesday) until > > midnight (EST) I can start the TCK tests right after in the early > > morning (MEZ). > > Thanks http://www.timeanddate.com for not beeing totally confused now ;-) > > > > -Manfred > > > > > > 2005/9/27, Sean Schofield <[EMAIL PROTECTED]>: > > > Yes that's correct. Lets just make sure Manfred and the other > > > committers don't have any last minute objections or alternative plans. > > > Lets figure anytime past 12:00 EST is ok to do the branch. Let me > > > know when you are starting the branch and I will start the JIRA > > > change. > > > > > > Should only take about 15 minutes with both of us working in tandem. > > > > > > sean > > > > > > ps. Testing a revised build.xml now ... > > > > > > On 9/26/05, Bill Dudney <[EMAIL PROTECTED]> wrote: > > > > Hi Sean, > > > > > > > > I can and will help tomorrow. I have some stuff to do in my day job > > > > but I'll make time for the branch. > > > > > > > > If I understand things correctly we are going to delete the 1.1.0.1 > > > > branch I created the other day and create another branch set from the > > > > current trunk and turn that into the release then create a tag when > > > > done and merge all changes into the trunk. > > > > > > > > Do I have that correct? I want to make sure before I start deleting > > > > branches :-) > > > > > > > > TTFN, > > > > > > > > -bd- > > > > > > > > On Sep 26, 2005, at 4:22 PM, Sean Schofield wrote: > > > > > > > > > We'll need to coordinate the creation of the branch with the version > > > > > change in JIRA. Bill are you available to create the branch tomorrow? > > > > > If so, please touch base with me tomorrow and we will begin together > > > > > (assuming no major objections overnight.) For now keep marking things > > > > > fixed in "nightly" and check into the trunk. > > > > > > > > > > sean > > > > > > > > > > On 9/26/05, Bruno Aranda <[EMAIL PROTECTED]> wrote: > > > > > > > > > >> +1 I like option #3. Thus the show stoppers will also be fixed, and > > > > >> let's test thoroughly this time :-) ... > > > > >> > > > > >> Regards, > > > > >> > > > > >> Bruno > > > > >> > > > > >> > > > > >> 2005/9/27, Sean Schofield <[EMAIL PROTECTED]>: > > > > >> > > > > >>> The trunk does not have my fix to the build but it does have yours. > > > > >>> My changes don't matter anymore since we settled on a different > > > > >>> option > > > > >>> for the sandbox problem. So we are fine to drop the old branch once > > > > >>> we are in agreement. > > > > >>> > > > > >>> Lets wait until tomorrow and give some of the Europeans a chance to > > > > >>> weigh in during business hours. If we get a few more +1 then we can > > > > >>> create the branch and pursue option #3 > > > > >>> > > > > >>> We just need to remind all committers that they should check urgent > > > > >>> bug fixes into the branch only and the rest goes into the trunk > > > > >>> only. > > > > >>> Also, all JIRA issues should be caefully scrutinized before > > > > >>> closing so > > > > >>> we can generate proper release notes off them. > > > > >>> > > > > >>> Lets make the branch short lived. Fix everything we can this > > > > >>> week and > > > > >>> build the RC over the weekend. Let people test the RC next week and > > > > >>> then start the mirroring over the weekend and release on Monday. > > > > >>> > > > > >>> sean > > > > >>> > > > > >>> > > > > >>> > > > > >>> On 9/26/05, Bill Dudney <[EMAIL PROTECTED]> wrote: > > > > >>> > > > > >>>> I'd like to get the branch 'closed' as soon as possible so I'm in > > > > >>>> favor of either 1.1.0.1 as a patch release (option 1) to get the > > > > >>>> myfaces-all problem resolved then start rolling on a 1.1.1 release > > > > >>>> (option 3). > > > > >>>> > > > > >>>> If we don't do the maintenance release then the branch IMO > > > > >>>> should be > > > > >>>> deleted, which would be fine with me (i.e. I'm not emotionally > > > > >>>> attached to the branch :-). It seemed very urgent the other day > > > > >>>> (when > > > > >>>> the branch was created) that we needed a new patch release ASAP. If > > > > >>>> that is not the case then we should drop the branch (easy to do in > > > > >>>> SVN) and get started on a 1.1.1 release. > > > > >>>> > > > > >>>> I believe the trunk has Sean and my fixes to the build so we are > > > > >>>> good > > > > >>>> to go on the branch from the fixed myfaces-all perspective. > > > > >>>> > > > > >>>> TTFN, > > > > >>>> > > > > >>>> -bd > > > > >>>> > > > > >>>> > > > > >>>> On Sep 26, 2005, at 3:49 PM, Martin Marinschek wrote: > > > > >>>> > > > > >>>> > > > > >>>>> With the documentation in place I don't see it necessary to > > > > >>>>> immediately pull a release. > > > > >>>>> > > > > >>>>> So let's take option three and roll it slowly! > > > > >>>>> > > > > >>>>> regards, > > > > >>>>> > > > > >>>>> Martin > > > > >>>>> > > > > >>>>> On 9/26/05, Sean Schofield <[EMAIL PROTECTED]> wrote: > > > > >>>>> > > > > >>>>> > > > > >>>>>> We seemed to have settled on doing a 1.1.0 patch release. The > > > > >>>>>> one > > > > >>>>>> fix > > > > >>>>>> we know for sure that is going to be in it is the fix to the > > > > >>>>>> TLD and > > > > >>>>>> faces-config.xml regarding the sandbox stuff. > > > > >>>>>> > > > > >>>>>> Bill has created a branch for us off the release point. There > > > > >>>>>> are > > > > >>>>>> one > > > > >>>>>> or two "urgent" bugs being described on the user list. Are we > > > > >>>>>> going > > > > >>>>>> to address them in this release or a folow up release? > > > > >>>>>> > > > > >>>>>> > > > > >>>>>> Here are the options as I see them: > > > > >>>>>> > > > > >>>>>> 1.) Fix nothing but the faces-config and release > > > > >>>>>> > > > > >>>>>> 2.) Fix faces config and one or two other show stopers. > > > > >>>>>> > > > > >>>>>> 3.) Create a new branch off the head, build an RC and put > > > > >>>>>> important > > > > >>>>>> fixes there. Then release after review of RC. > > > > >>>>>> > > > > >>>>>> If we choose option #2 or #3 I think we need to do the following: > > > > >>>>>> > > > > >>>>>> a.) keep the list *very* of must fixes very small so we don't > > > > >>>>>> have a > > > > >>>>>> SVN merging nightmare > > > > >>>>>> b.) create a JIRA version for 1.1.1 and mark the bugs to be > > > > >>>>>> fixed in > > > > >>>>>> 1.1.1 as such. > > > > >>>>>> c.) fix all these bugs on the branch *only* > > > > >>>>>> d.) release 1.1.1 > > > > >>>>>> e.) merge back down to trunk and get on with our lives. :-) > > > > >>>>>> > > > > >>>>>> This means we also need to be careful about creating and > > > > >>>>>> resolving > > > > >>>>>> bugs. They need to say "nightly" when fixed in the trunk and > > > > >>>>>> "1.1.1" > > > > >>>>>> when fixed in the branch. > > > > >>>>>> > > > > >>>>>> Right now I am leaning towards Option #3. > > > > >>>>>> > > > > >>>>>> sean > > > > >>>>>> > > > > >>>>>> > > > > >>>>>> > > > > >>>>> > > > > >>>>> > > > > >>>>> -- > > > > >>>>> > > > > >>>>> http://www.irian.at > > > > >>>>> Your JSF powerhouse - > > > > >>>>> JSF Trainings in English and German > > > > >>>>> > > > > >>>>> > > > > >>>> > > > > >>>> > > > > >>>> > > > > >>> > > > > >>> > > > > >> > > > > > > > > > > > > > > > > > > >
