archiva-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brett Porter <br...@apache.org>
Subject Re: proposal for stage repository
Date Tue, 04 May 2010 06:50:13 GMT
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