Re: [ALC] Request to establish ALC in Budapest
Hello Attila, Thank you for your email. As you are aware, we have recently established the ALC Warsaw. ALC Budapest is next in the plan, soon I will start the vote for ALC Budapest in ComDev PMC. Indeed, our other ALC Chapters are having online meetups. Best regards, Swapnil M Mane, www.apache.org On Fri, Mar 27, 2020 at 9:08 PM Attila Bukor wrote: > > Hi Swapnil, > > Is there any ETA on this? I know there aren't much events we could organize > now > anyway due to social distancing, but maybe we could start with some online > meetups? > > Thanks, > Attila > > On Sat, Feb 29, 2020 at 10:44:28AM +0530, Swapnil M Mane wrote: > > Hello Attila and team, > > Thank you so much for showing your kind interest in the Apache Local > > Community (ALC) initiative [1]. > > > > Currently, the voting is underway in ComDev PMC to establish ALC Warsaw. > > We will review the ALC Budapest request after this, will keep you posted. > > > > [1] https://s.apache.org/alc > > > > Best regards, > > Swapnil M Mane, > > www.apache.org > > > > On Fri, Feb 28, 2020 at 5:04 PM Attila Bukor wrote: > > > > > > Sorry, wrong email address in CC: > > > > > > +fapi...@gmail.com > > > -fapi...@apache.org > > > On Fri, Feb 28, 2020 at 12:19:02PM +0100, Attila Bukor wrote: > > > > Hi, > > > > > > > > We'd like to establish an ALC chapter in Budapest with the following > > > > initial > > > > members (listed Apache IDs in alphabetical order where applicable, email > > > > address otherwise): > > > > > > > > - abukor (kudu-pmc, kudu) > > > > - cstamas (maven-pmc, maven) > > > > - ddekany (freemarker-pmc, freemarker, incubator, member, pmc-chairs) > > > > - fapi...@gmail.com (Hadoop, Ozone contributor) > > > > - gezapeti (oozie-pmc, oozie, pmc-chairs) > > > > - mbalassi (flink-pmc, flink, incubator) > > > > > > > > Thanks, > > > > Attila > > > > > > > > > > - > > To unsubscribe, e-mail: dev-unsubscr...@community.apache.org > > For additional commands, e-mail: dev-h...@community.apache.org > > > > - > To unsubscribe, e-mail: dev-unsubscr...@community.apache.org > For additional commands, e-mail: dev-h...@community.apache.org > - To unsubscribe, e-mail: dev-unsubscr...@community.apache.org For additional commands, e-mail: dev-h...@community.apache.org
Re: Data inconsistency in projects.apache.org
See http://incubator.apache.org/clutch/tuweni The repositories are actual and are updated from gitbox.apache.org/repositories.json The releases are from dist.apache.org/repos/dist/release and are exactly what is available. Other items on the page are either from a podling status file or other bits of information including the podlings.xml. This information can be a service to the projects and the foundation. Sent from my iPhone > On Mar 27, 2020, at 2:04 PM, Hervé BOUTEMY wrote: > > there are many more parts, see some examples of human-readable output: > https://projects.apache.org/project.html?accumulo > https://projects.apache.org/project.html?calcite > > Le vendredi 27 mars 2020, 21:44:56 CET Dave Fisher a écrit : >> metadata for project releases is discoverable from the dist in svn. It is >> already done for podlings in the Incubator in the clutch analysis. >> >> It is python. I can provide some help late next week. >> >> Sent from my iPhone > > > > > - > To unsubscribe, e-mail: dev-unsubscr...@community.apache.org > For additional commands, e-mail: dev-h...@community.apache.org >
Re: Data inconsistency in projects.apache.org
there are many more parts, see some examples of human-readable output: https://projects.apache.org/project.html?accumulo https://projects.apache.org/project.html?calcite Le vendredi 27 mars 2020, 21:44:56 CET Dave Fisher a écrit : > metadata for project releases is discoverable from the dist in svn. It is > already done for podlings in the Incubator in the clutch analysis. > > It is python. I can provide some help late next week. > > Sent from my iPhone - To unsubscribe, e-mail: dev-unsubscr...@community.apache.org For additional commands, e-mail: dev-h...@community.apache.org
Re: Data inconsistency in projects.apache.org
Le vendredi 27 mars 2020, 21:19:56 CET sebb a écrit : > > > That way, over time, we'd eventually have all of those files in one > > > place, making them easier to find and update. > > > > find = 2 files (1 for committees, 1 for projects) > > May be more than one for projects. > e.g. Commons. I was not clear, here are the 2 files: https://svn.apache.org/repos/asf/comdev/projects.apache.org/trunk/data/committees.xml https://svn.apache.org/repos/asf/comdev/projects.apache.org/trunk/data/projects.xml > > On letting PMC RDF files go outside the centralised approach, I'd be > > curious to check if the 4 PMCs that chose to host outside of projects.a.o > > did that to fill more data, or if they just felt that they'd host this > > file the same way they did with project DOAP file. > I suggest dropping them entirely. yes, I suppose the PMC RDF content could be fully extracted from other sources: the only hard part is the charter, that you seem to have already extracted automatically dropping PMC RDF files would simplify the discussion, since only project DOAP files would remain big +1: a good step in the right direction of simplification to enable us to focus on the hard part = project DOAP files Regards, Hervé - To unsubscribe, e-mail: dev-unsubscr...@community.apache.org For additional commands, e-mail: dev-h...@community.apache.org
Re: Data inconsistency in projects.apache.org
metadata for project releases is discoverable from the dist in svn. It is already done for podlings in the Incubator in the clutch analysis. It is python. I can provide some help late next week. Sent from my iPhone > On Mar 27, 2020, at 1:20 PM, sebb wrote: > > On Fri, 27 Mar 2020 at 20:01, Hervé BOUTEMY wrote: >> >> Le vendredi 27 mars 2020 20:29:14 CET, vous avez écrit : On 3/27/20 3:07 PM, Hervé BOUTEMY wrote: > It's good to see some interest back on DOAP files content ad organisation, > now that the projects.apache.org rendering makes them really useful: a > few years ago, trying to open any discussion on that was deemed to > failure. But any change is hard, since every PMC will have to be > involved. >>> >>> What if we - and I'm perfectly prepared to be told "You can't do that >>> because ..." - fetched remote (ie, project-hosted) doap files, a few at >>> a time, and move them to the central repo, and as we do that, we go talk >>> to projects individually, telling them that we're doing it, and why, and >>> what the new process is for updating. Yes, I'm volunteering to do that >>> outreach. >> you can, but I don't see the benefit of this hard work >> >>> >>> That way, over time, we'd eventually have all of those files in one >>> place, making them easier to find and update. >> find = 2 files (1 for committees, 1 for projects) > > May be more than one for projects. > e.g. Commons. > >>> >>> I'm leaving the file format question for someone else entirely. I am far >>> less concerned about that, than about ensuring that the files are easily >>> found and updated. >> my point about "PMC RDF files" vs "projects DOAP files" is not a question of >> format, but a question of amount of data and who would have real knowledge >> to update content: >> - PMC RDF files are very light, rarely updated, and contain data that are >> really foundation-centric >> - projects DOAP files contain a lot more data, can/should be often updated, >> with data that are really to be delegated to PMCs given they are more >> technical details on code >> >> That's why I really think keeping centralised PMC RDF files and >> decentralised projects DOAP files is a good idea. >> >> IMHO, centralising project DOAP files would be a hard task with low benefit, >> and even counter productive effect on having every PMC responsible for the >> content, that is technical. >> >> On letting PMC RDF files go outside the centralised approach, I'd be curious >> to check if the 4 PMCs that chose to host outside of projects.a.o did that >> to fill more data, or if they just felt that they'd host this file the same >> way they did with project DOAP file. > > I suggest dropping them entirely. > >> Regards, >> >> Hervé >> >>> >>> --Rich >> >> >> >> >> >> - >> To unsubscribe, e-mail: dev-unsubscr...@community.apache.org >> For additional commands, e-mail: dev-h...@community.apache.org >> > > - > To unsubscribe, e-mail: dev-unsubscr...@community.apache.org > For additional commands, e-mail: dev-h...@community.apache.org > - To unsubscribe, e-mail: dev-unsubscr...@community.apache.org For additional commands, e-mail: dev-h...@community.apache.org
Re: Data inconsistency in projects.apache.org
On Fri, 27 Mar 2020 at 20:01, Hervé BOUTEMY wrote: > > Le vendredi 27 mars 2020 20:29:14 CET, vous avez écrit : > > On 3/27/20 3:07 PM, Hervé BOUTEMY wrote: > > > It's good to see some interest back on DOAP files content ad organisation, > > > now that the projects.apache.org rendering makes them really useful: a > > > few years ago, trying to open any discussion on that was deemed to > > > failure. But any change is hard, since every PMC will have to be > > > involved. > > > > What if we - and I'm perfectly prepared to be told "You can't do that > > because ..." - fetched remote (ie, project-hosted) doap files, a few at > > a time, and move them to the central repo, and as we do that, we go talk > > to projects individually, telling them that we're doing it, and why, and > > what the new process is for updating. Yes, I'm volunteering to do that > > outreach. > you can, but I don't see the benefit of this hard work > > > > > That way, over time, we'd eventually have all of those files in one > > place, making them easier to find and update. > find = 2 files (1 for committees, 1 for projects) May be more than one for projects. e.g. Commons. > > > > I'm leaving the file format question for someone else entirely. I am far > > less concerned about that, than about ensuring that the files are easily > > found and updated. > my point about "PMC RDF files" vs "projects DOAP files" is not a question of > format, but a question of amount of data and who would have real knowledge to > update content: > - PMC RDF files are very light, rarely updated, and contain data that are > really foundation-centric > - projects DOAP files contain a lot more data, can/should be often updated, > with data that are really to be delegated to PMCs given they are more > technical details on code > > That's why I really think keeping centralised PMC RDF files and decentralised > projects DOAP files is a good idea. > > IMHO, centralising project DOAP files would be a hard task with low benefit, > and even counter productive effect on having every PMC responsible for the > content, that is technical. > > On letting PMC RDF files go outside the centralised approach, I'd be curious > to check if the 4 PMCs that chose to host outside of projects.a.o did that to > fill more data, or if they just felt that they'd host this file the same way > they did with project DOAP file. I suggest dropping them entirely. > Regards, > > Hervé > > > > > --Rich > > > > > > - > To unsubscribe, e-mail: dev-unsubscr...@community.apache.org > For additional commands, e-mail: dev-h...@community.apache.org > - To unsubscribe, e-mail: dev-unsubscr...@community.apache.org For additional commands, e-mail: dev-h...@community.apache.org
Re: Data inconsistency in projects.apache.org
On Fri, 27 Mar 2020 at 18:04, Rich Bowen wrote: > > > > On 3/27/20 1:13 PM, sebb wrote: > > On Fri, 27 Mar 2020 at 13:44, Rich Bowen wrote: > >> there are also lines that look like: > >> > >> http://flex.apache.org/pmc_Flex.rdf > >> > >> (4 of them, for whatever that's worth - flex, ofbiz, plc4x, and tez) > >> > >> Is that correct? Or is that not how the data is supposed to be stored? > > > > Most PMC RDF files are stored locally, but the app does allow for > > projects to store the files elsewhere. > > Awesome. So it's just an "error" in the comment in the file, not in the > way things are done. Thanks. That helps. > > > If any changes are made, I strongly recommend centralising the data files. > > DOAP files maintained in project data areas often get moved, and the > > project forgets to update the entry in projects.xml > > Also, sometimes edits to DOAP files have syntax errors. > > My experience is that it can be very hard work getting projects to fix > > errors, whereas if DOAPs were centrally located, anyone could fix > > errors. > > So, while to me that seems like an obvious and enormous improvement, my > understanding is that this was proposed before and someone (I understood > it was you?) vetoed the change. So I'm a teensy bit confused. Not me. I have always been in favour of centralising the files. > -- > Rich Bowen - rbo...@rcbowen.com > http://rcbowen.com/ > @rbowen > > - > To unsubscribe, e-mail: dev-unsubscr...@community.apache.org > For additional commands, e-mail: dev-h...@community.apache.org > - To unsubscribe, e-mail: dev-unsubscr...@community.apache.org For additional commands, e-mail: dev-h...@community.apache.org
Re: Data inconsistency in projects.apache.org
On 3/27/20 4:01 PM, Hervé BOUTEMY wrote: my point about "PMC RDF files" vs "projects DOAP files" is not a question of format, but a question of amount of data and who would have real knowledge to update content: - PMC RDF files are very light, rarely updated, and contain data that are really foundation-centric - projects DOAP files contain a lot more data, can/should be often updated, with data that are really to be delegated to PMCs given they are more technical details on code That's why I really think keeping centralised PMC RDF files and decentralised projects DOAP files is a good idea. Aha, I see. Thank you for clarifying that for me. -- Rich Bowen - rbo...@rcbowen.com http://rcbowen.com/ @rbowen - To unsubscribe, e-mail: dev-unsubscr...@community.apache.org For additional commands, e-mail: dev-h...@community.apache.org
Re: Data inconsistency in projects.apache.org
Le vendredi 27 mars 2020, 20:11:33 CET Rich Bowen a écrit : > For context, I'm trying to address Sally's complaint that the data on > projects.a.o is inconsistent, out of date, and wonky. yes, I like this objective > I am very willing > to reach out to various projects about data updates (and am doing that > already for other things - namely, the stuff on > https://whimsy.apache.org/site/) but the "where is our data" question > not having one consistent answer is a little frustrating. this is where the mix between committee oriented data vs "technical" project data starts to hurt: projects DOAP files are technical details, that are to be delegated you can see the difference by looking at Committees page https:// projects.apache.org/committees.html vs Projects page https:// projects.apache.org/projects.html that can be sorted by Category and Programming Language > > I think, though, I now know where to go to look it up. - To unsubscribe, e-mail: dev-unsubscr...@community.apache.org For additional commands, e-mail: dev-h...@community.apache.org
Re: Data inconsistency in projects.apache.org
Le vendredi 27 mars 2020 20:29:14 CET, vous avez écrit : > On 3/27/20 3:07 PM, Hervé BOUTEMY wrote: > > It's good to see some interest back on DOAP files content ad organisation, > > now that the projects.apache.org rendering makes them really useful: a > > few years ago, trying to open any discussion on that was deemed to > > failure. But any change is hard, since every PMC will have to be > > involved. > > What if we - and I'm perfectly prepared to be told "You can't do that > because ..." - fetched remote (ie, project-hosted) doap files, a few at > a time, and move them to the central repo, and as we do that, we go talk > to projects individually, telling them that we're doing it, and why, and > what the new process is for updating. Yes, I'm volunteering to do that > outreach. you can, but I don't see the benefit of this hard work > > That way, over time, we'd eventually have all of those files in one > place, making them easier to find and update. find = 2 files (1 for committees, 1 for projects) > > I'm leaving the file format question for someone else entirely. I am far > less concerned about that, than about ensuring that the files are easily > found and updated. my point about "PMC RDF files" vs "projects DOAP files" is not a question of format, but a question of amount of data and who would have real knowledge to update content: - PMC RDF files are very light, rarely updated, and contain data that are really foundation-centric - projects DOAP files contain a lot more data, can/should be often updated, with data that are really to be delegated to PMCs given they are more technical details on code That's why I really think keeping centralised PMC RDF files and decentralised projects DOAP files is a good idea. IMHO, centralising project DOAP files would be a hard task with low benefit, and even counter productive effect on having every PMC responsible for the content, that is technical. On letting PMC RDF files go outside the centralised approach, I'd be curious to check if the 4 PMCs that chose to host outside of projects.a.o did that to fill more data, or if they just felt that they'd host this file the same way they did with project DOAP file. Regards, Hervé > > --Rich - To unsubscribe, e-mail: dev-unsubscr...@community.apache.org For additional commands, e-mail: dev-h...@community.apache.org
Re: Data inconsistency in projects.apache.org
On 3/27/20 3:07 PM, Hervé BOUTEMY wrote: It's good to see some interest back on DOAP files content ad organisation, now that the projects.apache.org rendering makes them really useful: a few years ago, trying to open any discussion on that was deemed to failure. But any change is hard, since every PMC will have to be involved. What if we - and I'm perfectly prepared to be told "You can't do that because ..." - fetched remote (ie, project-hosted) doap files, a few at a time, and move them to the central repo, and as we do that, we go talk to projects individually, telling them that we're doing it, and why, and what the new process is for updating. Yes, I'm volunteering to do that outreach. That way, over time, we'd eventually have all of those files in one place, making them easier to find and update. I'm leaving the file format question for someone else entirely. I am far less concerned about that, than about ensuring that the files are easily found and updated. --Rich -- Rich Bowen - rbo...@rcbowen.com http://rcbowen.com/ @rbowen - To unsubscribe, e-mail: dev-unsubscr...@community.apache.org For additional commands, e-mail: dev-h...@community.apache.org
Re: Data inconsistency in projects.apache.org
On 3/27/20 3:07 PM, Hervé BOUTEMY wrote: It's good to see some interest back on DOAP files content ad organisation, now that the projects.apache.org rendering makes them really useful: a few years ago, trying to open any discussion on that was deemed to failure. But any change is hard, since every PMC will have to be involved. Yeah, I can totally appreciate that, as there is no convenient consistent way to get in touch with every project, and believe, with any degree of certainty, that they'll all actually see it. I'll try to find the last discussion in the archives and see what the issues were. For context, I'm trying to address Sally's complaint that the data on projects.a.o is inconsistent, out of date, and wonky. I am very willing to reach out to various projects about data updates (and am doing that already for other things - namely, the stuff on https://whimsy.apache.org/site/) but the "where is our data" question not having one consistent answer is a little frustrating. I think, though, I now know where to go to look it up. -- Rich Bowen - rbo...@rcbowen.com http://rcbowen.com/ @rbowen - To unsubscribe, e-mail: dev-unsubscr...@community.apache.org For additional commands, e-mail: dev-h...@community.apache.org
Re: Data inconsistency in projects.apache.org
On 3/27/20 2:45 PM, Hervé BOUTEMY wrote: please start by reading the human-oriented explanation: https://projects.apache.org/about.html this should ease the deep dive into data behind the recurring "Committees vs Projects" discussion Thanks. That is indeed where I started. I think where I get hung up (and where I got hung up last time) was on the way that the doap files are scattered hither and yon across the universe. :) --Rich Le vendredi 27 mars 2020, 14:43:52 CET Rich Bowen a écrit : I'm trying to understand the twisty maze of data sources that fuel projects.apache.org and either I'm confused, or there's some inconsistency in how this all fits together. I'll start with just one data source for now, so that I don't muddle multiple things together. https://svn.apache.org/repos/asf/comdev/projects.apache.org/trunk/data/commi ttees.xml This file has a list of rdf files which are supposed to be in the committees/ subdirectory. The file itself says: This list should agree with the files in the directory committees/ However, in addition to the entries that look like: committees/any23.rdf there are also lines that look like: http://flex.apache.org/pmc_Flex.rdf (4 of them, for whatever that's worth - flex, ofbiz, plc4x, and tez) Is that correct? Or is that not how the data is supposed to be stored? Meanwhile, committees.xml contains 209 projects: grep location committees.xml| grep -vc Retired 209 while the committees/ directory contains just 206 rdf files: ls committees/*.rdf| wc -l 206 (Note, one of those files is _template.rdf, so it's really 205, and 205 + 4 = 209, so at least everything else matches up.) - To unsubscribe, e-mail: dev-unsubscr...@community.apache.org For additional commands, e-mail: dev-h...@community.apache.org -- Rich Bowen - rbo...@rcbowen.com http://rcbowen.com/ @rbowen - To unsubscribe, e-mail: dev-unsubscr...@community.apache.org For additional commands, e-mail: dev-h...@community.apache.org
Re: Data inconsistency in projects.apache.org
Le vendredi 27 mars 2020, 19:04:28 CET Rich Bowen a écrit : > > If any changes are made, I strongly recommend centralising the data files. > > DOAP files maintained in project data areas often get moved, and the > > project forgets to update the entry in projects.xml > > Also, sometimes edits to DOAP files have syntax errors. > > My experience is that it can be very hard work getting projects to fix > > errors, whereas if DOAPs were centrally located, anyone could fix > > errors. > > So, while to me that seems like an obvious and enormous improvement, my > understanding is that this was proposed before and someone (I understood > it was you?) vetoed the change. So I'm a teensy bit confused. on PMC RDF files, it was fully centralised, and I see now that some PMCs chose to host externally on projects DOAP files, it is de-centralised for a long time (notice: "PMC RDF files" vs "projects DOAP files") I don't remember precisely last discussions, but I am one who wants to keep DOAP files de-centralised: my rationale is that projects DOAP files contain a lot of data that can be updated often (like releases) PMC RDF files require a lot less maintenance: keeping them centralised seemed sufficient for a long time It's good to see some interest back on DOAP files content ad organisation, now that the projects.apache.org rendering makes them really useful: a few years ago, trying to open any discussion on that was deemed to failure. But any change is hard, since every PMC will have to be involved. Regards, Hervé - To unsubscribe, e-mail: dev-unsubscr...@community.apache.org For additional commands, e-mail: dev-h...@community.apache.org
Re: Data inconsistency in projects.apache.org
please start by reading the human-oriented explanation: https://projects.apache.org/about.html this should ease the deep dive into data behind the recurring "Committees vs Projects" discussion Regards, Hervé Le vendredi 27 mars 2020, 14:43:52 CET Rich Bowen a écrit : > I'm trying to understand the twisty maze of data sources that fuel > projects.apache.org and either I'm confused, or there's some > inconsistency in how this all fits together. > > I'll start with just one data source for now, so that I don't muddle > multiple things together. > > https://svn.apache.org/repos/asf/comdev/projects.apache.org/trunk/data/commi > ttees.xml > > > This file has a list of rdf files which are supposed to be in the > committees/ subdirectory. The file itself says: > > This list should agree with the files in the directory committees/ > > However, in addition to the entries that look like: > >committees/any23.rdf > > there are also lines that look like: > >http://flex.apache.org/pmc_Flex.rdf > > (4 of them, for whatever that's worth - flex, ofbiz, plc4x, and tez) > > Is that correct? Or is that not how the data is supposed to be stored? > > Meanwhile, committees.xml contains 209 projects: > > grep location committees.xml| grep -vc Retired > 209 > > while the committees/ directory contains just 206 rdf files: > > ls committees/*.rdf| wc -l > 206 > (Note, one of those files is _template.rdf, so it's really 205, and 205 > + 4 = 209, so at least everything else matches up.) - To unsubscribe, e-mail: dev-unsubscr...@community.apache.org For additional commands, e-mail: dev-h...@community.apache.org
Re: Data inconsistency in projects.apache.org
On 3/27/20 1:13 PM, sebb wrote: On Fri, 27 Mar 2020 at 13:44, Rich Bowen wrote: there are also lines that look like: http://flex.apache.org/pmc_Flex.rdf (4 of them, for whatever that's worth - flex, ofbiz, plc4x, and tez) Is that correct? Or is that not how the data is supposed to be stored? Most PMC RDF files are stored locally, but the app does allow for projects to store the files elsewhere. Awesome. So it's just an "error" in the comment in the file, not in the way things are done. Thanks. That helps. If any changes are made, I strongly recommend centralising the data files. DOAP files maintained in project data areas often get moved, and the project forgets to update the entry in projects.xml Also, sometimes edits to DOAP files have syntax errors. My experience is that it can be very hard work getting projects to fix errors, whereas if DOAPs were centrally located, anyone could fix errors. So, while to me that seems like an obvious and enormous improvement, my understanding is that this was proposed before and someone (I understood it was you?) vetoed the change. So I'm a teensy bit confused. -- Rich Bowen - rbo...@rcbowen.com http://rcbowen.com/ @rbowen - To unsubscribe, e-mail: dev-unsubscr...@community.apache.org For additional commands, e-mail: dev-h...@community.apache.org
Re: Data inconsistency in projects.apache.org
On Fri, 27 Mar 2020 at 13:44, Rich Bowen wrote: > > I'm trying to understand the twisty maze of data sources that fuel > projects.apache.org and either I'm confused, or there's some > inconsistency in how this all fits together. > > I'll start with just one data source for now, so that I don't muddle > multiple things together. > > https://svn.apache.org/repos/asf/comdev/projects.apache.org/trunk/data/committees.xml > > > This file has a list of rdf files which are supposed to be in the > committees/ subdirectory. The file itself says: > > This list should agree with the files in the directory committees/ > > However, in addition to the entries that look like: > >committees/any23.rdf > > there are also lines that look like: > >http://flex.apache.org/pmc_Flex.rdf > > (4 of them, for whatever that's worth - flex, ofbiz, plc4x, and tez) > > Is that correct? Or is that not how the data is supposed to be stored? Most PMC RDF files are stored locally, but the app does allow for projects to store the files elsewhere. > Meanwhile, committees.xml contains 209 projects: > > grep location committees.xml| grep -vc Retired > 209 > > while the committees/ directory contains just 206 rdf files: > > ls committees/*.rdf| wc -l > 206 > (Note, one of those files is _template.rdf, so it's really 205, and 205 > + 4 = 209, so at least everything else matches up.) Some PMCs have multiple projects. There is a cron job that reports an error if there is a new PMC without a corresponding RDF file. I tend to create the the PMC RDF to silence the error. However, it is up to the PMC to create the DOAP(s), so it's possible that a PMC has no DOAPs. I suspect that the PMC RDF files could be eliminated - I think the only useful info they contain is the charter. The charter is now also maintained in: https://svn.apache.org/repos/private/committers/board/committee-info.yaml If any changes are made, I strongly recommend centralising the data files. DOAP files maintained in project data areas often get moved, and the project forgets to update the entry in projects.xml Also, sometimes edits to DOAP files have syntax errors. My experience is that it can be very hard work getting projects to fix errors, whereas if DOAPs were centrally located, anyone could fix errors. > > > -- > Rich Bowen - rbo...@rcbowen.com > http://rcbowen.com/ > @rbowen > > - > To unsubscribe, e-mail: dev-unsubscr...@community.apache.org > For additional commands, e-mail: dev-h...@community.apache.org > - To unsubscribe, e-mail: dev-unsubscr...@community.apache.org For additional commands, e-mail: dev-h...@community.apache.org
Re: [ALC] Request to establish ALC in Budapest
Hi Swapnil, Is there any ETA on this? I know there aren't much events we could organize now anyway due to social distancing, but maybe we could start with some online meetups? Thanks, Attila On Sat, Feb 29, 2020 at 10:44:28AM +0530, Swapnil M Mane wrote: > Hello Attila and team, > Thank you so much for showing your kind interest in the Apache Local > Community (ALC) initiative [1]. > > Currently, the voting is underway in ComDev PMC to establish ALC Warsaw. > We will review the ALC Budapest request after this, will keep you posted. > > [1] https://s.apache.org/alc > > Best regards, > Swapnil M Mane, > www.apache.org > > On Fri, Feb 28, 2020 at 5:04 PM Attila Bukor wrote: > > > > Sorry, wrong email address in CC: > > > > +fapi...@gmail.com > > -fapi...@apache.org > > On Fri, Feb 28, 2020 at 12:19:02PM +0100, Attila Bukor wrote: > > > Hi, > > > > > > We'd like to establish an ALC chapter in Budapest with the following > > > initial > > > members (listed Apache IDs in alphabetical order where applicable, email > > > address otherwise): > > > > > > - abukor (kudu-pmc, kudu) > > > - cstamas (maven-pmc, maven) > > > - ddekany (freemarker-pmc, freemarker, incubator, member, pmc-chairs) > > > - fapi...@gmail.com (Hadoop, Ozone contributor) > > > - gezapeti (oozie-pmc, oozie, pmc-chairs) > > > - mbalassi (flink-pmc, flink, incubator) > > > > > > Thanks, > > > Attila > > > > > > - > To unsubscribe, e-mail: dev-unsubscr...@community.apache.org > For additional commands, e-mail: dev-h...@community.apache.org > - To unsubscribe, e-mail: dev-unsubscr...@community.apache.org For additional commands, e-mail: dev-h...@community.apache.org
Data inconsistency in projects.apache.org
I'm trying to understand the twisty maze of data sources that fuel projects.apache.org and either I'm confused, or there's some inconsistency in how this all fits together. I'll start with just one data source for now, so that I don't muddle multiple things together. https://svn.apache.org/repos/asf/comdev/projects.apache.org/trunk/data/committees.xml This file has a list of rdf files which are supposed to be in the committees/ subdirectory. The file itself says: This list should agree with the files in the directory committees/ However, in addition to the entries that look like: committees/any23.rdf there are also lines that look like: http://flex.apache.org/pmc_Flex.rdf (4 of them, for whatever that's worth - flex, ofbiz, plc4x, and tez) Is that correct? Or is that not how the data is supposed to be stored? Meanwhile, committees.xml contains 209 projects: grep location committees.xml| grep -vc Retired 209 while the committees/ directory contains just 206 rdf files: ls committees/*.rdf| wc -l 206 (Note, one of those files is _template.rdf, so it's really 205, and 205 + 4 = 209, so at least everything else matches up.) -- Rich Bowen - rbo...@rcbowen.com http://rcbowen.com/ @rbowen - To unsubscribe, e-mail: dev-unsubscr...@community.apache.org For additional commands, e-mail: dev-h...@community.apache.org
Re: [ALC Beijing] Proposal: Set up ALC Beijing Podcast (Mandarin）
Thank you JianSheng for sharing the detailed proposal. It looks great to me, +1 to go for it. Additionally, I see a sponsors section in the document. I just wanted to share information related to sponsorship in ALC events. An ALC event can have sponsors like Venue sponsor, Infrastructure Sponsor (provided help in arrangements like Mike, Speaker, Projects, etc..), Catering Sponsor, etc... The important thing to taken care of here is, respective ALC Chapter should be very specific in communication, for e.g. if a Sponsor A is sponsoring the Event X of an ALC Chapter Foo. It should be clearly mentioned and communicated that they are sponsors of the "*Event X of ALC Chapter Foo*", not ASF. Please refer Sponsorship section at https://s.apache.org/alc-guidelines Best regards, Swapnil M Mane, www.apache.org On Fri, Mar 27, 2020 at 6:54 AM 适兕 wrote: > > Thanks Mane, It's ok now, I can edit the wiki page. > > On Fri, Mar 27, 2020 at 12:59 AM Swapnil M Mane > wrote: > > > Hi JianSheng, > > I found your two confluence IDs, lijiangsheng and lijiangsheng1, > > Previously, access was given to lijiangsheng, now given access to > > lijiangsheng1. > > Kindly check and let me know if you still facing issue. > > > > > > Best regards, > > Swapnil M Mane, > > www.apache.org > > > > On Thu, Mar 26, 2020 at 5:48 PM 适兕 wrote: > > > > > > Hi, Mane, > > > > > > Sorry, I still have no write permission for ALC-Beijing wiki page. > > > > > > My account email is : lijiangshe...@gmail.com > > > > > > please check it again, Thanks very much. > > > > > > On Tue, Mar 24, 2020 at 11:59 AM Swapnil M Mane > > > > > wrote: > > > > > > > Hello JianSheng, > > > > Done, please check and let me know if you face any issues. > > > > > > > > Thanks for sharing the proposal, will review it soon, thank you! > > > > > > > > Best regards, > > > > Swapnil M Mane, > > > > www.apache.org > > > > > > > > On Tue, Mar 24, 2020 at 8:57 AM 适兕 wrote: > > > > > > > > > > Hi Mane > > > > > > > > > > Thanks for your help. > > > > > My cwiki.apache.org ID is: LiJiansheng. > > > > > > > > > > > > > > > On Mon, Mar 23, 2020 at 8:08 PM Swapnil M Mane < > > swapnilmm...@apache.org> > > > > > wrote: > > > > > > > > > > > Hi JianSheng, > > > > > > > > > > > > Kindly share your Confluence Id, will grant the edit rights. > > > > > > If you do not have Confluence account yet, please register at > > > > > > https://cwiki.apache.org/confluence/signup.action > > > > > > > > > > > > You can create a child page for the proposal at > > > > > > > > https://cwiki.apache.org/confluence/display/COMDEV/ALC+Beijing+Events > > > > > > > > > > > > For more details and guidelines, please refer > > > > > > https://s.apache.org/alc-guidelines > > > > > > > > > > > > Best regards, > > > > > > Swapnil M Mane, > > > > > > www.apache.org > > > > > > > > > > > > On Mon, Mar 23, 2020 at 4:22 PM 适兕 > > wrote: > > > > > > > > > > > > > > Hi， Willem > > > > > > > > > > > > > > Thanks for your respond. But I have no edit permission for ACL > > > > Beijing > > > > > > > Wiki page. I don't know how to apply for either. If you can help > > me , > > > > > > > appreciate thanks. > > > > > > > > > > > > > > > > > > > > > On Mon, Mar 23, 2020 at 6:39 PM Willem Jiang < > > willem.ji...@gmail.com > > > > > > > > > > > wrote: > > > > > > > > > > > > > > > +1 to invite more people to share their experiences with ASF > > > > projects > > > > > > > > through podcast. > > > > > > > > > > > > > > > > BTW, JianSheng do you have wiki edit right under ALC-Beijing? > > > > > > > > I think you can put the proposal into the wiki. > > > > > > > > > > > > > > > > Willem Jiang > > > > > > > > > > > > > > > > Twitter: willemjiang > > > > > > > > Weibo: 姜宁willem > > > > > > > > > > > > > > > > On Mon, Mar 23, 2020 at 5:59 PM 适兕 > > > > wrote: > > > > > > > > > > > > > > > > > > Hi，apache community members > > > > > > > > > > > > > > > > > >I was host podcast, Talking about open source related in > > > > Mandarin. > > > > > > > > Have > > > > > > > > > some experience, and the effect is also good, it is a good > > spread > > > > > > > > channel. > > > > > > > > >So I write an document[2] for set up ALC Beijing Podcast. > > > > > > > > > > > > > > > > > > Any input is welcome! > > > > > > > > > > > > > > > > > > [1]. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > http://opensourceway.community/posts/opensource_talking/2020-done-and-plan-index/ > > > > > > > > > [2]. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > https://docs.google.com/document/d/1vT07pdk9AnDKilCOTaKkQfQEAMR-4gkatOOd8OFsjNY/edit?usp=sharing > > > > > > > > > > > > > > > > > > > > - > > > > > > > > To unsubscribe, e-mail: dev-unsubscr...@community.apache.org > > > > > > > > For additional commands, e-mail: dev-h...@community.apache.org > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > > Welcome to http://opensourceway.com
[jira] [Updated] (COMDEV-362) RocketMQ Source Connect Cassandra
[ https://issues.apache.org/jira/browse/COMDEV-362?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ding Lei updated COMDEV-362: Description: The Cassandra source connector allows reading data from Apache Cassandra and writing data to Apache RocketMQ. In this project, you need to implement a Cassandra source connector based on OpenMessaging connect API, and run it on RocketMQ connect runtime You should learn before applying for this topic [Cassandra|http://cassandra.apache.org/]/[Apache RocketMQ |[https://rocketmq.apache.org|https://rocketmq.apache.org/]]/[OpenMessaging Connect API|https://github.com/openmessaging/openmessaging-connect] was: The Cassandra source connector allows reading data from Apache Cassandra and writing data to Apache RocketMQ. In this project, you need to implement a Cassandra source connector based on OpenMessaging connect API, and run it on RocketMQ connect runtime You should learn before applying for this topic [Cassandra|http://cassandra.apache.org/]/[Apache RocketMQ|[https://rocketmq.apache.org/]] /[OpenMessaging Connect API|https://github.com/openmessaging/openmessaging-connect] > RocketMQ Source Connect Cassandra > - > > Key: COMDEV-362 > URL: https://issues.apache.org/jira/browse/COMDEV-362 > Project: Community Development > Issue Type: Wish > Components: GSoC/Mentoring ideas >Reporter: Ding Lei >Priority: Major > Labels: RocketMQ, gsoc2020 > > > The Cassandra source connector allows reading data from Apache Cassandra and > writing data to Apache RocketMQ. In this project, you need to implement a > Cassandra source connector based on OpenMessaging connect API, and run it on > RocketMQ connect runtime You should learn before applying for this topic > [Cassandra|http://cassandra.apache.org/]/[Apache RocketMQ > |[https://rocketmq.apache.org|https://rocketmq.apache.org/]]/[OpenMessaging > Connect API|https://github.com/openmessaging/openmessaging-connect] -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@community.apache.org For additional commands, e-mail: dev-h...@community.apache.org
[jira] [Updated] (COMDEV-362) RocketMQ Source Connect Cassandra
[ https://issues.apache.org/jira/browse/COMDEV-362?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ding Lei updated COMDEV-362: Description: The Cassandra source connector allows reading data from Apache Cassandra and writing data to Apache RocketMQ. In this project, you need to implement a Cassandra source connector based on OpenMessaging connect API, and run it on RocketMQ connect runtime You should learn before applying for this topic [Cassandra|http://cassandra.apache.org/]/[Apache RocketMQ|[https://rocketmq.apache.org/]]/[OpenMessaging Connect API|https://github.com/openmessaging/openmessaging-connect] was: The Cassandra source connector allows reading data from Apache Cassandra and writing data to Apache RocketMQ. In this project, you need to implement a Cassandra source connector based on OpenMessaging connect API, and run it on RocketMQ connect runtime You should learn before applying for this topic [Cassandra|http://cassandra.apache.org/]/[Apache RocketMQ |[https://rocketmq.apache.org|https://rocketmq.apache.org/]]/[OpenMessaging Connect API|https://github.com/openmessaging/openmessaging-connect] > RocketMQ Source Connect Cassandra > - > > Key: COMDEV-362 > URL: https://issues.apache.org/jira/browse/COMDEV-362 > Project: Community Development > Issue Type: Wish > Components: GSoC/Mentoring ideas >Reporter: Ding Lei >Priority: Major > Labels: RocketMQ, gsoc2020 > > > The Cassandra source connector allows reading data from Apache Cassandra and > writing data to Apache RocketMQ. In this project, you need to implement a > Cassandra source connector based on OpenMessaging connect API, and run it on > RocketMQ connect runtime You should learn before applying for this topic > [Cassandra|http://cassandra.apache.org/]/[Apache > RocketMQ|[https://rocketmq.apache.org/]]/[OpenMessaging Connect > API|https://github.com/openmessaging/openmessaging-connect] -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@community.apache.org For additional commands, e-mail: dev-h...@community.apache.org
[jira] [Updated] (COMDEV-362) RocketMQ Source Connect Cassandra
[ https://issues.apache.org/jira/browse/COMDEV-362?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ding Lei updated COMDEV-362: Description: The Cassandra source connector allows reading data from Apache Cassandra and writing data to Apache RocketMQ. In this project, you need to implement a Cassandra source connector based on OpenMessaging connect API, and run it on RocketMQ connect runtime You should learn before applying for this topic [Cassandra|http://cassandra.apache.org/]/[Apache RocketMQ|[https://rocketmq.apache.org/]] /[OpenMessaging Connect API|https://github.com/openmessaging/openmessaging-connect] was: The Cassandra source connector allows reading data from Apache Cassandra and writing data to Apache RocketMQ. In this project, you need to implement a Cassandra source connector based on OpenMessaging connect API, and run it on RocketMQ connect runtime You should learn before applying for this topic [Cassandra|http://cassandra.apache.org/]/[Apache RocketMQ|[https://rocketmq.apache.org/]] /[OpenMessaging Connect API|[https://github.com/openmessaging/openmessaging-connect]|https://github.com/openmessaging/openmessaging-connect] > RocketMQ Source Connect Cassandra > - > > Key: COMDEV-362 > URL: https://issues.apache.org/jira/browse/COMDEV-362 > Project: Community Development > Issue Type: Wish > Components: GSoC/Mentoring ideas >Reporter: Ding Lei >Priority: Major > Labels: RocketMQ, gsoc2020 > > > The Cassandra source connector allows reading data from Apache Cassandra and > writing data to Apache RocketMQ. In this project, you need to implement a > Cassandra source connector based on OpenMessaging connect API, and run it on > RocketMQ connect runtime You should learn before applying for this topic > [Cassandra|http://cassandra.apache.org/]/[Apache > RocketMQ|[https://rocketmq.apache.org/]] /[OpenMessaging Connect > API|https://github.com/openmessaging/openmessaging-connect] -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@community.apache.org For additional commands, e-mail: dev-h...@community.apache.org
[jira] [Updated] (COMDEV-362) RocketMQ Source Connect Cassandra
[ https://issues.apache.org/jira/browse/COMDEV-362?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ding Lei updated COMDEV-362: Description: The Cassandra source connector allows reading data from Apache Cassandra and writing data to Apache RocketMQ. In this project, you need to implement a Cassandra source connector based on OpenMessaging connect API, and run it on RocketMQ connect runtime You should learn before applying for this topic [Cassandra|http://cassandra.apache.org/]/[Apache RocketMQ|[https://rocketmq.apache.org/]] /[OpenMessaging Connect API|[https://github.com/openmessaging/openmessaging-connect]|https://github.com/openmessaging/openmessaging-connect] was: The Cassandra source connector allows reading data from Apache Cassandra and writing data to Apache RocketMQ. In this project, you need to implement a Cassandra source connector based on OpenMessaging connect API, and run it on RocketMQ connect runtime You should learn before applying for this topic [Cassandra|http://cassandra.apache.org/]/[Apache RocketMQ](https://rocketmq.apache.org/) /[OpenMessaging Connect API](https://github.com/openmessaging/openmessaging-connect) > RocketMQ Source Connect Cassandra > - > > Key: COMDEV-362 > URL: https://issues.apache.org/jira/browse/COMDEV-362 > Project: Community Development > Issue Type: Wish > Components: GSoC/Mentoring ideas >Reporter: Ding Lei >Priority: Major > Labels: RocketMQ, gsoc2020 > > The Cassandra source connector allows reading data from Apache Cassandra and > writing data to Apache RocketMQ. In this project, you need to implement a > Cassandra source connector based on OpenMessaging connect API, and run it on > RocketMQ connect runtime You should learn before applying for this topic > [Cassandra|http://cassandra.apache.org/]/[Apache > RocketMQ|[https://rocketmq.apache.org/]] /[OpenMessaging Connect > API|[https://github.com/openmessaging/openmessaging-connect]|https://github.com/openmessaging/openmessaging-connect] > > -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@community.apache.org For additional commands, e-mail: dev-h...@community.apache.org
[jira] [Updated] (COMDEV-362) RocketMQ Source Connect Cassandra
[ https://issues.apache.org/jira/browse/COMDEV-362?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ding Lei updated COMDEV-362: Labels: RocketMQ gsoc2020 (was: ) > RocketMQ Source Connect Cassandra > - > > Key: COMDEV-362 > URL: https://issues.apache.org/jira/browse/COMDEV-362 > Project: Community Development > Issue Type: Wish > Components: GSoC/Mentoring ideas >Reporter: Ding Lei >Priority: Major > Labels: RocketMQ, gsoc2020 > > The Cassandra source connector allows reading data from Apache Cassandra and > writing data to Apache RocketMQ. In this project, you need to implement a > Cassandra source connector based on OpenMessaging connect API, and run it on > RocketMQ connect runtime You should learn before applying for this topic > [Cassandra|http://cassandra.apache.org/]/[Apache > RocketMQ](https://rocketmq.apache.org/) /[OpenMessaging Connect > API](https://github.com/openmessaging/openmessaging-connect) > > -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@community.apache.org For additional commands, e-mail: dev-h...@community.apache.org
[jira] [Created] (COMDEV-362) RocketMQ Source Connect Cassandra
Ding Lei created COMDEV-362: --- Summary: RocketMQ Source Connect Cassandra Key: COMDEV-362 URL: https://issues.apache.org/jira/browse/COMDEV-362 Project: Community Development Issue Type: Wish Components: GSoC/Mentoring ideas Reporter: Ding Lei The Cassandra source connector allows reading data from Apache Cassandra and writing data to Apache RocketMQ. In this project, you need to implement a Cassandra source connector based on OpenMessaging connect API, and run it on RocketMQ connect runtime You should learn before applying for this topic [Cassandra|http://cassandra.apache.org/]/[Apache RocketMQ](https://rocketmq.apache.org/) /[OpenMessaging Connect API](https://github.com/openmessaging/openmessaging-connect) -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@community.apache.org For additional commands, e-mail: dev-h...@community.apache.org
