It looks like the wiki is back up now. Perhaps it's a good time to transfer the proposal over there and edit in some of the comments from the thread?
- Brett On 13/04/2010, at 12:26 PM, Brett Porter wrote: > > On 12/04/2010, at 6:30 PM, Deng Ching wrote: > >> 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.)? > > Yep. To better articulate what I was trying to say, maybe a diagram would > help: > http://people.apache.org/~brett/staging-promotion.png > >> >> 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. > > Yep. What I was thinking when promoting was that you'd start at a particular > artifact and if it is in a staging repository a promote button appears if you > have permission. That would bring up a page with some options: > - promote all children in the staging repository (that is, by traversing > <modules> - listed, and on by default) > - promote all dependencies / parents in the staging repository (listed, and > off by default) > > Alternatively there could be a repository option to promote the whole repo, > probably accessible from the sidebar and offering a dropdown of staging > repositories with content and which you have promote access. > > Another use case is to delete a failed deployment - the existing delete > option can be used for that, and we might talk about improving it (possibly > by reusing the above UI). > > What do others think about this? Are there other use cases? > > As an implementation detail, as much as possible should be contained to the > repository-api and a new plugin, with just the UI in the webapp. > > I'll add some further comments on the proposal later. > > - Brett > > -- > Brett Porter > [email protected] > http://brettporter.wordpress.com/ > > > > -- Brett Porter [email protected] http://brettporter.wordpress.com/
