On Mon, Apr 12, 2010 at 3:03 PM, Eshan Sudharaka <[email protected]>wrote:
> Hi brett, > as i understood if we create a new repo then a staging repo is > automatically created.And deployment is according to following order. > stage _ test_repo > test_repo > internal repo or snapshot repo > > I think this should be just stage_test_repo > managed repo (internal, releases, etc.)? Also, as an additional comment to this line in the proposal.. * "Here i am going to use archiva audit logs to determine what is the suitable option to follw and provide above functionalies to the user.*" I think it would be best to have a UI to present or give the user an option which artifacts he/she may merge. I don't think you would need to necessarily base it on the audit logs since their purpose are mainly for tracking changes. Thanks, Deng > On Mon, Apr 12, 2010 at 11:53 AM, Brett Porter <[email protected]> wrote: > > > > > 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/ > > > > > > > > > > > > > -- > P.A.Eshan Sudharaka > Dept of Computer Science and Engineering > University of Moratuwa > Sri Lanka >
