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/
