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 <[email protected]> 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 > [email protected] > http://brettporter.wordpress.com/ > > > > >
