On Tue, May 4, 2010 at 12:20 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? > >>>> As i understood you mean that the permissions should be configurable for any use.is it ? > > 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.. > > 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. > > 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. > > Cheers, > Brett > > -- > Brett Porter > [email protected] > http://brettporter.wordpress.com/ > > > > > -- P.A.Eshan Sudharaka Dept of Computer Science and Engineering University of Moratuwa Sri Lanka
