I would say, sync only poms that don't exist already, so we get new ones, but don't override already existing poms automatically, make the interested projects submit a issue in MEV, because if they're interested in fixing their build they will be also interested in that pom ending in ibiblio, something that doesn't happen the other way.
With this process we'll ensure that the right pom will be always in ibiblio, used and tested by everyone, and interested projects can always get the pom from there. For each pom updated in a synced repo we'll have 20+ updated in MEV, so this will be an optimization, at least until things change. Also IIRC the m1-m2 converter could easily warn when the m1 pom changed, that we'll make us aware of updates. Regards On 8/30/05, Brett Porter <[EMAIL PROTECTED]> wrote: > Carlos Sanchez wrote: > > >This other was not overwritten > >http://jira.codehaus.org/browse/MEV-58 > > > > > Yep, the m1 version is overwritten each time - but the m2 is only > converted when it is changed. > > So if the m1 version where edited, you might find the m2 one gets lost > which would be a problem. > > >It'd be interesting to know if the sync will override it always or > >only when there're changes to the same file in the apache repo. > >I would suggest also to turn off the syncing of poms that already > >exist in the destination because this is causing a bottleneck, > >sometimes I can't fix the poms at the source repo because I don't have > >rights. > > > This is a good point. OTOH, not fixing it at the source means that > changes at the source are never propogated, or if we improve the repo > converter to better convert existing poms we can't have it rerun over > everything. Also, if we don't ask them to fix the source repo, we have > to make the same edits next release. > > I'm not sure what the best solution is here. Do you have any thoughts? > > >Anyway I'm not sure if it's "ethic" to change the files > >without notifing the projects involved and I'm not ready to subscribe > >to hundreds of mailing lists. > > > Sure. I mailed commons-dev and didn't get any objections to me going in > and fixing things. I don't think we should have to monitor each software > project either, but creating a patch and filing it in their issue > tracker should help. We did this with dom4j, for example. > > - Brett > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
