archiva-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dan Tran <dant...@gmail.com>
Subject Re: proposal for stage repository
Date Tue, 04 May 2010 07:51:53 GMT
if  basic merge feature between any 2 repositories works first using
admin repository admin role, it would be awesome.

then deliver security/access details later.

-





On Mon, May 3, 2010 at 11:50 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?
>
> 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).
>
> BTW, will merging be meaningful 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?
>
> Cheers,
> Brett
>
> --
> Brett Porter
> brett@apache.org
> http://brettporter.wordpress.com/
>
>
>
>
>

Mime
View raw message