archiva-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Deng Ching <och...@apache.org>
Subject Re: Staging repositories (was: Re: GSoC projects?)
Date Tue, 20 Apr 2010 09:26:50 GMT
+1 :)

On Mon, Apr 19, 2010 at 9:29 AM, Brett Porter <brett@apache.org> 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 <esudharaka@gmail.com
> >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>
> >
> >>
> >> 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
> > brett@apache.org
> > http://brettporter.wordpress.com/
> >
> >
> >
> >
>
> --
> Brett Porter
> brett@apache.org
> http://brettporter.wordpress.com/
>
>
>
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message