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=taelJbPf4h2/Stns4+Iq3jRD05izijza/kvk0xbs9S+CZuDYRqLuqSkrvYxL9iI0vR
         ATVW5oQnEt+8DaNXmxxQr3TEzV4gYFsrAwKSOCkSft6uxFiSa+gjiCcJa/cgGvrwJr+Y
         eNx5RnlZv3ZR72ndfeYPyb1eNpPces6m9KS4M=
MIME-Version: 1.0
Sender: odeaching@gmail.com
In-Reply-To: <t2i1e57ba6c1005051644ra5cbe810o727c41c05cfaef2@mail.gmail.com>
References: <l2r1e57ba6c1004301957t8a8bfd10m450fb77d6fc4de45@mail.gmail.com>
	 <A79709A5-7635-4212-99C5-46C83620EC9D@apache.org>
	 <j2z1e57ba6c1005041723z465d72acm6bfa8e337daf813f@mail.gmail.com>
	 <g2v8667b1bd1005042159gf519a2b4i6310ab164bdafb5a@mail.gmail.com>
	 <t2i1e57ba6c1005051644ra5cbe810o727c41c05cfaef2@mail.gmail.com>
Date: Tue, 11 May 2010 16:20:41 +0800
Message-ID: <AANLkTimFhbC7OlV5sOhQwYfmt0FiltLJ8pi21in-MR28@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=001636284434800c1b04864d33ec

--001636284434800c1b04864d33ec
Content-Type: text/plain; charset=ISO-8859-1

Hi Eshan,

Thanks for updating the proposal! I also made some minor changes to it --
fixed the formatting and also some typos.
Btw, if you're having a hard time editing the wiki, there's a reference to
the Full Notation guide on the right hand side when you edit the page. It
contains the symbols/figures that you can use to format a wiki page :)

-Deng

On Thu, May 6, 2010 at 7:44 AM, Eshan Sudharaka <esudharaka@gmail.com>wrote:

> On Wed, May 5, 2010 at 10:29 AM, Deng Ching <oching@apache.org> wrote:
>
> > 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
> >
>
> >>>>
>    thanks for the explanation.It gave me a good sense about the process.I
> have edited the proposal according to the ideas here.
>
>
>
>
> --
> P.A.Eshan Sudharaka
> Dept of Computer Science and Engineering
> University of Moratuwa
> Sri Lanka
>

--001636284434800c1b04864d33ec--