I think the model is that 1) Onces you attached a LC, you cannot change the LC 2) You can detach, but you loose all your LC state 3) You cannot edit/ delete LCs if it is attached to at least once resources
--Srinath On Wed, May 2, 2012 at 9:56 AM, Senaka Fernando <[email protected]> wrote: > Hi Subash, > > On Wed, May 2, 2012 at 9:33 AM, Subash Chaturanga <[email protected]> wrote: >> >> >> >> On Wed, May 2, 2012 at 12:20 AM, Senaka Fernando <[email protected]> wrote: >>> >>> Hi guys, >>> >> Hi Senaka, >>> >>> Once something moved from one state to another (and it got copied to a >>> new location as a result), and if you try to get rid of the LC - you screwed >>> up. This is not something that needs to be fixed. Why would anyone do >>> something like that in the first place? >>> >> >> +1 for that. And then what we should do is "DISABLE" the option to remove >> or alter LC from UI when it is not in initial state. Shall we do this ? > > > Honestly, I don't think that's needed either. If someone wants to validate > this, they can implement a handler to do that and that's not a hard to do > thing either. > > Thanks, > Senaka. >> >> >> >>> >>> Thanks, >>> Senaka. >>> >>> >>> On Mon, Apr 30, 2012 at 8:44 PM, Subash Chaturanga <[email protected]> >>> wrote: >>>> >>>> >>>> >>>> On Mon, Apr 30, 2012 at 7:29 PM, Eranda Sooriyabandara <[email protected]> >>>> wrote: >>>>> >>>>> Hi Subash, >>>>> >>>>> AFAIK, We should "move the artifact from branch to trunk or just >>>>> remove it from branch." Because LC change means current LC is out of date >>>>> or >>>>> no longer valid and keeping it is redundant. Also I don't think we need a >>>>> "preserve-the-original" flag since moving to a new LC means a new start >>>>> and >>>>> we can use a warning message if it really need the user to be warned. >>>> >>>> >>>> A user detaches a LC from an already promoted governance artifact (i.e >>>> service), may be because he no longer wants it or else he doesn't want it >>>> for the moment. >>>> In that sense, we should provide an option to add a LC again (which is >>>> already we supports). Then question comes what are the acceptable >>>> expectations of the user when he create his LC again.(want to start from >>>> trunk or from recent state) . Because a user who has 10 states in his LC >>>> and he may detach the LC in 5th state. Should we force him to come from >>>> initial state (trunk). We don't know in what context they use our LCs. >>>> >>>> What I propose is, lets add a option called "attach" in the LifeCycle >>>> admin menu, which gets activate upon creating a LC. It can attach and >>>> detach >>>> itself. >>>> And LC can only be created from Add artifact UI.(i.e Add Service UI). >>>> WDYT ? I think this will give a more flexibility for the users. >>>> >>>> >>>> >>>>> >>>>> >>>>> thanks >>>>> Eranda >>>>> >>>>> On Mon, Apr 30, 2012 at 2:34 PM, Subash Chaturanga <[email protected]> >>>>> wrote: >>>>>> >>>>>> Hi all, >>>>>> >>>>>> $subject is regarding the carbon issue [1] . Here, >>>>>> >>>>>> When try to disassociate(making associated LC to None) an existing LC >>>>>> from an already promoted service (which resides in branches with a new >>>>>> version according to DefalutLC impl ) and associate the LC again, its >>>>>> state is in initial state. (now a service in branches has a LC with >>>>>> the initial state), which is WRONG. >>>>>> >>>>>> Theoretically, if the associated LC is in its initial state, the >>>>>> relevant artifact SHOULD be in trunk. So to fix the above issue, >>>>>> >>>>>> - based on the flag, preserve-the-original, we can move the artifact >>>>>> from branch to trunk or just remove it from branch. >>>>>> - or should we allow users to decide what should happen upon removing >>>>>> an already associated LC from a service (or any governance artifact). i.e >>>>>> whether they want to start the service from trunk or start from its >>>>>> recent >>>>>> state or etc ? >>>>>> >>>>>> [1] - https://wso2.org/jira/browse/CARBON-12994 >>>>>> >>>>>> Thanks >>>>>> -- >>>>>> Subash Chaturanga >>>>>> Software Engineer >>>>>> WSO2 Inc. http://wso2.com >>>>>> >>>>>> email - [email protected] >>>>>> phone - 077 2225922 >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> Dev mailing list >>>>>> [email protected] >>>>>> http://wso2.org/cgi-bin/mailman/listinfo/dev >>>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> Eranda Sooriyabandara >>>>> Software Engineer; >>>>> Integration Technologies Team; >>>>> WSO2 Inc.; http://wso2.com >>>>> >>>>> >>>>> >>>> >>>> >>>> >>>> -- >>>> >>>> Subash Chaturanga >>>> Software Engineer >>>> WSO2 Inc. http://wso2.com >>>> >>>> email - [email protected] >>>> phone - 077 2225922 >>>> >>> >>> >>> >>> -- >>> Senaka Fernando >>> Product Manager - WSO2 Governance Registry; >>> Associate Technical Lead; WSO2 Inc.; http://wso2.com >>> Member; Apache Software Foundation; http://apache.org >>> >>> E-mail: senaka AT wso2.com >>> P: +1 408 754 7388; ext: 51736; M: +94 77 322 1818 >>> Linked-In: http://linkedin.com/in/senakafernando >>> >>> Lean . Enterprise . Middleware >>> >> >> >> >> -- >> >> Subash Chaturanga >> Software Engineer >> WSO2 Inc. http://wso2.com >> >> email - [email protected] >> phone - 077 2225922 >> > > > > -- > Senaka Fernando > Product Manager - WSO2 Governance Registry; > Associate Technical Lead; WSO2 Inc.; http://wso2.com > Member; Apache Software Foundation; http://apache.org > > E-mail: senaka AT wso2.com > P: +1 408 754 7388; ext: 51736; M: +94 77 322 1818 > Linked-In: http://linkedin.com/in/senakafernando > > Lean . Enterprise . Middleware > > > _______________________________________________ > Architecture mailing list > [email protected] > https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture > -- ============================ Srinath Perera, Ph.D. http://www.cs.indiana.edu/~hperera/ http://srinathsview.blogspot.com/ _______________________________________________ Dev mailing list [email protected] http://wso2.org/cgi-bin/mailman/listinfo/dev
