On Wed, May 5, 2010 at 10:29 AM, Deng Ching <[email protected]> wrote:
> On Wed, May 5, 2010 at 8:23 AM, Eshan Sudharaka <[email protected] > >wrote: > > > 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 ? > > > > I think what Brett meant here is not specifically categorizing between QA > and developers, but more of like a generic role similar to what we > currently > have -- Repository Manager and Repository Observer. It's possible that we > might not even need to add a new role for this and just add a set of new > permissions that can be assigned to the existing roles. > > > > > > > > > > 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.. > > > > > +1, I think you need update the proposal to reflect this instead of using > the 1.3 and 1.4 versions example :) > > > > > > > > > > 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. > > > > I don't think the repository merging is significant 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? > > > > > >>>>>> you mean that first we need to get the basic thing done and > then > > move for further enhancements. > > > > To help you get a better picture of what Brett meant above.. what we can > probably do is break down the implementation into smaller bits, maybe > something like this: > 1. repository merge > 2. web UI for merging repositories and for resolving conflicts during the > merge + integration with #1 > 3. security changes > > For #1, I agree with what Dan said in his email to try to get the > repository > merge working first with the current repository manager role then apply the > necessary roles/permissions later on once you get that core functionality > working (this is #3 above). Also, the repository merge will definitely be > implemented as a separate component from the webapp that's why it was > broken > down into #1 and #2 above. This is where the tests come in. Since there is > no integration yet between the UI and the repository merge while you're > working on #1, you need to write tests for this in order to ensure that the > repository merge is working and that you've covered the different > scenarios. > Once you get #1 working, you can then start implementing the web UI for the > merging (this is #2) and start integrating this with the core repository > merging functionality that you did in #1. You would also need to write > Selenium tests in #2. After you've finished the integration, make the > necessary changes in the security component (for example, add a new role or > new permission for reading and writing to the staging repository, or adding > a restriction on who can merge repositories, etc.) > > Thanks, > Deng > >>>> thanks for the explanation.It gave me a good sense about the process.I have edited the proposal according to the ideas here. -- P.A.Eshan Sudharaka Dept of Computer Science and Engineering University of Moratuwa Sri Lanka
