archiva-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Deng Ching <och...@apache.org>
Subject Re: proposal for stage repository
Date Wed, 05 May 2010 04:59:38 GMT
On Wed, May 5, 2010 at 8:23 AM, Eshan Sudharaka <esudharaka@gmail.com>wrote:

> On Tue, May 4, 2010 at 12:20 PM, Brett Porter <brett@apache.org> wrote:
>
> > On 01/05/2010, at 12:57 PM, Eshan Sudharaka wrote:
> >
> > >
> >
> https://cwiki.apache.org/confluence/display/ARCHIVA/Staging+Repository+Merge
> > >
> > > It will be more useful for me to understand the missing parts and the
> > > conflicts by going through the comments.So all are warmly welcome to
> > share
> > > ideas to  make that thing a success.
> >
> > Looking good.
> >
> > Here are some more comments:
> >
> > > I think in the stage repository we should limit the access. Nobody
> should
> > allow to download the artifacts in the staging repositories other than
> the
> > developers,QA people, archiva admin user ,and the the guy who have the
> > permission for the promotion.
> > >
> > > I think it is the repository manager's task to create the stage
> > repositories and attach it to the main repository that he want to add the
> > staging functionality.
> >
> > I generally agree with this, but maybe it should be more general - those
> > might be the defaults, but it's really a matter of specifying how the
> roles
> > and permissions relate and can be assigned. Does that make sense?
> >
>
>     >>>> As i understood you mean that the permissions should be
> configurable for any use.is it ?
>

I think what Brett meant here is not specifically categorizing between QA
and developers, but more of like a generic role similar to what we currently
have -- Repository Manager and Repository Observer. It's possible that we
might not even need to add a new role for this and just add a set of new
permissions that can be assigned to the existing roles.


>
> >
> > This started to be covered in the next section, but that also talks about
> > the behaviour - maybe it would be better to rephrase these as 'stories'
> for
> > users in certain roles (this will help break it up into tasks to complete
> as
> > well).
> >
> > > If the artifact is an existing one(latest version) we need to provide
> > following options.
> >
> >
> > I'm not sure about these options. I think we can honour the current
> > repository configuration - that is either just let it replace, or block
> it
> > as not allowed to overwrite existing releases.
> >
> > > But if there are no significant changes in both artifacts then it is
> > better to remove the version 1.3 and add 1.4.
> >
> >
> > I don't think Archiva should get into this judgement call here - old
> > releases need to stay around (and the existing delete functionality is
> there
> > if there is a need to remove old things for some reason).
> >
>
> >>>  As you have mentioned there is no point of  replacing the artifacts
> for
> the new versions.(if we have version 1.2 it will be remain in the repo
> until
> we will do a re release of same 1.2) So i hope to add this replacing option
> for only a re-release in the stage repository..
>
>
+1, I think you need update the proposal to reflect this instead of using
the 1.3 and 1.4 versions example :)


>
> >
> > BTW, will merging be meaningful for snapshot repositories?
> >
>
>  >>>> as i understood for the snapshot merging is not necessary.But i need
> to clarify it from you guyz.
>

I don't think the repository merging is significant for snapshot
repositories..


>
> >
> > In the implementation, some of the above is covered and there is more
> like:
> >
> > > add the simultaneous deployment functionality for the stage
> > repositories.(here need to find a way to check with repository is busy
> with
> > being a deployment)
> >
> > This is useful but maybe a more general capability to add to Archiva in a
> > separate issue. I'd be happy to get a very basic stage/promotion
> mechanism
> > in place for this project and do it very well (then worry about new
> things
> > that can be done later). You could probably have a bit more detail on the
> > implementation in that regard as it gets into some tricky areas,
> > particularly considering multiple deployments, etc. I'd also look at
> > building it up from pieces: so define how it works here, think about how
> it
> > looks from the UI, but then when implementing get the low level merge
> > operations working first at the API/testing level, then work up to the
> user
> > interface and so on.
> >
>
>
>
> > Does that make sense?
> >
> >>>>>> you mean that first we need  to  get  the basic thing done and
then
> move for  further enhancements.
>

To help you get a better picture of what Brett meant above.. what we can
probably do is break down the implementation into smaller bits, maybe
something like this:
1. repository merge
2. web UI for merging repositories and for resolving conflicts during the
merge + integration with #1
3. security changes

For #1, I agree with what Dan said in his email to try to get the repository
merge working first with the current repository manager role then apply the
necessary roles/permissions later on once you get that core functionality
working (this is #3 above). Also, the repository merge will definitely be
implemented as a separate component from the webapp that's why it was broken
down into #1 and #2 above. This is where the tests come in. Since there is
no integration yet between the UI and the repository merge while you're
working on #1, you need to write tests for this in order to ensure that the
repository merge is working and that you've covered the different scenarios.
Once you get #1 working, you can then start implementing the web UI for the
merging (this is #2) and start integrating this with the core repository
merging functionality that you did in #1. You would also need to write
Selenium tests in #2. After you've finished the integration, make the
necessary changes in the security component (for example, add a new role or
new permission for reading and writing to the staging repository, or adding
a restriction on who can merge repositories, etc.)

Thanks,
Deng

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