Hi Eshan, Thanks for updating the proposal! I also made some minor changes to it -- fixed the formatting and also some typos. Btw, if you're having a hard time editing the wiki, there's a reference to the Full Notation guide on the right hand side when you edit the page. It contains the symbols/figures that you can use to format a wiki page :)
-Deng On Thu, May 6, 2010 at 7:44 AM, Eshan Sudharaka <[email protected]>wrote: > 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 >
