Mailing-List: contact dev-help@archiva.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@archiva.apache.org
Received-SPF: pass (nike.apache.org: domain of odeaching@gmail.com designates
 209.85.221.200 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=mime-version:sender:in-reply-to:references:date
         :x-google-sender-auth:message-id:subject:from:to:content-type;
        b=aAQD86FiSfN7Lb9ILgHW3TKV+GxWLOWIpURkz1BTlMMif0RT92OX45P+JJZdNTnc4+
         qBVsvtgQm6R1jbTIWIMaSCHJ+muRc5rWYjhSHgJRJn7OTee+cxY94Vk3g/G9yj67rG/h
         Pfoav4yO2KZAaFehHV809PfKgUC7ag+NjSfRY=
MIME-Version: 1.0
Sender: odeaching@gmail.com
In-Reply-To: <j2z1e57ba6c1005041723z465d72acm6bfa8e337daf813f@mail.gmail.com>
References: <l2r1e57ba6c1004301957t8a8bfd10m450fb77d6fc4de45@mail.gmail.com>
	 <A79709A5-7635-4212-99C5-46C83620EC9D@apache.org>
	 <j2z1e57ba6c1005041723z465d72acm6bfa8e337daf813f@mail.gmail.com>
Date: Wed, 5 May 2010 12:59:38 +0800
Message-ID: <g2v8667b1bd1005042159gf519a2b4i6310ab164bdafb5a@mail.gmail.com>
Subject: Re: proposal for stage repository
From: Deng Ching <oching@apache.org>
To: dev@archiva.apache.org
Content-Type: multipart/alternative; boundary=001485f91b2a74febe0485d1b193

--001485f91b2a74febe0485d1b193
Content-Type: text/plain; charset=ISO-8859-1

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

--001485f91b2a74febe0485d1b193--