On 12/04/2010, at 3:25 PM, Eshan Sudharaka wrote: > hi Brett, > i have already posted my proposal to the gsoc site.Could you please check it > and if there are any unclear parts or conflicts things please let me > inform.I saw deng has already put comment on it.
Yes, I've seen it - but not everyone on this list can :) I thought it might be best to summarise here instead (or on the wiki when it is back up). My main comments would be the same as below - I'd like there to be at least one staging repo per managed repo and minimal admin work. For permissions, I'm not sure we need new ones, just separate ones for staging & managed resources (when the wiki is back up, I can point to the document that says what roles, permissions and resources are). As an example, say you have repo "releases" and attached repo "releases-staged". There's no need to block read access to stage - you can give out the normal repo read permission (and limit it to QAs or keep it as the same as the main repo). Whoever has write perms to releases-staged can stage a release, whoever has write permissions to releases can promote a release. I would say write permissions to "releases" implies r/w permissions to "releases-staged", but nothing else is implied. - Brett > > On Mon, Apr 12, 2010 at 10:15 AM, Brett Porter <[email protected]> wrote: > >> Any further thoughts on this? Eshan, could you perhaps summarise your >> proposal so far with the comments incorporated? Unfortunately, our wiki is >> still down which is the normal place to document the current state between >> discussions, but we can continue using the mailing list in the mean time. >> >> On 06/04/2010, at 1:36 PM, Brett Porter wrote: >> >>> >>> On 03/04/2010, at 8:25 AM, Dan Tran wrote: >>> >>>> From a build admin perspective, this what I would like to have: >>>> >>>> >>>> 1. Create a permanent staging repository on archiva where I can >>>> release/deploy all my projects one at the time. >>>> >>>> I can have multiple staging repos so that I can release multiple >>>> project at the same time >>> >>> I agree to them being permanent - I'd prefer to be pointing Maven at >> deploying to a staging repository, rather an automatically creating a >> temporary one, and the staging repository should be available to Maven users >> without having to change it all the time. I think they must be attached to a >> particular managed repository, though, and this needs to be easy to do - I >> wouldn't want a lot of manual work each time and I definitely wouldn't want >> to be reconfiguring Maven for different deployments. >>> >>> This makes some sense for us since the permissions are currently aligned >> to the repositories, so we can grant a merging permission. >>> >>> The tools here should be reusable for similar use cases - for example if >> a proxy connector had a staging repository, we would be able to have an >> approval process for third party artifacts that are requested. >>> >>>> >>>> 2. Once the artifacts at a staging repos, I'd like it to merge the >>>> staging repo into the official release repo. Finally wipe out the >>>> staging repo's content >>> >>> It might be worth having the option of selecting which artifacts to merge >> (with default being all), then deleting those artifacts from the staging >> repository. >>> >>> In the future, this could be made more intelligent by grouping artifacts >> automatically for merging (by using the modules, parents and dependencies >> elements to detect related artifacts that need to be moved together). >>> >>> Cheers, >>> Brett >>> >>> -- >>> Brett Porter >>> [email protected] >>> http://brettporter.wordpress.com/ >>> >>> >>> >>> >> >> -- >> Brett Porter >> [email protected] >> http://brettporter.wordpress.com/ >> >> >> >> >> > > > -- > P.A.Eshan Sudharaka > Dept of Computer Science and Engineering > University of Moratuwa > Sri Lanka -- Brett Porter [email protected] http://brettporter.wordpress.com/
