Hi Eshan, Can you update the wiki directly with the changes that you specified in the attachment? The wiki is version controlled so it shouldn't be a problem to track changes made in the page.
Thanks, Deng On Thu, Apr 29, 2010 at 3:44 AM, Eshan Sudharaka <[email protected]>wrote: > hi brett, > i have added a attachment to the proposal on wiki.I need a review and then > i > am willing to edit the proposal. > link to the attachment< > https://cwiki.apache.org/confluence/pages/viewpageattachments.action?pageId=18153606&metadataLink=true > > > > thank you. > > On Wed, Apr 28, 2010 at 7:46 PM, Brett Porter <[email protected]> wrote: > > > > > On 21/04/2010, at 2:33 AM, Eshan Sudharaka wrote: > > > > > hi, > > > I just added the gsoc proposal to the apache wiki(with out doing any > > > change). > > > > > > https://cwiki.apache.org/confluence/display/ARCHIVA/Staging+Repository+Merge > > > > I cleaned up the content to use wiki syntax and remove the GSOC specifics > > (that can all be tracked separately - we just want to work on the > technical > > proposal here). I haven't made any changes to the content itself. > > > > I'd like it if you were able to make most changes to the doc based on > what > > we discuss here. There's a few posts in the thread to pick up ideas from. > > > > There's also plenty of questions to answer and adjust based on the thread > > so far: > > - are the repositories temporary or permanent, and how do they get > created? > > - how will promotion work? what different options are there? (as Deng > > pointed out, the audit logs are probably not the right approach here) > > - how does a failed deployment get cleaned up? > > - what permissions are needed exactly? > > > > I addressed my thoughts in some previous messages. But don't feel like > you > > have to agree with me - the point here is to discuss alternatives and all > > convince each other until we find the best solution. > > > > I previously posted this: > > http://people.apache.org/~brett/staging-promotion.png<http://people.apache.org/%7Ebrett/staging-promotion.png> > <http://people.apache.org/%7Ebrett/staging-promotion.png>. > > That has an assumption of permanent staging repositories - which is an > > advantage that the URL is always the same and doesn't require some > > finalisation to be active, but has a disadvantage that you might mix > > releases. One way to handle that problem is to have artifact-level > control > > of what gets promoted (which you can make smart by reading the Maven > > metadata and finding out which modules are related to each other). I > > discussed that more in the previous email. > > > > One other thing to note: repositories are not necessarily Maven 2. Things > > like Maven metadata merging should be handled by the repository API > > abstraction, rather than being baked into the code. I'm happy to help > > discuss the design of this once we get past the "user level" ideas. > > > > Cheers, > > Brett > > > > -- > > Brett Porter > > [email protected] > > http://brettporter.wordpress.com/ > > > > > > > > > > > > > -- > P.A.Eshan Sudharaka > Dept of Computer Science and Engineering > University of Moratuwa > Sri Lanka >
