Mailing-List: contact dev-help@myfaces.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "MyFaces Development" <dev@myfaces.apache.org>
Received-SPF: pass (asf.osuosl.org: domain of mbroekelmann@googlemail.com
 designates 64.233.162.192 as permitted sender)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
        s=beta; d=googlemail.com;
        h=received:message-id:date:from:reply-to:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references;
        b=OzFlTqhkYQrzn0FJiXxeqXx2p8dDMP0JMm8yd+NH7hkaBIqfWgGEmMBidd6FacMCxSuNr0bfp/gxsGhRTXnp65uTjwLRxsSW+KkXPL+vhktVAil84XCMIRFW5FZNmvMZVe7iBNQz2XIc82xniXgCzvFAeSLbOVRGwivftP4vGOM=
Message-ID: <9eb65db005092701102696f892@mail.gmail.com>
Date: Tue, 27 Sep 2005 10:10:20 +0200
From: =?ISO-8859-1?Q?Mathias_Br=F6kelmann?= <mbroekelmann@googlemail.com>
Reply-To: =?ISO-8859-1?Q?Mathias_Br=F6kelmann?= <mbroekelmann@googlemail.com>
To: MyFaces Development <dev@myfaces.apache.org>,
	Sean Schofield <sean.schofield@gmail.com>
Subject: Re: Addressing issues in the patch release
In-Reply-To: <2387fbc505092619451655f1f3@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
References: <2387fbc505092614443e895d7d@mail.gmail.com>
	 <5a99335f05092614492dd4e5e1@mail.gmail.com>
	 <E94FA299-072D-42CC-8B68-E99F0CD6B424@mac.com>
	 <2387fbc505092615082b4f670e@mail.gmail.com>
	 <1a681ff205092615142675adbe@mail.gmail.com>
	 <2387fbc505092615221efdc77d@mail.gmail.com>
	 <0F6133F6-6CF6-4545-8503-F99F61A0B83C@mac.com>
	 <2387fbc505092619451655f1f3@mail.gmail.com>

+1 for #3
there are some issues with the radio button in the current release.
Some of them are fixed in trunk but others are still open. I will take
a look at it.

2005/9/27, Sean Schofield <sean.schofield@gmail.com>:
> 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 <bdudney@mac.com> 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 thing=
s
> > > fixed in "nightly" and check into the trunk.
> > >
> > > sean
> > >
> > > On 9/26/05, Bruno Aranda <brunoaranda@gmail.com> 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 <sean.schofield@gmail.com>:
> > >>
> > >>> 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 onc=
e
> > >>> 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 ca=
n
> > >>> 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 an=
d
> > >>> then start the mirroring over the weekend and release on Monday.
> > >>>
> > >>> sean
> > >>>
> > >>>
> > >>>
> > >>> On 9/26/05, Bill Dudney <bdudney@mac.com> 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. I=
f
> > >>>> 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 <sean.schofield@gmail.com> 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
> > >>>>>
> > >>>>>
> > >>>>
> > >>>>
> > >>>>
> > >>>
> > >>>
> > >>
> > >
> >
> >
>


--
Mathias