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 Mon, 12 Apr 2010 08:30:30 GMT
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.)?

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.

Thanks,
Deng


> On Mon, Apr 12, 2010 at 11:53 AM, Brett Porter <brett@apache.org> wrote:
>
> >
> > On 12/04/2010, at 3:25 PM, Eshan Sudharaka wrote:
> >
> > > hi Brett,
> > > i have already posted my proposal to the gsoc site.Could you please
> check
> > it
> > > and if there are any unclear parts or conflicts things please let me
> > > inform.I saw deng has already put comment on it.
> >
> > Yes, I've seen it - but not everyone on this list can :) I thought it
> might
> > be best to summarise here instead (or on the wiki when it is back up).
> >
> > My main comments would be the same as below - I'd like there to be at
> least
> > one staging repo per managed repo and minimal admin work.
> >
> > For permissions, I'm not sure we need new ones, just separate ones for
> > staging & managed resources (when the wiki is back up, I can point to the
> > document that says what roles, permissions and resources are). As an
> > example, say you have repo "releases" and attached repo
> "releases-staged".
> > There's no need to block read access to stage - you can give out the
> normal
> > repo read permission (and limit it to QAs or keep it as the same as the
> main
> > repo). Whoever has write perms to releases-staged can stage a release,
> > whoever has write permissions to releases can promote a release. I would
> say
> > write permissions to "releases" implies r/w permissions to
> > "releases-staged", but nothing else is implied.
> >
> > - Brett
> >
> > >
> > > On Mon, Apr 12, 2010 at 10:15 AM, Brett Porter <brett@apache.org>
> wrote:
> > >
> > >> Any further thoughts on this? Eshan, could you perhaps summarise your
> > >> proposal so far with the comments incorporated? Unfortunately, our
> wiki
> > is
> > >> still down which is the normal place to document the current state
> > between
> > >> discussions, but we can continue using the mailing list in the mean
> > time.
> > >>
> > >> On 06/04/2010, at 1:36 PM, Brett Porter wrote:
> > >>
> > >>>
> > >>> On 03/04/2010, at 8:25 AM, Dan Tran 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
> > >>>
> > >>> I agree to them being permanent - I'd prefer to be pointing Maven at
> > >> deploying to a staging repository, rather an automatically creating a
> > >> temporary one, and the staging repository should be available to Maven
> > users
> > >> without having to change it all the time. I think they must be
> attached
> > to a
> > >> particular managed repository, though, and this needs to be easy to do
> -
> > I
> > >> wouldn't want a lot of manual work each time and I definitely wouldn't
> > want
> > >> to be reconfiguring Maven for different deployments.
> > >>>
> > >>> This makes some sense for us since the permissions are currently
> > aligned
> > >> to the repositories, so we can grant a merging permission.
> > >>>
> > >>> The tools here should be reusable for similar use cases - for example
> > if
> > >> a proxy connector had a staging repository, we would be able to have
> an
> > >> approval process for third party artifacts that are requested.
> > >>>
> > >>>>
> > >>>> 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
> > >>>
> > >>> It might be worth having the option of selecting which artifacts to
> > merge
> > >> (with default being all), then deleting those artifacts from the
> staging
> > >> repository.
> > >>>
> > >>> In the future, this could be made more intelligent by grouping
> > artifacts
> > >> automatically for merging (by using the modules, parents and
> > dependencies
> > >> elements to detect related artifacts that need to be moved together).
> > >>>
> > >>> Cheers,
> > >>> Brett
> > >>>
> > >>> --
> > >>> Brett Porter
> > >>> brett@apache.org
> > >>> http://brettporter.wordpress.com/
> > >>>
> > >>>
> > >>>
> > >>>
> > >>
> > >> --
> > >> Brett Porter
> > >> brett@apache.org
> > >> http://brettporter.wordpress.com/
> > >>
> > >>
> > >>
> > >>
> > >>
> > >
> > >
> > > --
> > > P.A.Eshan Sudharaka
> > > Dept of Computer Science and Engineering
> > > University of Moratuwa
> > > Sri Lanka
> >
> > --
> > Brett Porter
> > brett@apache.org
> > http://brettporter.wordpress.com/
> >
> >
> >
> >
> >
>
>
> --
> P.A.Eshan Sudharaka
> Dept of Computer Science and Engineering
> University of Moratuwa
> Sri Lanka
>

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