Re: New JIRA component for observation
hi chetan i don't really see the problem with the big amount of issues inside the 'core' module. on a regular basis i look at unassigned issues and those without a component to see if there is anything in there that i missed. from a consumer point of view though i see a lot of benefit of having the structure aligned with svn because you don't have to wonder where to put stuff. kind regards angela On 29/03/17 08:02, "Chetan Mehrotra" wrote: >Not sure if we should have a 1-1 mapping between JIRA Component and >Module at svn level. We can create logical components and later align >them as and when new modules are carved out. If required JIRA >components can be merged and renamed easily. > >As said having specific JIRA component for some logical feature set in >Oak allows better tracking and discovery of logged issues which is >harder with current set where "core" component has lots of different >types of issues clubbed together >Chetan Mehrotra > > >On Tue, Mar 28, 2017 at 12:32 PM, Angela Schreiber >wrote: >> i agree with marcel. >> in general i would rather move forward with the modularisation and then >> adjust jira accordingly. >> >> kind regards >> angela >> >> On 27/03/17 09:26, "Marcel Reutegger" wrote: >> >>>Hi, >>> >>>I'm wondering if this is the best approach. Initially we used the JIRA >>>component 1:1 for modules we have in SVN. Now we also use them for >>>sub-modules like 'documentmk', 'mongomk', 'property-index', ... >>> >>>In my view this indicates that the existing modules should probably be >>>split and we'd be back to a 1:1 relation between modules in SVN and >>>components in JIRA. Alternatively, we could also use JIRA labels and >>>group issues by features like observation. >>> >>>Regards >>> Marcel >>> >>>On 27/03/17 07:57, Chetan Mehrotra wrote: I analyzed the issues currently logged under component "core" which has ~100 issues. Looking at most issues I think we can do following 1. Create a new component for observation issues i.e. "observation" 2. Avoid marking same issue for multiple component like "documentmk and core" unless the change impacts code base outside of that component like in this case outside of documentmk package This would ensure that we can get some better sense out of issues currently clubbed under "core" Thoughts? Chetan Mehrotra >>
Re: New JIRA component for observation
Not sure if we should have a 1-1 mapping between JIRA Component and Module at svn level. We can create logical components and later align them as and when new modules are carved out. If required JIRA components can be merged and renamed easily. As said having specific JIRA component for some logical feature set in Oak allows better tracking and discovery of logged issues which is harder with current set where "core" component has lots of different types of issues clubbed together Chetan Mehrotra On Tue, Mar 28, 2017 at 12:32 PM, Angela Schreiber wrote: > i agree with marcel. > in general i would rather move forward with the modularisation and then > adjust jira accordingly. > > kind regards > angela > > On 27/03/17 09:26, "Marcel Reutegger" wrote: > >>Hi, >> >>I'm wondering if this is the best approach. Initially we used the JIRA >>component 1:1 for modules we have in SVN. Now we also use them for >>sub-modules like 'documentmk', 'mongomk', 'property-index', ... >> >>In my view this indicates that the existing modules should probably be >>split and we'd be back to a 1:1 relation between modules in SVN and >>components in JIRA. Alternatively, we could also use JIRA labels and >>group issues by features like observation. >> >>Regards >> Marcel >> >>On 27/03/17 07:57, Chetan Mehrotra wrote: >>> I analyzed the issues currently logged under component "core" which >>> has ~100 issues. Looking at most issues I think we can do following >>> >>> 1. Create a new component for observation issues i.e. "observation" >>> 2. Avoid marking same issue for multiple component like "documentmk >>> and core" unless the change impacts code base outside of that >>> component like in this case outside of documentmk package >>> >>> This would ensure that we can get some better sense out of issues >>> currently clubbed under "core" >>> >>> Thoughts? >>> >>> Chetan Mehrotra >>> >
Cassandra as NodeStore
Hello guys, I'm currently assessing Oak as an alternative for content management on my cloud product. However, I already have a Cassandra cluster as the main persistence technology and to go additionally with Mongo would turn out in more complexity in terms of manteinance and support. So, have you ever consider Cassandra as an alternative to Mongo for node storing?. I'd be willing to tackle the implementation of such a plugin but I'd like to know if you find any drawbacks in advance. Perhaps you've already tried it and stumbled across with blocking issues. For instance, I'd be concern with Cassandra's eventual consistency. Thanks in adance for considering this. Regards, Juanjo -- Juan José Vázquez Delgado CTO Tecsisa C/Quintanavides, 19 Parque Vía Norte Edificio 4, Planta 3, Oficina H 28050 Madrid T: +34 91 182 04 70 F: +34 91 447 05 11 E: juanjo.vazquez.delg...@tecsisa.com W: www.tecsisa.com
Re: [VOTE] Release Apache Jackrabbit Oak 1.0.38
On 2017-03-28 14:33, Dominique Jaeggi wrote: ... [X] +1 Release this package as Apache Jackrabbit Oak 1.0.38 Best regards, Julian
Re: [VOTE] Release Apache Jackrabbit Oak 1.0.38
[X] +1 Release this package as Apache Jackrabbit Oak 1.0.38 all checks pass. Regards, Tommaso Il giorno mar 28 mar 2017 alle ore 15:13 Alex Parvulescu < alex.parvule...@gmail.com> ha scritto: > [X] +1 Release this package as Apache Jackrabbit Oak 1.0.38 > > all checks ok, > > alex > > > On Tue, Mar 28, 2017 at 2:33 PM, Dominique Jaeggi wrote: > > > A candidate for the Jackrabbit Oak 1.0.38 release is available at: > > > > https://dist.apache.org/repos/dist/dev/jackrabbit/oak/1.0.38/ > > > > The release candidate is a zip archive of the sources in: > > > > https://svn.apache.org/repos/asf/jackrabbit/oak/tags/ > > jackrabbit-oak-1.0.38/ > > > > The SHA1 checksum of the archive is > > f5e8e98900f2464d84d730551f6d30c309155aa5. > > > > A staged Maven repository is available for review at: > > > > https://repository.apache.org/ > > > > The command for running automated checks against this release candidate > is: > > > > $ sh check-release.sh oak 1.0.38 f5e8e98900f2464d84d730551f6d30 > > c309155aa5 > > > > Please vote on releasing this package as Apache Jackrabbit Oak 1.0.38. > > The vote is open for the next 72 hours and passes if a majority of at > > least three +1 Jackrabbit PMC votes are cast. > > > > [ ] +1 Release this package as Apache Jackrabbit Oak 1.0.38 > > > > [ ] -1 Do not release this package because... > > > > My vote is +1. > > > > Thanks > > dom. > > >
Re: [VOTE] Release Apache Jackrabbit Oak 1.0.38
[X] +1 Release this package as Apache Jackrabbit Oak 1.0.38 all checks ok, alex On Tue, Mar 28, 2017 at 2:33 PM, Dominique Jaeggi wrote: > A candidate for the Jackrabbit Oak 1.0.38 release is available at: > > https://dist.apache.org/repos/dist/dev/jackrabbit/oak/1.0.38/ > > The release candidate is a zip archive of the sources in: > > https://svn.apache.org/repos/asf/jackrabbit/oak/tags/ > jackrabbit-oak-1.0.38/ > > The SHA1 checksum of the archive is > f5e8e98900f2464d84d730551f6d30c309155aa5. > > A staged Maven repository is available for review at: > > https://repository.apache.org/ > > The command for running automated checks against this release candidate is: > > $ sh check-release.sh oak 1.0.38 f5e8e98900f2464d84d730551f6d30 > c309155aa5 > > Please vote on releasing this package as Apache Jackrabbit Oak 1.0.38. > The vote is open for the next 72 hours and passes if a majority of at > least three +1 Jackrabbit PMC votes are cast. > > [ ] +1 Release this package as Apache Jackrabbit Oak 1.0.38 > > [ ] -1 Do not release this package because... > > My vote is +1. > > Thanks > dom. >
Re: Backport of OAK-4933 to 1.6
Hi, I wasn’t aware that “releasing independently” is an option, and maybe even desired for future modules. This is currently proposed on https://issues.apache.org/jira/browse/OAK-4933. If you have input on how to make it successful, please add your input there (I’d be interested in the lessons learned from the previous attempt, which I understand it was related to segment-tar). Thanks, Raul On 28/03/2017, 11:54, "Angela Schreiber" wrote: i was about to write pretty much the same thing :-) regards angela On 28/03/17 09:09, "Michael Dürig" wrote: > >As this is a new feature I would be interested in the motivation for >having to backport this. Generally we should only backport fixes for >defects. > >As Marcel mentions on the issue a better approach would be to release >this independently. If this is blocked by dependencies we should make an >effort to sort this out, as now is the time in the release cycle for >doing so. > >So for now -1 from my side to back porting this until > >a) we have a clear picture of the alternatives and >b) in the case of backporting, understand how we would ensure quality. >This is new code that was so far never exposed to the level of testing >people would expect from 1.6 code. > >Michael > >On 27.03.17 11:21, Raul-Nicolae Hudea wrote: >> Hi, >> >> I would like to backport OAK-4933 to 1.6. The impact should be minimal >>since the changes are about bringing the AzureBlobStore connector to 1.6. >> >> Changes are: >> - new module >> - changes in oak-run to support the azure data store >> >> Thanks, >> Raul >> >>
[VOTE] Release Apache Jackrabbit Oak 1.0.38
A candidate for the Jackrabbit Oak 1.0.38 release is available at: https://dist.apache.org/repos/dist/dev/jackrabbit/oak/1.0.38/ The release candidate is a zip archive of the sources in: https://svn.apache.org/repos/asf/jackrabbit/oak/tags/jackrabbit-oak-1.0.38/ The SHA1 checksum of the archive is f5e8e98900f2464d84d730551f6d30c309155aa5. A staged Maven repository is available for review at: https://repository.apache.org/ The command for running automated checks against this release candidate is: $ sh check-release.sh oak 1.0.38 f5e8e98900f2464d84d730551f6d30c309155aa5 Please vote on releasing this package as Apache Jackrabbit Oak 1.0.38. The vote is open for the next 72 hours and passes if a majority of at least three +1 Jackrabbit PMC votes are cast. [ ] +1 Release this package as Apache Jackrabbit Oak 1.0.38 [ ] -1 Do not release this package because... My vote is +1. Thanks dom.
Re: problem on oak jcr sql2 query
Hi Francesco, do you have other indexes within your Oak repo ? It might be that the query engine selects a different index which only acts on [nt:file] nodes. You can try checking the plan [1] for your query and compare with the [nt:base] version. It might also be useful to enable debug logging for org.apache.jackrabbit.oak.query, that will allow you to check the costs associated to each index so that it should be easier to eventually tweak the index definitions accordingly (note that the query engine selects the index with the lowest cost), e.g. you should see something like: ... cost for solr is 1.4 cost for lucene is 1.2 cost for reference is Infinity ... Regards, Tommaso [1] : http://jackrabbit.apache.org/oak/docs/query/query-troubleshooting.html#Query_Plan Il giorno mar 28 mar 2017 alle ore 12:28 Ancona Francesco < francesco.anc...@siav.it> ha scritto: > We have wrapped oak jcr implementation with our data model, so it's not so > easy give you our unit test (our sw is not yet open sourece :-)) > Besides we know the documenti is correctly indexed, cause we see it in > solr; so you can use any type of pdf: oak manage full text correctly. > > Anyway we tried to use a query like this to optimize performance: > SELECT parent.* FROM [nt:file] AS parent INNER JOIN [nt:resource] AS child > ON ISCHILDNODE(child,parent) WHERE CONTAINS(child.*, ' company') or > CONTAINS(parent.*, ' company') > > But we saw that index planner doesn't permit solr query (oak doesn't use > solr for the query). So we can't find words inside content (nt:resource) > > What is wrong ? > Why oak doesn't use solr for full text query ? > > Thanks in advance, > best regards > > -Messaggio originale- > Da: Tommaso Teofili [mailto:tomm...@apache.org] > Inviato: martedì 28 marzo 2017 10:33 > A: oak-dev@jackrabbit.apache.org > Cc: Diquigiovanni Simone > Oggetto: Re: problem on oak jcr sql2 query > > Hi Francesco, > > Il giorno lun 27 mar 2017 alle ore 08:59 Ancona Francesco < > francesco.anc...@siav.it> ha scritto: > > Sorry. > > We are using Oak 1.4.10 and solr 4.10.4 > > i send you also a pdf example: the searched word is "sezione" > > > attachments do not usually get through the mailing list therefore we can't > look into it. > > > > In another document ([nt:file] that doesn't have childs) i'd want match > only through metadata that contains the word "company" > > Actually i resolved the problem executing a query like this: select p.* > from [nt:base] as p where .. contains (p.*, "company") or contains > (p.*, "sezione") > > Then i explore (programmatically and after the query response) jcr nodes > to set only nodes that are [nt:file] > > Is it the correct approach ? > > > this can work but it's surely worse in terms of performance as you > retrieve and skip some docs you don't really need. > If you can provide the PDF via a link or, better, a unit test we can > probably help you more effectively. > > Regards, > Tommaso > > > > Thanks in advance, > best regards > > -Messaggio originale- > Da: Tommaso Teofili [mailto:tommaso.teof...@gmail.com] > Inviato: venerdì 24 marzo 2017 14:56 > A: oak-dev@jackrabbit.apache.org > Cc: Diquigiovanni Simone > Oggetto: Re: problem on oak jcr sql2 query > > It'd be helpful to also know the version of Oak and Solr you're using and, > possibly, sample content you expect the query to match. > > Thanks, > Tommaso > > > Il giorno ven 24 mar 2017 alle ore 14:54 Thomas Mueller > ha scritto: > > > Could you post the index definition please? > > > > > > From: Ancona Francesco > > Reply-To: "oak-dev@jackrabbit.apache.org" > > > > Date: Thursday, 23 March 2017 at 15:19 > > To: "oak-dev@jackrabbit.apache.org" > > Cc: Diquigiovanni Simone > > Subject: problem on oak jcr sql2 query > > > > Hi all, > > we use SolrSrerver for fulltext searches; both on metadata both on > > content binary. > > In general i have to find all nodes nt:file that contain the word > > “company” or all nodes that have childs nt:resource that contain the > > same word. > > > > Unfortunately if upload e file (so a node that is a nt:resource) and i > > use this query SELECT p.* FROM [nt:file] as p where > > contains(p.*,''company ') > > > > Solr find result but the RowIterator doesn’t return anything. > > > > Instead the above query works > > SELECT p.* FROM [nt:resource] as p where contains(p.*,'company') But > > doesn’t find nt:file nodes > > > > Can you help me ? > > > > Thanks in advance. > > > > > > [cid:image002.png@01D2A3E8.D7747740] > > Francesco Ancona | Software Dev. Dept. (SP) - Software Architect tel. > > +39 049 8979797 <049%20897%209797> <049%20897%209797> > <049%20897%209797> | fax +39 049 > 8978800 <049%20897%208800> > > <049%20897%208800> | cel. +39 3299060325 <329%20906%200325> > <329%20906%200325> > <329%20906%200325> > > e-mail: francesco.anc...@siav.it | www.siav.it< > > https://na01.safelinks.protection.outlook.com/?url=www.siav.it&data=02 > > %7C01%7C%7Caed3cadf483741e2971708d471f7b284%7Cfa7b1b
R: problem on oak jcr sql2 query
We have wrapped oak jcr implementation with our data model, so it's not so easy give you our unit test (our sw is not yet open sourece :-)) Besides we know the documenti is correctly indexed, cause we see it in solr; so you can use any type of pdf: oak manage full text correctly. Anyway we tried to use a query like this to optimize performance: SELECT parent.* FROM [nt:file] AS parent INNER JOIN [nt:resource] AS child ON ISCHILDNODE(child,parent) WHERE CONTAINS(child.*, ' company') or CONTAINS(parent.*, ' company') But we saw that index planner doesn't permit solr query (oak doesn't use solr for the query). So we can't find words inside content (nt:resource) What is wrong ? Why oak doesn't use solr for full text query ? Thanks in advance, best regards -Messaggio originale- Da: Tommaso Teofili [mailto:tomm...@apache.org] Inviato: martedì 28 marzo 2017 10:33 A: oak-dev@jackrabbit.apache.org Cc: Diquigiovanni Simone Oggetto: Re: problem on oak jcr sql2 query Hi Francesco, Il giorno lun 27 mar 2017 alle ore 08:59 Ancona Francesco < francesco.anc...@siav.it> ha scritto: Sorry. We are using Oak 1.4.10 and solr 4.10.4 i send you also a pdf example: the searched word is "sezione" attachments do not usually get through the mailing list therefore we can't look into it. In another document ([nt:file] that doesn't have childs) i'd want match only through metadata that contains the word "company" Actually i resolved the problem executing a query like this: select p.* from [nt:base] as p where .. contains (p.*, "company") or contains (p.*, "sezione") Then i explore (programmatically and after the query response) jcr nodes to set only nodes that are [nt:file] Is it the correct approach ? this can work but it's surely worse in terms of performance as you retrieve and skip some docs you don't really need. If you can provide the PDF via a link or, better, a unit test we can probably help you more effectively. Regards, Tommaso Thanks in advance, best regards -Messaggio originale- Da: Tommaso Teofili [mailto:tommaso.teof...@gmail.com] Inviato: venerdì 24 marzo 2017 14:56 A: oak-dev@jackrabbit.apache.org Cc: Diquigiovanni Simone Oggetto: Re: problem on oak jcr sql2 query It'd be helpful to also know the version of Oak and Solr you're using and, possibly, sample content you expect the query to match. Thanks, Tommaso Il giorno ven 24 mar 2017 alle ore 14:54 Thomas Mueller ha scritto: > Could you post the index definition please? > > > From: Ancona Francesco > Reply-To: "oak-dev@jackrabbit.apache.org" > > Date: Thursday, 23 March 2017 at 15:19 > To: "oak-dev@jackrabbit.apache.org" > Cc: Diquigiovanni Simone > Subject: problem on oak jcr sql2 query > > Hi all, > we use SolrSrerver for fulltext searches; both on metadata both on > content binary. > In general i have to find all nodes nt:file that contain the word > “company” or all nodes that have childs nt:resource that contain the > same word. > > Unfortunately if upload e file (so a node that is a nt:resource) and i > use this query SELECT p.* FROM [nt:file] as p where > contains(p.*,''company ') > > Solr find result but the RowIterator doesn’t return anything. > > Instead the above query works > SELECT p.* FROM [nt:resource] as p where contains(p.*,'company') But > doesn’t find nt:file nodes > > Can you help me ? > > Thanks in advance. > > > [cid:image002.png@01D2A3E8.D7747740] > Francesco Ancona | Software Dev. Dept. (SP) - Software Architect tel. > +39 049 8979797 <049%20897%209797> <049%20897%209797> | fax +39 049 8978800 <049%20897%208800> > <049%20897%208800> | cel. +39 3299060325 <329%20906%200325> <329%20906%200325> > e-mail: francesco.anc...@siav.it | www.siav.it< > https://na01.safelinks.protection.outlook.com/?url=www.siav.it&data=02 > %7C01%7C%7Caed3cadf483741e2971708d471f7b284%7Cfa7b1b5a7b34438794aed2c1 > 78decee1%7C0%7C0%7C636258756051666135&sdata=GFXjC%2BgyoIh37AXmGYhYdORt > Xp1dFiA5v0hoghgbtBw%3D&reserved=0 > > > > I contenuti di questa e-mail e dei suoi allegati sono confidenziali e > riservati esclusivamente ai destinatari. > L'utilizzo per qualunque fine del presente messaggio e degli allegati > così come la relativa divulgazione senza l'autorizzazione del mittente > sono vietati. > Se avete ricevuto questa e-mail per errore, vi preghiamo di > distruggerla e di comunicarcelo. > I dati personali sono trattati esclusivamente per le finalità della > presente comunicazione in conformità con la legislazione vigente (D.lgs. > 196/2003 "Codice Privacy"). > Per informazioni: SIAV S.p.A. – s...@siav.it – 049 8979797 <049%20897%209797> > <049%20897%209797> > > The contents of this e-mail and its attachments are confidential and > reserved exclusively to the recipients. > The use for any purpose of this message and attachments as well as its > disclosure without the consent of the sender is prohibited. > If you have received this email in error, please destroy it and notify us.
Re: Backport of OAK-4933 to 1.6
i was about to write pretty much the same thing :-) regards angela On 28/03/17 09:09, "Michael Dürig" wrote: > >As this is a new feature I would be interested in the motivation for >having to backport this. Generally we should only backport fixes for >defects. > >As Marcel mentions on the issue a better approach would be to release >this independently. If this is blocked by dependencies we should make an >effort to sort this out, as now is the time in the release cycle for >doing so. > >So for now -1 from my side to back porting this until > >a) we have a clear picture of the alternatives and >b) in the case of backporting, understand how we would ensure quality. >This is new code that was so far never exposed to the level of testing >people would expect from 1.6 code. > >Michael > >On 27.03.17 11:21, Raul-Nicolae Hudea wrote: >> Hi, >> >> I would like to backport OAK-4933 to 1.6. The impact should be minimal >>since the changes are about bringing the AzureBlobStore connector to 1.6. >> >> Changes are: >> - new module >> - changes in oak-run to support the azure data store >> >> Thanks, >> Raul >> >>
Re: problem on oak jcr sql2 query
Hi Francesco, Il giorno lun 27 mar 2017 alle ore 08:59 Ancona Francesco < francesco.anc...@siav.it> ha scritto: Sorry. We are using Oak 1.4.10 and solr 4.10.4 i send you also a pdf example: the searched word is "sezione" attachments do not usually get through the mailing list therefore we can't look into it. In another document ([nt:file] that doesn't have childs) i'd want match only through metadata that contains the word "company" Actually i resolved the problem executing a query like this: select p.* from [nt:base] as p where .. contains (p.*, "company") or contains (p.*, "sezione") Then i explore (programmatically and after the query response) jcr nodes to set only nodes that are [nt:file] Is it the correct approach ? this can work but it's surely worse in terms of performance as you retrieve and skip some docs you don't really need. If you can provide the PDF via a link or, better, a unit test we can probably help you more effectively. Regards, Tommaso Thanks in advance, best regards -Messaggio originale- Da: Tommaso Teofili [mailto:tommaso.teof...@gmail.com] Inviato: venerdì 24 marzo 2017 14:56 A: oak-dev@jackrabbit.apache.org Cc: Diquigiovanni Simone Oggetto: Re: problem on oak jcr sql2 query It'd be helpful to also know the version of Oak and Solr you're using and, possibly, sample content you expect the query to match. Thanks, Tommaso Il giorno ven 24 mar 2017 alle ore 14:54 Thomas Mueller ha scritto: > Could you post the index definition please? > > > From: Ancona Francesco > Reply-To: "oak-dev@jackrabbit.apache.org" > > Date: Thursday, 23 March 2017 at 15:19 > To: "oak-dev@jackrabbit.apache.org" > Cc: Diquigiovanni Simone > Subject: problem on oak jcr sql2 query > > Hi all, > we use SolrSrerver for fulltext searches; both on metadata both on > content binary. > In general i have to find all nodes nt:file that contain the word > “company” or all nodes that have childs nt:resource that contain the > same word. > > Unfortunately if upload e file (so a node that is a nt:resource) and i > use this query SELECT p.* FROM [nt:file] as p where > contains(p.*,''company ') > > Solr find result but the RowIterator doesn’t return anything. > > Instead the above query works > SELECT p.* FROM [nt:resource] as p where contains(p.*,'company') But > doesn’t find nt:file nodes > > Can you help me ? > > Thanks in advance. > > > [cid:image002.png@01D2A3E8.D7747740] > Francesco Ancona | Software Dev. Dept. (SP) - Software Architect tel. > +39 049 8979797 <049%20897%209797> <049%20897%209797> | fax +39 049 8978800 <049%20897%208800> > <049%20897%208800> | cel. +39 3299060325 <329%20906%200325> <329%20906%200325> > e-mail: francesco.anc...@siav.it | www.siav.it< > https://na01.safelinks.protection.outlook.com/?url=www.siav.it&data=02 > %7C01%7C%7Caed3cadf483741e2971708d471f7b284%7Cfa7b1b5a7b34438794aed2c1 > 78decee1%7C0%7C0%7C636258756051666135&sdata=GFXjC%2BgyoIh37AXmGYhYdORt > Xp1dFiA5v0hoghgbtBw%3D&reserved=0 > > > > I contenuti di questa e-mail e dei suoi allegati sono confidenziali e > riservati esclusivamente ai destinatari. > L'utilizzo per qualunque fine del presente messaggio e degli allegati > così come la relativa divulgazione senza l'autorizzazione del mittente > sono vietati. > Se avete ricevuto questa e-mail per errore, vi preghiamo di > distruggerla e di comunicarcelo. > I dati personali sono trattati esclusivamente per le finalità della > presente comunicazione in conformità con la legislazione vigente (D.lgs. > 196/2003 "Codice Privacy"). > Per informazioni: SIAV S.p.A. – s...@siav.it – 049 8979797 <049%20897%209797> > <049%20897%209797> > > The contents of this e-mail and its attachments are confidential and > reserved exclusively to the recipients. > The use for any purpose of this message and attachments as well as its > disclosure without the consent of the sender is prohibited. > If you have received this email in error, please destroy it and notify us. > Personal data shall be processed solely for the purposes of this > notice in accordance with current legislation (Legislative Decree no. > 196/2003 "Code"). > For more information: SIAV S.p.A. – s...@siav.it – 049 8979797 <049%20897%209797> > <049%20897%209797> > > This footnote confirms that this email message has been scanned by PineApp Mail-SeCure for the presence of malicious code, vandals & computer viruses.
Re: Documenting enhancements done in Oak 1.6
hi chetan On 24/03/17 07:11, "Chetan Mehrotra" wrote: >On Thu, Mar 23, 2017 at 10:19 PM, Angela Schreiber >wrote: >> i have been working on should already >> be included in the documentation because i try to do that before i >>resolve >> the issue. > >Thats much better! What we can do is mark such new stuff with `@since >Oak 1.6` that should be the case. >and then refer to them via links in main page. Would start a >draft work here for docs I know and you can your doc links there. sure :-) kind regards angela > > >Chetan Mehrotra
Re: Backport of OAK-4933 to 1.6
As this is a new feature I would be interested in the motivation for having to backport this. Generally we should only backport fixes for defects. As Marcel mentions on the issue a better approach would be to release this independently. If this is blocked by dependencies we should make an effort to sort this out, as now is the time in the release cycle for doing so. So for now -1 from my side to back porting this until a) we have a clear picture of the alternatives and b) in the case of backporting, understand how we would ensure quality. This is new code that was so far never exposed to the level of testing people would expect from 1.6 code. Michael On 27.03.17 11:21, Raul-Nicolae Hudea wrote: Hi, I would like to backport OAK-4933 to 1.6. The impact should be minimal since the changes are about bringing the AzureBlobStore connector to 1.6. Changes are: - new module - changes in oak-run to support the azure data store Thanks, Raul
Re: New JIRA component for observation
i agree with marcel. in general i would rather move forward with the modularisation and then adjust jira accordingly. kind regards angela On 27/03/17 09:26, "Marcel Reutegger" wrote: >Hi, > >I'm wondering if this is the best approach. Initially we used the JIRA >component 1:1 for modules we have in SVN. Now we also use them for >sub-modules like 'documentmk', 'mongomk', 'property-index', ... > >In my view this indicates that the existing modules should probably be >split and we'd be back to a 1:1 relation between modules in SVN and >components in JIRA. Alternatively, we could also use JIRA labels and >group issues by features like observation. > >Regards > Marcel > >On 27/03/17 07:57, Chetan Mehrotra wrote: >> I analyzed the issues currently logged under component "core" which >> has ~100 issues. Looking at most issues I think we can do following >> >> 1. Create a new component for observation issues i.e. "observation" >> 2. Avoid marking same issue for multiple component like "documentmk >> and core" unless the change impacts code base outside of that >> component like in this case outside of documentmk package >> >> This would ensure that we can get some better sense out of issues >> currently clubbed under "core" >> >> Thoughts? >> >> Chetan Mehrotra >>
