geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alan D. Cabrera" <l...@toolazydogs.com>
Subject Re: Geronimo Repository (was Re: Unable to build using m2)
Date Sat, 01 Jul 2006 21:05:17 GMT
Jason, who are you replying to?  You accidentally cut out the person's name.


Regards,
Alan

Jason Dillon wrote:
>> I agree with your comments but I also recognize that it is a slippery 
>> slope.  Who is responsible for tracking the changes and lobbying the 
>> other groups?  My limited experience tells me that this will likely 
>> end up being a set of forked code from other projects that will be 
>> very difficult to manage.  for instance...say a quick change is made 
>> to XMLBeans and it get's put into our "local" copy.  4 months later 
>> the XMLBeans folks have not done anything with the patch and now 
>> after discussing it further decide that it doens't fit with their 
>> direction.  During that time Geronimo has relied on the patch and 
>> changing direction is going to be painful.
>
> I would expect that most of the localized changes would be to pom's 
> only and to install the correct version of the dependency in a 
> repository for our build to work.
>
> While I think that we may need to have a few cases where some code is 
> required to change, but in order for that to work, there must be 
> someone who is actively working with the external community to get the 
> changes in.  Otherwise, as you suggested it would turn into a private 
> fork... and IMO that is not acceptable.
>
> I believe that it would be the responsibility of the developer who 
> introduces the new version of the dependency to create a JIRA (in our 
> project) to manage the state of the dependency... AND be active about 
> getting the changes introduced in the target communities codebase.
>
> Peer review will also be used to help ensure that we keep things 
> moving smoothly.  Like, if a custom version of a dependency exists for 
> months and months and goes no where, then we need to react and either 
> help the developer get the changes moved or reevaluate the need for 
> those changes, etc.
>
>
>> I realize this is a worse case scenario but we had a similar 
>> situation with the Axis guys in cutting a 1.4 release for us.  It 
>> took about 6 months and I think was only done because David Blevins 
>> was made a committer.
>
> Um, did it take 6 months because he was a committer?  Meaning it would 
> have taken more than 6 months if he was not?  Yikes!
>
>
>> In order to consider this it would be great if you could flush out 
>> the different scenarios as you see them and how we would handle 
>> them.  I'm not the most administrative person on the planet and what 
>> you are proposing sounds great and scare the heck out of me at the 
>> same time ;-0
>
> Well...  I'm not sure I know of all of the scenarios, but mostly I do 
> not see that we will have custom forked versions of others work in our 
> repository, though on some occasions yes, we will... but only for a 
> very limited and controlled period.
>
> For example, I have been using the RetroTranslator m2 plugin in GShell 
> for many weeks now.  I have been very active about creating patches 
> for the Mojo team, getting changes needed into this plugin so that it 
> can be more useful.  But, it takes the Mojo team time (some times a 
> long time) to pull in those changes... or as is the current case, to 
> publish the plugin with those changes already accepted and committed.
>
> So we have already gotten the code in the target communities 
> codebase... but it is taking a long time to get a new release (or 
> SNAPSHOT) pushed out to a repo so that we can actually use it.
>
> This is where our repository comes in.  We publish a SNAPSHOT of the 
> plugin to our repository so that we can continue to move forward using 
> the plugin, and in the background keep on the Mojo peeps to get the 
> thing official.
>
>  * * *
>
> There is also the other-side of the repository, which is to allow 
> builds to be reproducible in future months, years.  To have 100% build 
> reproducibility we need to have much more control over the repository 
> which dependencies are pulled from.
>
> The reliance on so many external repositories is a build anti-pattern 
> and make is very difficult (some times impossible) to ensure that 
> builds will just work in future days, months, years.  Machines crash, 
> data gets lost, which we have recently seen and suffered from.  Having 
> a repository that is controlled by the same system as our sources will 
> generally mean that at any point in time when when have a valid scm 
> codebase, then we also have the valid dependencies.  Then when the 
> Codehaus disks die again, or a worm eats thought all of Ibiblio, then 
> we can still function and continue to work.
>
>  * * *
>
> I believe that both of these reasons (staging w/external groups and 
> build reproduction and isolation from external failure) warrant the 
> creation of an internal SVN-backed repository that exists solely for 
> the use by Geronimo, and its child projects.
>
> --jason


Mime
View raw message