hi, I just added the gsoc proposal to the apache wiki(with out doing any change). https://cwiki.apache.org/confluence/display/ARCHIVA/Staging+Repository+Merge
On Tue, Apr 20, 2010 at 2:56 PM, Deng Ching <[email protected]> wrote: > +1 :) > > On Mon, Apr 19, 2010 at 9:29 AM, Brett Porter <[email protected]> wrote: > > > 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<http://people.apache.org/%7Ebrett/staging-promotion.png> > <http://people.apache.org/%7Ebrett/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/ > > > > > > > > > > > -- P.A.Eshan Sudharaka Dept of Computer Science and Engineering University of Moratuwa Sri Lanka
