- Creating staging repo is same as a normal hosted repo. So repo admin will do.

- Ability to merge a repo to another repo. Again repo admin will do

- Finally, ability to clear out the entire repo should be repo admin as well.
  However this feature is dangerous since user can shoot their own foot

-Dan

On Fri, Apr 2, 2010 at 7:25 PM, Deng Ching <[email protected]> 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
>> >
>>
>

Reply via email to