On Mon, Apr 5, 2010 at 8:55 AM, eshan sudharaka <[email protected]>wrote:
> > As all of u guys mentioned a separate repository is a must for staging > artifacts. > Then all the registered archiva usrs have the access to that. > > In most of the companies projects are done by modular basis and those > modules are assign to developers.So i thought that tech lead should access > archiva stage repository and then assign a project location for his > group.(This location should be only access by only team members) > > once the development has done it is the tech lead's task to notify the sys > admin and ask the permision for merge the content in to common repository. > As Wendy pointed out in her previous email, Archiva currently only have 2 roles: a repository manager (read & write access to repo) and a repository observer (read access only). Will you be introducing a new set of roles and/or permissions for this? > > * Here we need to search through the common repo for the projects > which has the same name and give options to user to override them or keep > the older version on the repo. > Sounds good :) How will these options be presented to the user? > > * question : can you explain me where these kind of overriding things > are happening...is this due to merge same repo repeating ? > The blocking of re-deployments for released artifacts happens in the archiva-webdav module, particularly the ArchivaDavResourceFactory class. But given that this is different from a regular artifact deployment, I think it should be put in a separate component. > > * It is the tech lead task to release the project for the QA ppl.(Since he > is the current admin for the project on the staging repo.Developers access > should be restricted before the QA release) > > Eshan. > thank you. > Thanks, Deng > > Deng Ching-2 wrote: > > > > I agree with Dan. I think it should be kept as simple as possible.. :) > > > > In addition to what Dan listed below, I think the following should be > > addressed in the design: > > - creation of the staging repository (should it be distinguished and how > > will it be distinguished it from a regular repository?) > > - merging of the staged artifacts to the final repository > > - deletion of the staging repository (should Archiva do this after the > > merging? or should the user manually delete it?) > > - security (who will be able to promote artifacts? will the granting of > > access to the staging repo be just the same as what is currently > > implemented? or will batch assignment of permissions to a group/set of > > users > > be supported?) > > > > Thanks, > > Deng > > > > On Sat, Apr 3, 2010 at 5:25 AM, Dan Tran <[email protected]> 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 > >> > >> 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 > >> > >> I think Archiva should keep the requiment as simple as these. > >> > >> Thanks > >> > >> -Dan > >> > >> On Fri, Apr 2, 2010 at 1:47 PM, Wendy Smoak <[email protected]> wrote: > >> > (I changed the subject line so it doesn't get lost in the generic > >> discussion) > >> > > >> > On Fri, Apr 2, 2010 at 4:15 PM, eshan sudharaka <[email protected] > > > >> wrote: > >> > > >> >> * Assign a Temporory reposotory for a group.(eg : > >> com.MyTempRep.example) > >> > > >> > How do you think this should happen? Currently an admin has to create > >> > a repo and assign permissions before it can be used. > >> > > >> >> * Only they are allowed to publish artifacts and the tempo rory repo > >> is > >> only > >> >> open to them untill deploye the all artifacts to be > tested.(not > >> visible to > >> >> the common repo with have tesed modules) > >> > > >> > How would you determine that all the artifacts have been deployed? > >> > > >> >> * once the temporory reposotory is closed it should me prevented > from > >> the > >> >> developers being updating and it should be opened to QA people to > >> >> testing(Same temporory repo will be used.only acces grants should be > >> chaged > >> >> and assing the acces for the QA group) > >> > > >> > Archiva doesn't currently know anything about 'developers' vs. 'QA'. > >> > It just has users with roles like repository manager or observer. > >> > > >> > Is this something you want to introduce? > >> > > >> >> * once testing is done > if it success then merge the temp repo to > the > >> >> common repo(where the tested modules are located) > >> >> if it fails then manually removed from the repo. > >> > > >> > IMO, this is the most important part (the promotion/merge step) and it > >> > could be addressed separately from the roles/repo access part. > >> > > >> > In fact I'd like to be able to merge any two repositories, separately > >> > from any staging/promotion workflow. See > >> > http://jira.codehaus.org/browse/MRM-980 > >> > > >> >> I dont understand how the audit log is linking with this project > >> idea.could > >> >> u please explain it? > >> > > >> > The audit log needs to record all changes to the repositories. > >> > who/what/where, etc. That would apply to these staging repos as well. > >> > > >> > Unless it's already been changed, I remember the audit logging being a > >> > rather complex event driven thing. Don't get too bogged down in it if > >> > it looks scary, it probably needs to be reworked as a separate > >> > project. > >> > > >> >> and also are we need to wary about the changes that are done in the > >> >> artifacts in temporary repo (by developers).I mean whether we should > >> provide > >> >> a facility like svn diff ? > >> > > >> > Once an artifact is deployed, it should not change. (I believe > >> > Archiva already prevents re-deploying a released [non-SNAPSHOT] > >> > artifact.) So no, I don't think a diff utility is needed. > >> > > >> > -- > >> > Wendy > >> > > >> > > > > > > -- > View this message in context: > http://old.nabble.com/Staging-repositories-%28was%3A-Re%3A-GSoC-projects-%29-tp28122839p28133873.html > Sent from the archiva-dev mailing list archive at Nabble.com. > >
