myfaces-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Matt Cooper" <matt.fa...@gmail.com>
Subject Re: [Trinidad: VOTE] 1.2 current again
Date Fri, 16 Nov 2007 00:44:09 GMT
+1 to committers patching both "branches" as they go; no more poor
soul having to do an ubermerge :)

On Nov 15, 2007 5:38 PM, Scott O'Bryan <darkarena@gmail.com> wrote:
> Jeanne,
>
> Yes they are saying different things but the two are not mutually
> exclusive.  What I was saying was +1 to creating a 1.2 trunk.
>
> That said, we will have to move to a situation where patches are applied
> to the main branch as a per-patch basis to make this manageable.  Matt's
> concerns for creating this trunk are valid and can be addressed quite
> easily by changing how we choose to apply changes.  I think in the long
> run it'll make the 1.2 branch more stable because we will no longer have
> to depend on an UBERMERGE to get the code into the new branch.  Instead
> issues can be addressed when the patches are applied and the committer
> is familiar with the code.
>
> Scott  :)
>
>
> Jeanne Waldman wrote:
> > What is Matt saying that is different than what Andrew was saying?
> > We are going to require someone to check into both 1.2.X and 1.0.X,
> > correct?
> > This is a step in the right direction, and helps me out since I won't
> > have to do the merge if this goes through.
> >
> > +1
> >
> > - Jeanne
> >
> > Scott O'Bryan wrote:
> >> +1 to adding the trunk and I think Matt's suggestion is the best way
> >> to do this without being too cumbersome.
> >>
> >> Matt Cooper wrote:
> >>> +0 I have had troubles with the reverse structure of having the legacy
> >>> code on the trunk and the latest in a branch so I would like that to
> >>> switch too.  As Jeanne points out, I think having 2 trunks would make
> >>> merging more difficult--at least if the rules remained as noted in
> >>> Adam's wiki.  Now, if we were to apply patches as a one-by-one basis
> >>> and no no longer perform large trunk-to-branch style merging for
> >>> releases then this would be a big win.  This would help to prevent
> >>> accidental merging of patches that are specific to a particular
> >>> release into the wrong release.  This may not be what the vote is for
> >>> so my vote is just neutral for now.
> >>>
> >>> Regards,
> >>> Matt
> >>>
> >>> On Nov 15, 2007 12:09 PM, Martin Marinschek
> >>> <martin.marinschek@gmail.com> wrote:
> >>>
> >>>> +1,
> >>>>
> >>>> regards,
> >>>>
> >>>> Martin
> >>>>
> >>>>
> >>>> On 11/15/07, Grant Smith <work.grant@gmail.com> wrote:
> >>>>
> >>>>> +1, Andrew's suggestions make good sense.
> >>>>>
> >>>>> On 11/15/07, Andrew Robinson <andrew.rw.robinson@gmail.com>
wrote:
> >>>>>
> >>>>>> On 11/15/07, Jeanne Waldman <jeanne.waldman@oracle.com>
wrote:
> >>>>>>
> >>>>>>> The same fix was in both, but one had different spacing.
> >>>>>>>
> >>>>>> Then it wasn't merged correctly and technically wasn't the same
fix
> >>>>>> from a repository point of view. With two active versions, ppl.
> >>>>>> would
> >>>>>> be responsible for using svn commands for putting a change set
in
> >>>>>> both
> >>>>>> branches and not doing manual edits except for conflict resolution.
> >>>>>>
> >>>>>> If ppl used the tool correctly, there should not be any such
> >>>>>> conflicts.
> >>>>>>
> >>>>>>
> >>>>>>> Check Adam's wiki about merging the branches
> >>>>>>>
> >>>>>> Yes, this is assuming the current procedure without an active
> >>>>>> branch on
> >>>>>> JSF 1.2
> >>>>>>
> >>>>>>
> >>>>>>> - Jeanne
> >>>>>>>
> >>>>>
> >>>>> --
> >>>>> Grant Smith
> >>>>>
> >>>>>
> >>>> --
> >>>>
> >>>> http://www.irian.at
> >>>>
> >>>> Your JSF powerhouse -
> >>>> JSF Consulting, Development and
> >>>> Courses in English and German
> >>>>
> >>>> Professional Support for Apache MyFaces
> >>>>
> >>>>
> >>>
> >>>
> >>
> >>
> >
>
>

Mime
View raw message