You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@geronimo.apache.org by Jacek Laskowski <ja...@laskowski.net.pl> on 2006/07/03 20:36:41 UTC
m2migration branch - thoughts?
Hi,
After having read so many emails with frustration and disgust, I think
we could get rid of these shortcomings and do the migration in a
branch - m2migration or alike. The idea of the branch would be to
loosen up the RTC rules that are bound to the trunk and let people
experimenting - do the migration without having to follow RTC,
preparing patches that don't work for everyone, but often very
temporarily until they're again fixed and improved.
Thoughts?
Jacek
--
Jacek Laskowski
http://www.laskowski.net.pl
Re: m2migration branch - thoughts?
Posted by Jacek Laskowski <ja...@laskowski.net.pl>.
On 7/6/06, Jason Dillon <ja...@planet57.com> wrote:
> On Jul 3, 2006, at 12:18 PM, Alan D. Cabrera wrote:
> > The problem w/ migrating in a branch is that it gets out of date
> > quickly. Since we're not using m2 in trunk anyway, why not just
> > let Jason go crazy in trunk? If there are any changes that are
> > needed in trunk that would affect the current build then for that
> > bit, we go RTC; i.e. Jason should only be futzing w/ M2 POMs.
>
> I agree with this... almost completely; I'd rather not say "go
> crazy"... as it implies the wrong notion for what is going on. But
> short of that I do believe that this is the right approach to getting
> the build system upgraded.
I'm not a svn master and am not saying it will work, but...
Just done a quick test that verified I might be right that a branch
might eventually work. Here goes the story.
We create a branch - m2migration (it's done actually). Every change to
trunk is applied to the branch itself so we're sure it's kept updated.
After a day or two once we're satisfied with a very small change in
the branch, we let people vote - creating a diff (svn diff) and apply
it to a JIRA issue for review. That's where it needs to drift a little
from a common understanding - namely using unix patch. The UNIX patch
command doesn't work well with svn diff as described here -
http://svnbook.red-bean.com/nightly/en/svn.branchmerge.copychanges.html,
but svn merge does. When people are satisfied with reading, they can
apply the patch to their local repository using svn merge (nor patch
that doesn't work well). Once all are satisfied with the change, it
goes to trunk.
Comments?
> --jason
Jacek
--
Jacek Laskowski
http://www.laskowski.net.pl
Re: m2migration branch - thoughts?
Posted by David Jencks <da...@yahoo.com>.
On Jul 5, 2006, at 4:10 PM, Jason Dillon wrote:
> On Jul 3, 2006, at 12:18 PM, Alan D. Cabrera wrote:
>> The problem w/ migrating in a branch is that it gets out of date
>> quickly. Since we're not using m2 in trunk anyway, why not just
>> let Jason go crazy in trunk? If there are any changes that are
>> needed in trunk that would affect the current build then for that
>> bit, we go RTC; i.e. Jason should only be futzing w/ M2 POMs.
>
> I agree with this... almost completely; I'd rather not say "go
> crazy"... as it implies the wrong notion for what is going on. But
> short of that I do believe that this is the right approach to
> getting the build system upgraded.
me too
david jencks
>
> --jason
>
>
Re: m2migration branch - thoughts?
Posted by Jason Dillon <ja...@planet57.com>.
On Jul 3, 2006, at 12:18 PM, Alan D. Cabrera wrote:
> The problem w/ migrating in a branch is that it gets out of date
> quickly. Since we're not using m2 in trunk anyway, why not just
> let Jason go crazy in trunk? If there are any changes that are
> needed in trunk that would affect the current build then for that
> bit, we go RTC; i.e. Jason should only be futzing w/ M2 POMs.
I agree with this... almost completely; I'd rather not say "go
crazy"... as it implies the wrong notion for what is going on. But
short of that I do believe that this is the right approach to getting
the build system upgraded.
--jason
Re: m2migration branch - thoughts?
Posted by Jason Dillon <ja...@planet57.com>.
Brave man! Doesn't look like much fun:
http://svnbook.red-bean.com/nightly/en/svn-
book.html#svn.branchmerge.commonuses.wholebr
But, maybe no one will commit anything to trunk over the next days/
weeks/months :-P
* * *
Does anyone know off hand if the Subversion peeps are going to be
adding the tracking of integrations/merges anytime soon?
--jason
On Jul 4, 2006, at 12:10 AM, Jacek Laskowski wrote:
> On 7/4/06, Jason Dillon <ja...@planet57.com> wrote:
>> Who's responsible for keeping this branch in sync with trunk?
>>
>> Specifically who is going to merge changes from trunk to this branch
>> and/or apply patches to this branch when they are applied to trunk?
>
> I'd be glad to do so. In other words - it's me, but I count on you and
> others. Call me the m2migration branch maintainer ;-)
>
>> --jason
>
> Jacek
>
> --
> Jacek Laskowski
> http://www.laskowski.net.pl
Re: m2migration branch - thoughts?
Posted by Jason Dillon <ja...@planet57.com>.
> I found it invaluable to track my work locally and be able to merge
> in trunk changes and produce patches, but IIRC none of the patches
> I produced could be applied by patch. So, it would probably help
> single developers but might not improve communication or enable review
I would not expect it to have anything to do with communication or
review. Just looking for an easier way to keep development branches
inn sync with trunk, and then when approved, make it easy to merge
back to trunk. SVN is not very good at making this "easy" and thus
ends up being error prone (their book even warns users about it).
So, I was thinking that something like SVK might help facilitate the
sync... but I've only played with SVK in attempts to keep a SVN repo
synchronized with Perforce.
Seems like it might work... I'm gonna try and see.
--jason
Re: m2migration branch - thoughts?
Posted by Jason Dillon <ja...@planet57.com>.
I need someway to move forward... RTC with a ton of patches waiting
for votes just isn't working.
So, if we can not commit to trunk, we need to find a way to
effectively merge from branches so that development can actually use
the source control system to manage work and effectively share that
work with others so they can really see what is going on with
relative ease.
Or do away with this RTC mess which IMO has proven itself to be non-
functional in our environment with only PMC votes counting. Or do
away with the PMC and make all votes count, or make everyone a PMC
member, or... anything to move forward... futzing or not.
:-P
--jason
On Jul 5, 2006, at 11:13 AM, Alan D. Cabrera wrote:
> Please excuse my shout. :)
>
> ARE WE REALLY CONSIDERING FUTZING WITH SVK FOR THE M2
> CONVERISON!?!??!?!
>
> Whew! That felt good. So, we've decided to make an already
> complex job even more complex and obtuse? Quite frankly, IMHO, and
> put in the most genteel tone, that's just crazy talk.
>
>
>
> Regards,
> Alan
>
>
> Jason Dillon wrote:
>> On Jul 4, 2006, at 12:43 AM, David Jencks wrote:
>>> I found it invaluable to track my work locally and be able to
>>> merge in trunk changes and produce patches, but IIRC none of the
>>> patches I produced could be applied by patch. So, it would
>>> probably help single developers but might not improve
>>> communication or enable review.
>>
>> I just re-read this... why were the patches you produced not able
>> to be applied?
>>
>> Did SVK generate bunk patches?
>>
>> * * *
>>
>> From what I have read so far, I *think* that using SVK *might*
>> work to perform the branch sync'ing.
>>
>> I'm going to test it out tomorrow; something like....
>>
>> Create a faux-trunk and branch to test with and not taint the real
>> trunk or branch:
>>
>> svn cp https://svn.apache.org/repos/asf/geronimo/trunk https://
>> svn.apache.org/repos/asf/geronimo/sandbox/svkmerge/trunk
>> svn cp https://svn.apache.org/repos/asf/geronimo/sandbox/svkmerge/
>> trunk https://svn.apache.org/repos/asf/geronimo/sandbox/svkmerge/
>> m2migration
>>
>> Then I'm going to setup SVK to mirror both of these new
>> branches... which I think ends up looking like:
>>
>> svk cp https://svn.apache.org/repos/asf/geronimo/sandbox/svkmerge/
>> trunk trunk
>> svk cp https://svn.apache.org/repos/asf/geronimo/sandbox/svkmerge/
>> m2migration m2migration
>>
>> But, I'm only going to use SVK to sync... not apply changes, so I
>> will apply the GERONIMO-2161 patch to https://svn.apache.org/repos/
>> asf/geronimo/sandbox/svkmerge/m2migration and then commit with SVN
>>
>> Then sync the SVK mirrors...
>>
>> And then smerge m2migration to trunk with SVK (svk push). Should
>> also be able to test smerge trunk to m2migration to test how
>> branch refreshing works (svk pull).
>>
>> Found this email which leads me to believe that this will work:
>>
>> http://rt.openfoundry.org/Foundry/Project/Forum/List.html/wws/
>> arc/svk-dev/2005-02/msg00035.html
>>
>> I might ping folks in #svk on freenode too and see what they have
>> to say about using SVK in this manner.
>>
>> --jason
>
Re: m2migration branch - thoughts?
Posted by "Alan D. Cabrera" <li...@toolazydogs.com>.
Please excuse my shout. :)
ARE WE REALLY CONSIDERING FUTZING WITH SVK FOR THE M2 CONVERISON!?!??!?!
Whew! That felt good. So, we've decided to make an already complex job
even more complex and obtuse? Quite frankly, IMHO, and put in the most
genteel tone, that's just crazy talk.
Regards,
Alan
Jason Dillon wrote:
> On Jul 4, 2006, at 12:43 AM, David Jencks wrote:
>> I found it invaluable to track my work locally and be able to merge
>> in trunk changes and produce patches, but IIRC none of the patches I
>> produced could be applied by patch. So, it would probably help
>> single developers but might not improve communication or enable review.
>
> I just re-read this... why were the patches you produced not able to
> be applied?
>
> Did SVK generate bunk patches?
>
> * * *
>
> From what I have read so far, I *think* that using SVK *might* work to
> perform the branch sync'ing.
>
> I'm going to test it out tomorrow; something like....
>
> Create a faux-trunk and branch to test with and not taint the real
> trunk or branch:
>
> svn cp https://svn.apache.org/repos/asf/geronimo/trunk
> https://svn.apache.org/repos/asf/geronimo/sandbox/svkmerge/trunk
> svn cp
> https://svn.apache.org/repos/asf/geronimo/sandbox/svkmerge/trunk
> https://svn.apache.org/repos/asf/geronimo/sandbox/svkmerge/m2migration
>
> Then I'm going to setup SVK to mirror both of these new branches...
> which I think ends up looking like:
>
> svk cp
> https://svn.apache.org/repos/asf/geronimo/sandbox/svkmerge/trunk trunk
> svk cp
> https://svn.apache.org/repos/asf/geronimo/sandbox/svkmerge/m2migration
> m2migration
>
> But, I'm only going to use SVK to sync... not apply changes, so I will
> apply the GERONIMO-2161 patch to
> https://svn.apache.org/repos/asf/geronimo/sandbox/svkmerge/m2migration
> and then commit with SVN
>
> Then sync the SVK mirrors...
>
> And then smerge m2migration to trunk with SVK (svk push). Should also
> be able to test smerge trunk to m2migration to test how branch
> refreshing works (svk pull).
>
> Found this email which leads me to believe that this will work:
>
>
> http://rt.openfoundry.org/Foundry/Project/Forum/List.html/wws/arc/svk-dev/2005-02/msg00035.html
>
>
> I might ping folks in #svk on freenode too and see what they have to
> say about using SVK in this manner.
>
> --jason
Re: m2migration branch - thoughts?
Posted by Jason Dillon <ja...@planet57.com>.
On Jul 4, 2006, at 12:43 AM, David Jencks wrote:
> I found it invaluable to track my work locally and be able to merge
> in trunk changes and produce patches, but IIRC none of the patches
> I produced could be applied by patch. So, it would probably help
> single developers but might not improve communication or enable
> review.
I just re-read this... why were the patches you produced not able to
be applied?
Did SVK generate bunk patches?
* * *
From what I have read so far, I *think* that using SVK *might* work
to perform the branch sync'ing.
I'm going to test it out tomorrow; something like....
Create a faux-trunk and branch to test with and not taint the real
trunk or branch:
svn cp https://svn.apache.org/repos/asf/geronimo/trunk https://
svn.apache.org/repos/asf/geronimo/sandbox/svkmerge/trunk
svn cp https://svn.apache.org/repos/asf/geronimo/sandbox/svkmerge/
trunk https://svn.apache.org/repos/asf/geronimo/sandbox/svkmerge/
m2migration
Then I'm going to setup SVK to mirror both of these new branches...
which I think ends up looking like:
svk cp https://svn.apache.org/repos/asf/geronimo/sandbox/svkmerge/
trunk trunk
svk cp https://svn.apache.org/repos/asf/geronimo/sandbox/svkmerge/
m2migration m2migration
But, I'm only going to use SVK to sync... not apply changes, so I
will apply the GERONIMO-2161 patch to https://svn.apache.org/repos/
asf/geronimo/sandbox/svkmerge/m2migration and then commit with SVN
Then sync the SVK mirrors...
And then smerge m2migration to trunk with SVK (svk push). Should
also be able to test smerge trunk to m2migration to test how branch
refreshing works (svk pull).
Found this email which leads me to believe that this will work:
http://rt.openfoundry.org/Foundry/Project/Forum/List.html/wws/
arc/svk-dev/2005-02/msg00035.html
I might ping folks in #svk on freenode too and see what they have to
say about using SVK in this manner.
--jason
Re: m2migration branch - thoughts?
Posted by David Jencks <da...@yahoo.com>.
On Jul 4, 2006, at 12:35 AM, Jason Dillon wrote:
> Has anyone used SVK to facilitate full branch merging at all?
I used svk while I was working on jetspeed 2/geronimo integration.
However, I wasn't a jetspeed committer at the time so don't know how
well actually committing sets of versions to the svn repo works.
I found it invaluable to track my work locally and be able to merge
in trunk changes and produce patches, but IIRC none of the patches I
produced could be applied by patch. So, it would probably help
single developers but might not improve communication or enable review.
thanks
david jencks
>
> --jason
>
>
> On Jul 4, 2006, at 12:10 AM, Jacek Laskowski wrote:
>
>> On 7/4/06, Jason Dillon <ja...@planet57.com> wrote:
>>> Who's responsible for keeping this branch in sync with trunk?
>>>
>>> Specifically who is going to merge changes from trunk to this branch
>>> and/or apply patches to this branch when they are applied to trunk?
>>
>> I'd be glad to do so. In other words - it's me, but I count on you
>> and
>> others. Call me the m2migration branch maintainer ;-)
>>
>>> --jason
>>
>> Jacek
>>
>> --
>> Jacek Laskowski
>> http://www.laskowski.net.pl
>
Re: m2migration branch - thoughts?
Posted by Jason Dillon <ja...@planet57.com>.
Has anyone used SVK to facilitate full branch merging at all?
--jason
On Jul 4, 2006, at 12:10 AM, Jacek Laskowski wrote:
> On 7/4/06, Jason Dillon <ja...@planet57.com> wrote:
>> Who's responsible for keeping this branch in sync with trunk?
>>
>> Specifically who is going to merge changes from trunk to this branch
>> and/or apply patches to this branch when they are applied to trunk?
>
> I'd be glad to do so. In other words - it's me, but I count on you and
> others. Call me the m2migration branch maintainer ;-)
>
>> --jason
>
> Jacek
>
> --
> Jacek Laskowski
> http://www.laskowski.net.pl
Re: m2migration branch - thoughts?
Posted by Jacek Laskowski <ja...@laskowski.net.pl>.
On 7/4/06, Jason Dillon <ja...@planet57.com> wrote:
> Who's responsible for keeping this branch in sync with trunk?
>
> Specifically who is going to merge changes from trunk to this branch
> and/or apply patches to this branch when they are applied to trunk?
I'd be glad to do so. In other words - it's me, but I count on you and
others. Call me the m2migration branch maintainer ;-)
> --jason
Jacek
--
Jacek Laskowski
http://www.laskowski.net.pl
Re: m2migration branch - thoughts?
Posted by Jason Dillon <ja...@planet57.com>.
Who's responsible for keeping this branch in sync with trunk?
Specifically who is going to merge changes from trunk to this branch
and/or apply patches to this branch when they are applied to trunk?
--jason
On Jul 3, 2006, at 11:29 PM, Jacek Laskowski wrote:
> On 7/3/06, Alan D. Cabrera <li...@toolazydogs.com> wrote:
>
>> Because m2 work is not the only work that's going on. Not all
>> work has
>> stopped. You are only speaking of the m2 conversion work. There are
>> other efforts underway.
>
> Again, I don't follow. If a change is applied to trunk, why shouldn't
> it be done to the branch, too? Wouldn't it ensure that the branch is
> up-to-date? I think I miss something obvious and you explain me
> something assuming I've got all information you've got. I remember one
> said in this mailing list that it's always worth to try it out in
> action rather than discussing it over and over again. Although it
> doesn't work in all cases, it likely will in this one.
>
> So, did this:
>
> $ svn copy https://svn.apache.org/repos/asf/geronimo/trunk \
> https://svn.apache.org/repos/asf/geronimo/branches/m2migration \
> -m "Creating a branch for M2 migration"
>
> Committed revision 418926.
>
> and a branch is ready at
>
> https://svn.apache.org/repos/asf/geronimo/branches/m2migration/
>
> I hope I didn't break anything and the only change in Geronimo repo is
> the branch only ;-)
>
> Jacek
>
> --
> Jacek Laskowski
> http://www.laskowski.net.pl
Re: m2migration branch - thoughts?
Posted by Jacek Laskowski <ja...@laskowski.net.pl>.
On 7/5/06, Alan D. Cabrera <li...@toolazydogs.com> wrote:
> Sorry, I don't think that I'm following. I don't how I'm ignoring
> people who aren't commiters. You asked for an opinion about branching
> and I gave it.
I tried to compare our situation to what our community has long
experienced and funny enough we kept encouraging them with 'just pick
an issue you wish to work on, submit a patch and voila you're *almost*
done - just wait a while before it gets commited, but hey don't get be
upset as it takes some time - we'll get back to you'.
Jacek
--
Jacek Laskowski
http://www.laskowski.net.pl
Re: m2migration branch - thoughts?
Posted by "Alan D. Cabrera" <li...@toolazydogs.com>.
Jacek Laskowski wrote:
> On 7/5/06, Alan D. Cabrera <li...@toolazydogs.com> wrote:
>
>> Are you saying that *all* changes to the trunk should also be made to
>> your branch? Yikes!
>
> No, what I meant (which seems again to have been expressed badly) was
> that *I* or anyone who cares about the branch being up-to-date to
> apply the patch to the branch, too. It's not an option - with the
> recent Ken's explanation on how we vote for changes - it's the only
> feasible way to go on, imho. It might be more complicated than it
> should really be, but what else could we do? It was just a proposal
> and if you think it's not appropriate, that's fine, but please propose
> something else or we'll end up with nothing but a lenghty discussion
> with no outcome at all. I don't think we want it - not me.
I did, a few days ago on the 3rd.
> Let's think about people who aren't committers? Are you implying that
> they cannot contribute to the project? Can't we work for a while as
> they - the community - have to? It's so good to read so after many
> advices like - 'contributing to a project is as simple as creating a
> JIRA issue and attaching a patch'. I think it's been said many times
> to people who asked how they could contribute with less experience in
> open source projects. Now they read it's not the way *we* can work.
> Interesting.
Sorry, I don't think that I'm following. I don't how I'm ignoring
people who aren't commiters. You asked for an opinion about branching
and I gave it.
Regards,
Alan
Re: m2migration branch - thoughts?
Posted by Jacek Laskowski <ja...@laskowski.net.pl>.
On 7/5/06, Alan D. Cabrera <li...@toolazydogs.com> wrote:
> Are you saying that *all* changes to the trunk should also be made to
> your branch? Yikes!
No, what I meant (which seems again to have been expressed badly) was
that *I* or anyone who cares about the branch being up-to-date to
apply the patch to the branch, too. It's not an option - with the
recent Ken's explanation on how we vote for changes - it's the only
feasible way to go on, imho. It might be more complicated than it
should really be, but what else could we do? It was just a proposal
and if you think it's not appropriate, that's fine, but please propose
something else or we'll end up with nothing but a lenghty discussion
with no outcome at all. I don't think we want it - not me.
Let's think about people who aren't committers? Are you implying that
they cannot contribute to the project? Can't we work for a while as
they - the community - have to? It's so good to read so after many
advices like - 'contributing to a project is as simple as creating a
JIRA issue and attaching a patch'. I think it's been said many times
to people who asked how they could contribute with less experience in
open source projects. Now they read it's not the way *we* can work.
Interesting.
> Alan
Jacek
--
Jacek Laskowski
http://www.laskowski.net.pl
Re: m2migration branch - thoughts?
Posted by "Alan D. Cabrera" <li...@toolazydogs.com>.
Jacek Laskowski wrote:
> On 7/3/06, Alan D. Cabrera <li...@toolazydogs.com> wrote:
>
>> Because m2 work is not the only work that's going on. Not all work has
>> stopped. You are only speaking of the m2 conversion work. There are
>> other efforts underway.
>
> Again, I don't follow. If a change is applied to trunk, why shouldn't
> it be done to the branch, too? Wouldn't it ensure that the branch is
> up-to-date?
Are you saying that *all* changes to the trunk should also be made to
your branch? Yikes!
> I think I miss something obvious and you explain me
> something assuming I've got all information you've got. I remember one
> said in this mailing list that it's always worth to try it out in
> action rather than discussing it over and over again.
The difference is that to make this fly, you need the cooperation of
everyone who is, or will be, checking in changes/fixes into trunk. This
is a big change and I'm not sure that we've been discussing this over
and over again. As a matter of fact, I kinda slightly feel that this is
abruptly stifling the discussion that's moving along quite nicely.
Regards,
Alan
> Although it
> doesn't work in all cases, it likely will in this one.
>
> So, did this:
>
> $ svn copy https://svn.apache.org/repos/asf/geronimo/trunk \
> https://svn.apache.org/repos/asf/geronimo/branches/m2migration \
> -m "Creating a branch for M2 migration"
>
> Committed revision 418926.
>
> and a branch is ready at
>
> https://svn.apache.org/repos/asf/geronimo/branches/m2migration/
>
> I hope I didn't break anything and the only change in Geronimo repo is
> the branch only ;-)
>
> Jacek
>
Re: m2migration branch - thoughts?
Posted by Jacek Laskowski <ja...@laskowski.net.pl>.
On 7/3/06, Alan D. Cabrera <li...@toolazydogs.com> wrote:
> Because m2 work is not the only work that's going on. Not all work has
> stopped. You are only speaking of the m2 conversion work. There are
> other efforts underway.
Again, I don't follow. If a change is applied to trunk, why shouldn't
it be done to the branch, too? Wouldn't it ensure that the branch is
up-to-date? I think I miss something obvious and you explain me
something assuming I've got all information you've got. I remember one
said in this mailing list that it's always worth to try it out in
action rather than discussing it over and over again. Although it
doesn't work in all cases, it likely will in this one.
So, did this:
$ svn copy https://svn.apache.org/repos/asf/geronimo/trunk \
https://svn.apache.org/repos/asf/geronimo/branches/m2migration \
-m "Creating a branch for M2 migration"
Committed revision 418926.
and a branch is ready at
https://svn.apache.org/repos/asf/geronimo/branches/m2migration/
I hope I didn't break anything and the only change in Geronimo repo is
the branch only ;-)
Jacek
--
Jacek Laskowski
http://www.laskowski.net.pl
Re: m2migration branch - thoughts?
Posted by "Alan D. Cabrera" <li...@toolazydogs.com>.
Jacek Laskowski wrote:
> On 7/3/06, Alan D. Cabrera <li...@toolazydogs.com> wrote:
>
>> The problem w/ migrating in a branch is that it gets out of date
>> quickly.
>
> Quickly?! Is my English working badly again? ;-) How could you say
> 'quickly' while we're almost stopped and everybody's frustrated?
> That's why I proposed it.
Because m2 work is not the only work that's going on. Not all work has
stopped. You are only speaking of the m2 conversion work. There are
other efforts underway.
>> Since we're not using m2 in trunk anyway, why not just let
>> Jason go crazy in trunk? If there are any changes that are needed in
>> trunk that would affect the current build then for that bit, we go RTC;
>> i.e. Jason should only be futzing w/ M2 POMs.
>
> Isn't a branch suitable for such a work? I think Ken wouldn't agree
> with the above ;-)
As I mentioned above, the branch could get out of sync w/ trunk pretty
quickly. The only reason to make a branch is to isolate the m2 work
from the m2 stuff that's being used in trunk. But, the m2 stuff isn't
being used in trunk. Working in the branch and working on the trunk is
then virtually the same since m2 isn't being used in trunk.
When the m2 work is done, we can fire up an RTC vote. This is not to
say that there won't be a healthy dose of discussion along the way.
It's ultimately up to the PMC and, most likely, Ken if it's following
the intent of RTC.
Regards,
Alan
Re: m2migration branch - thoughts?
Posted by Jason Dillon <ja...@planet57.com>.
>> The problem w/ migrating in a branch is that it gets out of date
>> quickly.
>
> Quickly?! Is my English working badly again? ;-) How could you say
> 'quickly' while we're almost stopped and everybody's frustrated?
> That's why I proposed it.
Problem is that the branch needs to be kept in sync with other
changes to trunk... which is merging overhead, less overhead perhaps
than with RTC.
Unless we can agree that the m2 changes in trunk are okay to commit w/
o RTC because they only affect the m2 build, then I feel I have not
choice but to branch and work out how best to keep the branch sync'd
with out causing artificial merge conflicts... or simply stop working
on this.
IMO, the branch is better than RTC on trunk... but I think that it is
still more work than what is really needed... and I don't really like
to waste my time (or yours).
--jason
Re: m2migration branch - thoughts?
Posted by Jacek Laskowski <ja...@laskowski.net.pl>.
On 7/3/06, Alan D. Cabrera <li...@toolazydogs.com> wrote:
> The problem w/ migrating in a branch is that it gets out of date
> quickly.
Quickly?! Is my English working badly again? ;-) How could you say
'quickly' while we're almost stopped and everybody's frustrated?
That's why I proposed it.
> Since we're not using m2 in trunk anyway, why not just let
> Jason go crazy in trunk? If there are any changes that are needed in
> trunk that would affect the current build then for that bit, we go RTC;
> i.e. Jason should only be futzing w/ M2 POMs.
Isn't a branch suitable for such a work? I think Ken wouldn't agree
with the above ;-)
> Alan
Jacek
--
Jacek Laskowski
http://www.laskowski.net.pl
Re: m2migration branch - thoughts?
Posted by "Alan D. Cabrera" <li...@toolazydogs.com>.
Jacek Laskowski wrote:
> Hi,
>
> After having read so many emails with frustration and disgust, I think
> we could get rid of these shortcomings and do the migration in a
> branch - m2migration or alike. The idea of the branch would be to
> loosen up the RTC rules that are bound to the trunk and let people
> experimenting - do the migration without having to follow RTC,
> preparing patches that don't work for everyone, but often very
> temporarily until they're again fixed and improved.
>
> Thoughts?
>
> Jacek
>
The problem w/ migrating in a branch is that it gets out of date
quickly. Since we're not using m2 in trunk anyway, why not just let
Jason go crazy in trunk? If there are any changes that are needed in
trunk that would affect the current build then for that bit, we go RTC;
i.e. Jason should only be futzing w/ M2 POMs.
Regards,
Alan
Re: m2migration branch - thoughts?
Posted by Jason Dillon <ja...@planet57.com>.
On Jul 3, 2006, at 1:04 PM, Aaron Mulder wrote:
> I'm concerned that after all the work is done, it will be hard to
> merge the M2 changes from the branch to the trunk. SVN doesn't seem
> to have particularly good handing for merging changes that involve a
> lot of subsequent adds, deletes, moves, etc. When this stuff gets
> complex, more often than not, I've had to just whack the old tree and
> check out a fresh copy.
Perforce can handle all of that... and you can merge 90% of it with
your eyes closed. You could have a branch of a branch with moves and
adds and deletes in both, and P4 will be able to easily merge it all
back to trunk with no problems.
I really, really, really wish that Subversion could handle this sort
of branching and merging. In many ways SVN is still as bad as CVS
when it comes to branch and merge.
:-(
--jason
Re: m2migration branch - thoughts?
Posted by Aaron Mulder <am...@alumni.princeton.edu>.
I'm concerned that after all the work is done, it will be hard to
merge the M2 changes from the branch to the trunk. SVN doesn't seem
to have particularly good handing for merging changes that involve a
lot of subsequent adds, deletes, moves, etc. When this stuff gets
complex, more often than not, I've had to just whack the old tree and
check out a fresh copy.
So we could all shift to working out the kinks in the M2 branch as CTR
and then vote to make that branch *into* head under the rules for
revolutionaries. But really, I think this just emphasizes the
limitations of RTC for the kind of work that's going on for 1.2.
Thanks,
Aaron
On 7/3/06, Jacek Laskowski <ja...@laskowski.net.pl> wrote:
> Hi,
>
> After having read so many emails with frustration and disgust, I think
> we could get rid of these shortcomings and do the migration in a
> branch - m2migration or alike. The idea of the branch would be to
> loosen up the RTC rules that are bound to the trunk and let people
> experimenting - do the migration without having to follow RTC,
> preparing patches that don't work for everyone, but often very
> temporarily until they're again fixed and improved.
>
> Thoughts?
>
> Jacek
>
> --
> Jacek Laskowski
> http://www.laskowski.net.pl
>
Re: m2migration branch - thoughts?
Posted by John Sisson <jr...@gmail.com>.
Matt Hogstrom wrote:
> I think the Maven 2 work is a significant project. It appears to me
> that RTC has worked really well in increasing e-mail traffic on the
> list exponentially but I too would agree that it has not been totally
> productive. Here is my assessment:
>
> 1. Everyone agrees that this work needs to be done.
>
> 2. The overall approach is generally accepted.
>
> 3. I believe that Jason and others that have been working on the
> conversion (not to mention the voluminous amount of work on the part
> of Prasad and Anita as well as Jencks) and understand what needs to be
> done.
>
> 4. Maven 1 still works in trunk and Maven 2 is broken.
>
> I suggest that we agree that the team doing the conversion be allowed
> to make the changes directly in trunk. They are not disrupting
> anything they are currently fixing a move to an already agreed to
> build change. Rather than have RTC be the model I move that we allow
> them to continue to communicate through e-mail to keep everyone up to
> date on the status of the migration.
>
> My goal is not to bypass RTC but merely to acknowledge that in the
> case of this migration it is not the best tool to accomplish the task.
>
> John and Jacek since you are the active committers on the PMC perhaps
> you can discuss this and provide some relief in the process.
>
Will follow up with the PMC.
Regards,
John
> Cheers.
>
> Jacek Laskowski wrote:
>> Hi,
>>
>> After having read so many emails with frustration and disgust, I think
>> we could get rid of these shortcomings and do the migration in a
>> branch - m2migration or alike. The idea of the branch would be to
>> loosen up the RTC rules that are bound to the trunk and let people
>> experimenting - do the migration without having to follow RTC,
>> preparing patches that don't work for everyone, but often very
>> temporarily until they're again fixed and improved.
>>
>> Thoughts?
>>
>> Jacek
>>
>
Re: m2migration branch - thoughts?
Posted by Matt Hogstrom <ma...@hogstrom.org>.
I think the Maven 2 work is a significant project. It appears to me that RTC has worked really well
in increasing e-mail traffic on the list exponentially but I too would agree that it has not been
totally productive. Here is my assessment:
1. Everyone agrees that this work needs to be done.
2. The overall approach is generally accepted.
3. I believe that Jason and others that have been working on the conversion (not to mention the
voluminous amount of work on the part of Prasad and Anita as well as Jencks) and understand what
needs to be done.
4. Maven 1 still works in trunk and Maven 2 is broken.
I suggest that we agree that the team doing the conversion be allowed to make the changes directly
in trunk. They are not disrupting anything they are currently fixing a move to an already agreed to
build change. Rather than have RTC be the model I move that we allow them to continue to
communicate through e-mail to keep everyone up to date on the status of the migration.
My goal is not to bypass RTC but merely to acknowledge that in the case of this migration it is not
the best tool to accomplish the task.
John and Jacek since you are the active committers on the PMC perhaps you can discuss this and
provide some relief in the process.
Cheers.
Jacek Laskowski wrote:
> Hi,
>
> After having read so many emails with frustration and disgust, I think
> we could get rid of these shortcomings and do the migration in a
> branch - m2migration or alike. The idea of the branch would be to
> loosen up the RTC rules that are bound to the trunk and let people
> experimenting - do the migration without having to follow RTC,
> preparing patches that don't work for everyone, but often very
> temporarily until they're again fixed and improved.
>
> Thoughts?
>
> Jacek
>