moderators?
Who are the moderators for this list? We seem to be getting many emails that should not be getting through. Do we need to find some new blood to spread the load?
Re: svn commit: r1686683 - in /comdev/projects.apache.org/scripts: README.txt import/addpmc.py
ok, no answer: I'll re-do the commit this WE Regards, Hervé Le jeudi 25 juin 2015 07:54:44 Hervé BOUTEMY a écrit : > > do you really think addpmc.py is useful now? > > ping > > Regards, > > Hervé > > Le dimanche 21 juin 2015 16:47:25 Hervé BOUTEMY a écrit : > > ok, there is a misunderstanding: reverted as first step > > > > then we need to discuss, since I don't see when it may be used given > > current logic where everything comes from committee-info.txt and rdf > > files: that's the way I added committees created during last monthes, ie > > simply running parsecommittees.py > > > > adding committees as json when the committee does not exist in committee- > > info.txt is a nonsense IMHO: once I added committe-info.txt parsing > > feature, after long thoughts on it, I really don't see any use for this > > addpmc.py script > > > > (the discussion about RDF/DOAP is another independant topic, ie where to > > find information that is not in committee-info.txt) > > > > > > do you really think addpmc.py is useful now? > > > > Regards, > > > > Hervé > > > > Le dimanche 21 juin 2015 15:52:28 Daniel Gruno a écrit : > > > Excuse me? That script WAS used for adding new committees to the site, > > > simple and easy. > > > Please revert, and don't just delete stuff because you personally don't > > > use it. > > > > > > WIth regards, > > > Daniel. > > > > > > On 2015-06-21 03:50, hbout...@apache.org wrote: > > > > Author: hboutemy > > > > Date: Sun Jun 21 01:50:14 2015 > > > > New Revision: 1686683 > > > > > > > > URL: http://svn.apache.org/r1686683 > > > > Log: > > > > removed addpmc.py: not used > > > > > > > > Removed: > > > > comdev/projects.apache.org/scripts/import/addpmc.py > > > > > > > > Modified: > > > > comdev/projects.apache.org/scripts/README.txt > > > > > > > > Modified: comdev/projects.apache.org/scripts/README.txt > > > > URL: > > > > http://svn.apache.org/viewvc/comdev/projects.apache.org/scripts/README > > > > .t > > > > x > > > > t?rev=1686683&r1=1686682&r2=1686683&view=diff > > > > == > > > > == > > > > = > > > > = --- comdev/projects.apache.org/scripts/README.txt (original) > > > > +++ comdev/projects.apache.org/scripts/README.txt Sun Jun 21 01:50:14 > > > > 2015 > > > > > > > > @@ -34,8 +34,7 @@ various sources: > > > > in: foundation/committees.json + > > > > foundation/committees-retired.json > > > > + > > > > committee-info.txt > > > > (https://svn.apache.org/repos/private/committers/board/committee-i > > > > nf > > > > o > > > > .txt) out: foundation/committees.json + > > > > foundation/committees-retired.json> > > > > > > > > -- parsepmcs.py: imports PMC data (RDF) from the old > > > > project.apache.org > > > > site. No need - to run that more than once? > > > > +- parsepmcs.py: imports PMC data (RDF) from the old > > > > project.apache.org > > > > site.> > > > > > > > > in: > > > > https://svn.apache.org/repos/asf/infrastructure/site-tools/trunk/p > > > > ro > > > > j > > > > ects/pmc_list.xml + PMC data .rdf files out: foundation/pmcs.json > > > > > > > > @@ -43,8 +42,3 @@ various sources: > > > > turns them into JSON objects. > > > > in: > > > > https://svn.apache.org/repos/asf/infrastructure/site-tools/trunk/p > > > > ro > > > > j > > > > ects/files.xml + projects' DOAP files out: projects/*.json + > > > > foundation/projects.json > > > > > > > > - > > > > -- addpmc.py > > > > - in: foundation/pmcs.json + foundation/committees-evolution.json + > > > > params > > > > - out: foundation/pmcs.json + foundation/committees-evolution.json > > > > - list of PMCs with site url (pmcs.json) and monthly list of new > > > > committees (committees-evolution.json)
Re: Is https://projects-new.apache.org/ ready for prime time?
Le vendredi 26 juin 2015 17:46:55 sebb a écrit : > On 26 June 2015 at 07:12, Hervé BOUTEMY wrote: > > that's why I want to switch projects to projects-old and projects-new to > > projects: be able to work on extracting documentation from projects-old > > and > > updating it to match the new location > > That will break the existing links. > > If you want do the switch ahead of fixing the documentation, then one > way to do it is to ensure that projects-old is set up to point to the > current projects.a.o. > > Then change projects-new to link to projects-old instead of projects - > that should be trivial to do. > > Then projects-new can replace projects.a.o. > > Documentation can then be migrated to the new code in the old URL. yes, of course, these are the exact steps: I just summarised > > > I proposed http://svn.apache.org/viewvc/comdev/projects.apache.org/data/ > > as > > the new location of DOAP files lists (both PMC and projects) but got no > > answer > Did not see that. > > That will break projects-old, so -1 until projects-old has been > retired unless you can find a way to keep projects-old working with > the new location. the idea is to let old data in the old location and not update it any more: this won't break anything, just make projects-old less accurate over time that's not an issue IMHO, since we expect to migrate the doc and shutdown projects-old after that, in a few monthes notice that I think the cron job that updates projects-old should be switched off to avoid issues > > AFAIK it's not necessary to move the location. ? previously, you told having projects-new depending on projects-old was an issue and you were right! and IMHO, it's an issue just because data in projects-old is hard to find for someone not expert in the whole system I'll start to add comments in projects-old data to point to projects-new to start the transition then we'll have to agree on when to really switch (and find who can do it) Regards, Hervé > > > if we're ok with that new location, the next step is to stop modifying > > equivalent files in > > http://svn.apache.org/viewvc/infrastructure/site-tools/trunk/projects/ > > (or even remove them) but point to the new location > > > > Of course, if ok with the new location, we can immediately add > > committees.xml and projects.xml pointers to > > https://projects-new.apache.org/about.html IMHO the simple file names and > > location in about.html would make things very clear before diggin into > > more details on DOAP format and conventions (which could be in the Wiki > > for ease of editing) > > > > > > can we agree: > > 1. on the new data location and content: > > http://svn.apache.org/viewvc/comdev/projects.apache.org/data/ > > No, see above. > > > 2. on the switch then update of everything to match the new location (and > > stop updating projects-old) > > Not entirely, see above. > > > Regards, > > > > Hervé > > > > Le jeudi 25 juin 2015 09:17:32 vous avez écrit : > >> On 25 June 2015 at 06:53, Hervé BOUTEMY wrote: > >> > Sebb, > >> > > >> > as main maintainer of current http://projects.apache.org/ (AFAIK), are > >> > you > >> > ok with switching the url to the new service and renaming current > >> > service > >> > to projects-old (to let use time to continue content migration withotu > >> > loosing anything)? Do you see any show stopper? > >> > >> The main item missing from projects-new is documentation - it > >> currently points to projects. > >> It's not immediately obvious how to provide data for the site. > >> I think the main page needs to provide more of an overview. > >> > >> I think the first step needs to be to improve the projects-new > >> documentation so it does not rely on the current project pages. > >> > >> Also I notice that it seems p-new relies on parsing > >> http://people.apache.org/committer-index.html > >> which in turn parses other data sources. > >> > >> That needs to be fixed. > >> > >> > Of course, I'm interested in your help to maintain the new projects > >> > site: > >> > don't hesitate to comment on or change the code. > >> > > >> > Regards, > >> > > >> > Hervé > >> > > >> > Le dimanche 21 juin 2015 17:16:07 jan i a écrit : > >> >> +1 switch as soon as possible, and then continue working on the data > >> >> end. > >> >> > >> >> rgds > >> >> jan i > >> >> > >> >> On Sunday, June 21, 2015, Hervé BOUTEMY wrote: > >> >> > Le dimanche 21 juin 2015 15:54:29 jan i a écrit : > >> >> > > On 21 June 2015 at 15:48, Daniel Gruno >> >> > > >> >> > > wrote: > >> >> > > > On 2015-06-21 02:45, Hervé BOUTEMY wrote: > >> >> > > >> for me, the new site is ready: there is of course room for > >> >> > > >> >> > improvements, > >> >> > > >> >> > > >> but > >> >> > > >> it is stable and maintainable, waiting for contributions > >> >> > > >> > >> >> > > >> notice: I changed the wording to stop using "TLP", but use > >> >> > > >> "Committee" > >> >> > > >> instead, since TLP cause issues when trying to describe
Re: Can't reporter.a.o automatically detect version number and release datenschutzrechtlichen?
Am 26.06.2015 19:32 schrieb : > > Am 26.06.2015 19:30 schrieb "Franco Perruna" : > > > > Am 26.06.2015 19:01 schrieb "Franco Perruna" >: > >> > >> Francoperruna83 > >> > >> Am 26.06.2015 18:52 schrieb "sebb" : > >>> > >>> Or just include the URL that triggered the e-mail? > >>> Surely that would give sufficient clue to the project? > >>> > >>> By the way, I received e-mails from the reporter service when I > >>> *deleted* some old release files. > >>> > >>> Surely such mails could/should be suppressed? > >>> > >>> On 26 June 2015 at 09:04, Branko Čibej wrote: > >>> > On 25.06.2015 17:40, Martijn Dashorst wrote: > >>> >> And there is no rule (yet) that there is only one format to rule > them > >>> >> all. A transformation rule specified at project level in the > reporter > >>> >> tool could do the trick as well. > >>> > > >>> > > >>> > Yah ... have each project define a (set of) regular expressions and > use > >>> > the contents of \1. > >>> > > >>> > > >>> > -- Brane > >>> > > >>> > > >>> >> > >>> >> On Thu, Jun 25, 2015 at 5:17 PM, Niclas Hedhman > wrote: > >>> >>> Alex, > >>> >>> I think you made an assumption that "format" meant naming schemes > of > >>> >>> releases, but it didn't. Simple "a defined way" to make that > available for > >>> >>> reporter to pick it up with relative ease. > >>> >>> Your suggestion of a doap-based solution is equally a "format". The > >>> >>> important part, I think, is that "whatever way is chosen", that it > is > >>> >>> documented and notified to PMCs, with optionality to use it. > >>> >>> > >>> >>> For me; DOAP is as good as anything, although there are probably a > great > >>> >>> demand for linking that with Maven publishing "somehow". Since our > Gradle > >>> >>> build is generating all kinds of meta data output anyway, one more > wouldn't > >>> >>> hurt much. > >>> >>> > >>> >>> Cheers > >>> >>> > >>> >>> On Thu, Jun 25, 2015 at 10:31 PM, Alex Harui > wrote: > >>> >>> > >>> > >>> On 6/25/15, 7:18 AM, "hedh...@gmail.com on behalf of Niclas > Hedhman" > >>> wrote: > >>> > >>> > If the "format" is published, and the "reward" of following it > would be > >>> > that the reporter picks it up automatically, it could lead to > swift > >>> > adoption ;-) > >>> You might get push back about having to change naming schemes. > >>> > >>> I’m interested in a list of all current and past releases for my > project. > >>> I was trying to figure out how to mine archive.a.o or the svn log > for it. > >>> I’d be willing to maintain an xml file like in DOAP or elsewhere > of not > >>> just the last, but all releases and links to their downloads with > >>> “friendly” names for the releases. Then reporter.a.o could grab > from that. > >>> > >>> -Alex > >>> > >>> > On Thu, Jun 25, 2015 at 9:26 PM, Daniel Gruno < > humbed...@apache.org> > >>> > wrote: > >>> > > >>> >> It has been tried, and it did not work. > >>> >> People are too inconsistent across projects in how they name > their > >>> >> release > >>> >> files, grabbing the version is nigh impossible. > >>> >> If we had some form of agreement on how to name files, then it > would be > >>> >> possible. > >>> >> > >>> >> With regards, > >>> >> Daniel. > >>> >> > >>> >> > >>> >> On 2015-06-25 15:11, Martijn Dashorst wrote: > >>> >> > >>> >>> Is there a reason why the reporter.a.o can send a message to a > release > >>> >>> manager that it detected a new release, but is incapable of > >>> >>> determining a version number and release date? > >>> >>> > >>> >>> Martijn > >>> >>> > >>> >> > >>> > > >>> > -- > >>> > Niclas Hedhman, Software Developer > >>> > http://zest.apache.org - New Energy for Java > >>> > >>> >>> > >>> >>> -- > >>> >>> Niclas Hedhman, Software Developer > >>> >>> http://zest.apache.org - New Energy for Java > >>> >> > >>> >> > >>> > >
Re: Can't reporter.a.o automatically detect version number and release datenschutzrechtlichen?
Am 26.06.2015 19:30 schrieb "Franco Perruna" : > > Am 26.06.2015 19:01 schrieb "Franco Perruna" : >> >> Francoperruna83 >> >> Am 26.06.2015 18:52 schrieb "sebb" : >>> >>> Or just include the URL that triggered the e-mail? >>> Surely that would give sufficient clue to the project? >>> >>> By the way, I received e-mails from the reporter service when I >>> *deleted* some old release files. >>> >>> Surely such mails could/should be suppressed? >>> >>> On 26 June 2015 at 09:04, Branko Čibej wrote: >>> > On 25.06.2015 17:40, Martijn Dashorst wrote: >>> >> And there is no rule (yet) that there is only one format to rule them >>> >> all. A transformation rule specified at project level in the reporter >>> >> tool could do the trick as well. >>> > >>> > >>> > Yah ... have each project define a (set of) regular expressions and use >>> > the contents of \1. >>> > >>> > >>> > -- Brane >>> > >>> > >>> >> >>> >> On Thu, Jun 25, 2015 at 5:17 PM, Niclas Hedhman wrote: >>> >>> Alex, >>> >>> I think you made an assumption that "format" meant naming schemes of >>> >>> releases, but it didn't. Simple "a defined way" to make that available for >>> >>> reporter to pick it up with relative ease. >>> >>> Your suggestion of a doap-based solution is equally a "format". The >>> >>> important part, I think, is that "whatever way is chosen", that it is >>> >>> documented and notified to PMCs, with optionality to use it. >>> >>> >>> >>> For me; DOAP is as good as anything, although there are probably a great >>> >>> demand for linking that with Maven publishing "somehow". Since our Gradle >>> >>> build is generating all kinds of meta data output anyway, one more wouldn't >>> >>> hurt much. >>> >>> >>> >>> Cheers >>> >>> >>> >>> On Thu, Jun 25, 2015 at 10:31 PM, Alex Harui wrote: >>> >>> >>> >>> On 6/25/15, 7:18 AM, "hedh...@gmail.com on behalf of Niclas Hedhman" >>> wrote: >>> >>> > If the "format" is published, and the "reward" of following it would be >>> > that the reporter picks it up automatically, it could lead to swift >>> > adoption ;-) >>> You might get push back about having to change naming schemes. >>> >>> I’m interested in a list of all current and past releases for my project. >>> I was trying to figure out how to mine archive.a.o or the svn log for it. >>> I’d be willing to maintain an xml file like in DOAP or elsewhere of not >>> just the last, but all releases and links to their downloads with >>> “friendly” names for the releases. Then reporter.a.o could grab from that. >>> >>> -Alex >>> >>> > On Thu, Jun 25, 2015 at 9:26 PM, Daniel Gruno < humbed...@apache.org> >>> > wrote: >>> > >>> >> It has been tried, and it did not work. >>> >> People are too inconsistent across projects in how they name their >>> >> release >>> >> files, grabbing the version is nigh impossible. >>> >> If we had some form of agreement on how to name files, then it would be >>> >> possible. >>> >> >>> >> With regards, >>> >> Daniel. >>> >> >>> >> >>> >> On 2015-06-25 15:11, Martijn Dashorst wrote: >>> >> >>> >>> Is there a reason why the reporter.a.o can send a message to a release >>> >>> manager that it detected a new release, but is incapable of >>> >>> determining a version number and release date? >>> >>> >>> >>> Martijn >>> >>> >>> >> >>> > >>> > -- >>> > Niclas Hedhman, Software Developer >>> > http://zest.apache.org - New Energy for Java >>> >>> >>> >>> >>> -- >>> >>> Niclas Hedhman, Software Developer >>> >>> http://zest.apache.org - New Energy for Java >>> >> >>> >> >>> >
Re: Can't reporter.a.o automatically detect version number and release date?
Am 26.06.2015 19:01 schrieb "Franco Perruna" : > Francoperruna83 > Am 26.06.2015 18:52 schrieb "sebb" : > >> Or just include the URL that triggered the e-mail? >> Surely that would give sufficient clue to the project? >> >> By the way, I received e-mails from the reporter service when I >> *deleted* some old release files. >> >> Surely such mails could/should be suppressed? >> >> On 26 June 2015 at 09:04, Branko Čibej wrote: >> > On 25.06.2015 17:40, Martijn Dashorst wrote: >> >> And there is no rule (yet) that there is only one format to rule them >> >> all. A transformation rule specified at project level in the reporter >> >> tool could do the trick as well. >> > >> > >> > Yah ... have each project define a (set of) regular expressions and use >> > the contents of \1. >> > >> > >> > -- Brane >> > >> > >> >> >> >> On Thu, Jun 25, 2015 at 5:17 PM, Niclas Hedhman >> wrote: >> >>> Alex, >> >>> I think you made an assumption that "format" meant naming schemes of >> >>> releases, but it didn't. Simple "a defined way" to make that >> available for >> >>> reporter to pick it up with relative ease. >> >>> Your suggestion of a doap-based solution is equally a "format". The >> >>> important part, I think, is that "whatever way is chosen", that it is >> >>> documented and notified to PMCs, with optionality to use it. >> >>> >> >>> For me; DOAP is as good as anything, although there are probably a >> great >> >>> demand for linking that with Maven publishing "somehow". Since our >> Gradle >> >>> build is generating all kinds of meta data output anyway, one more >> wouldn't >> >>> hurt much. >> >>> >> >>> Cheers >> >>> >> >>> On Thu, Jun 25, 2015 at 10:31 PM, Alex Harui >> wrote: >> >>> >> >> On 6/25/15, 7:18 AM, "hedh...@gmail.com on behalf of Niclas Hedhman" >> wrote: >> >> > If the "format" is published, and the "reward" of following it >> would be >> > that the reporter picks it up automatically, it could lead to swift >> > adoption ;-) >> You might get push back about having to change naming schemes. >> >> I’m interested in a list of all current and past releases for my >> project. >> I was trying to figure out how to mine archive.a.o or the svn log >> for it. >> I’d be willing to maintain an xml file like in DOAP or elsewhere of >> not >> just the last, but all releases and links to their downloads with >> “friendly” names for the releases. Then reporter.a.o could grab >> from that. >> >> -Alex >> >> > On Thu, Jun 25, 2015 at 9:26 PM, Daniel Gruno > > >> > wrote: >> > >> >> It has been tried, and it did not work. >> >> People are too inconsistent across projects in how they name their >> >> release >> >> files, grabbing the version is nigh impossible. >> >> If we had some form of agreement on how to name files, then it >> would be >> >> possible. >> >> >> >> With regards, >> >> Daniel. >> >> >> >> >> >> On 2015-06-25 15:11, Martijn Dashorst wrote: >> >> >> >>> Is there a reason why the reporter.a.o can send a message to a >> release >> >>> manager that it detected a new release, but is incapable of >> >>> determining a version number and release date? >> >>> >> >>> Martijn >> >>> >> >> >> > >> > -- >> > Niclas Hedhman, Software Developer >> > http://zest.apache.org - New Energy for Java >> >> >>> >> >>> -- >> >>> Niclas Hedhman, Software Developer >> >>> http://zest.apache.org - New Energy for Java >> >> >> >> >> > >> >
Re: Can't reporter.a.o automatically detect version number and release date?
Francoperruna83 Am 26.06.2015 18:52 schrieb "sebb" : > Or just include the URL that triggered the e-mail? > Surely that would give sufficient clue to the project? > > By the way, I received e-mails from the reporter service when I > *deleted* some old release files. > > Surely such mails could/should be suppressed? > > On 26 June 2015 at 09:04, Branko Čibej wrote: > > On 25.06.2015 17:40, Martijn Dashorst wrote: > >> And there is no rule (yet) that there is only one format to rule them > >> all. A transformation rule specified at project level in the reporter > >> tool could do the trick as well. > > > > > > Yah ... have each project define a (set of) regular expressions and use > > the contents of \1. > > > > > > -- Brane > > > > > >> > >> On Thu, Jun 25, 2015 at 5:17 PM, Niclas Hedhman > wrote: > >>> Alex, > >>> I think you made an assumption that "format" meant naming schemes of > >>> releases, but it didn't. Simple "a defined way" to make that available > for > >>> reporter to pick it up with relative ease. > >>> Your suggestion of a doap-based solution is equally a "format". The > >>> important part, I think, is that "whatever way is chosen", that it is > >>> documented and notified to PMCs, with optionality to use it. > >>> > >>> For me; DOAP is as good as anything, although there are probably a > great > >>> demand for linking that with Maven publishing "somehow". Since our > Gradle > >>> build is generating all kinds of meta data output anyway, one more > wouldn't > >>> hurt much. > >>> > >>> Cheers > >>> > >>> On Thu, Jun 25, 2015 at 10:31 PM, Alex Harui wrote: > >>> > > On 6/25/15, 7:18 AM, "hedh...@gmail.com on behalf of Niclas Hedhman" > wrote: > > > If the "format" is published, and the "reward" of following it would > be > > that the reporter picks it up automatically, it could lead to swift > > adoption ;-) > You might get push back about having to change naming schemes. > > I’m interested in a list of all current and past releases for my > project. > I was trying to figure out how to mine archive.a.o or the svn log for > it. > I’d be willing to maintain an xml file like in DOAP or elsewhere of > not > just the last, but all releases and links to their downloads with > “friendly” names for the releases. Then reporter.a.o could grab from > that. > > -Alex > > > On Thu, Jun 25, 2015 at 9:26 PM, Daniel Gruno > > wrote: > > > >> It has been tried, and it did not work. > >> People are too inconsistent across projects in how they name their > >> release > >> files, grabbing the version is nigh impossible. > >> If we had some form of agreement on how to name files, then it > would be > >> possible. > >> > >> With regards, > >> Daniel. > >> > >> > >> On 2015-06-25 15:11, Martijn Dashorst wrote: > >> > >>> Is there a reason why the reporter.a.o can send a message to a > release > >>> manager that it detected a new release, but is incapable of > >>> determining a version number and release date? > >>> > >>> Martijn > >>> > >> > > > > -- > > Niclas Hedhman, Software Developer > > http://zest.apache.org - New Energy for Java > > >>> > >>> -- > >>> Niclas Hedhman, Software Developer > >>> http://zest.apache.org - New Energy for Java > >> > >> > > >
Re: Can't reporter.a.o automatically detect version number and release date?
Or just include the URL that triggered the e-mail? Surely that would give sufficient clue to the project? By the way, I received e-mails from the reporter service when I *deleted* some old release files. Surely such mails could/should be suppressed? On 26 June 2015 at 09:04, Branko Čibej wrote: > On 25.06.2015 17:40, Martijn Dashorst wrote: >> And there is no rule (yet) that there is only one format to rule them >> all. A transformation rule specified at project level in the reporter >> tool could do the trick as well. > > > Yah ... have each project define a (set of) regular expressions and use > the contents of \1. > > > -- Brane > > >> >> On Thu, Jun 25, 2015 at 5:17 PM, Niclas Hedhman wrote: >>> Alex, >>> I think you made an assumption that "format" meant naming schemes of >>> releases, but it didn't. Simple "a defined way" to make that available for >>> reporter to pick it up with relative ease. >>> Your suggestion of a doap-based solution is equally a "format". The >>> important part, I think, is that "whatever way is chosen", that it is >>> documented and notified to PMCs, with optionality to use it. >>> >>> For me; DOAP is as good as anything, although there are probably a great >>> demand for linking that with Maven publishing "somehow". Since our Gradle >>> build is generating all kinds of meta data output anyway, one more wouldn't >>> hurt much. >>> >>> Cheers >>> >>> On Thu, Jun 25, 2015 at 10:31 PM, Alex Harui wrote: >>> On 6/25/15, 7:18 AM, "hedh...@gmail.com on behalf of Niclas Hedhman" wrote: > If the "format" is published, and the "reward" of following it would be > that the reporter picks it up automatically, it could lead to swift > adoption ;-) You might get push back about having to change naming schemes. I’m interested in a list of all current and past releases for my project. I was trying to figure out how to mine archive.a.o or the svn log for it. I’d be willing to maintain an xml file like in DOAP or elsewhere of not just the last, but all releases and links to their downloads with “friendly” names for the releases. Then reporter.a.o could grab from that. -Alex > On Thu, Jun 25, 2015 at 9:26 PM, Daniel Gruno > wrote: > >> It has been tried, and it did not work. >> People are too inconsistent across projects in how they name their >> release >> files, grabbing the version is nigh impossible. >> If we had some form of agreement on how to name files, then it would be >> possible. >> >> With regards, >> Daniel. >> >> >> On 2015-06-25 15:11, Martijn Dashorst wrote: >> >>> Is there a reason why the reporter.a.o can send a message to a release >>> manager that it detected a new release, but is incapable of >>> determining a version number and release date? >>> >>> Martijn >>> >> > > -- > Niclas Hedhman, Software Developer > http://zest.apache.org - New Energy for Java >>> >>> -- >>> Niclas Hedhman, Software Developer >>> http://zest.apache.org - New Energy for Java >> >> >
Re: Is https://projects-new.apache.org/ ready for prime time?
On 26 June 2015 at 07:12, Hervé BOUTEMY wrote: > that's why I want to switch projects to projects-old and projects-new to > projects: be able to work on extracting documentation from projects-old and > updating it to match the new location That will break the existing links. If you want do the switch ahead of fixing the documentation, then one way to do it is to ensure that projects-old is set up to point to the current projects.a.o. Then change projects-new to link to projects-old instead of projects - that should be trivial to do. Then projects-new can replace projects.a.o. Documentation can then be migrated to the new code in the old URL. > I proposed http://svn.apache.org/viewvc/comdev/projects.apache.org/data/ as > the new location of DOAP files lists (both PMC and projects) but got no answer Did not see that. That will break projects-old, so -1 until projects-old has been retired unless you can find a way to keep projects-old working with the new location. AFAIK it's not necessary to move the location. > if we're ok with that new location, the next step is to stop modifying > equivalent files in > http://svn.apache.org/viewvc/infrastructure/site-tools/trunk/projects/ (or > even remove them) but point to the new location > > Of course, if ok with the new location, we can immediately add committees.xml > and projects.xml pointers to https://projects-new.apache.org/about.html > IMHO the simple file names and location in about.html would make things very > clear before diggin into more details on DOAP format and conventions (which > could be in the Wiki for ease of editing) > > > can we agree: > 1. on the new data location and content: > http://svn.apache.org/viewvc/comdev/projects.apache.org/data/ No, see above. > 2. on the switch then update of everything to match the new location (and stop > updating projects-old) Not entirely, see above. > Regards, > > Hervé > > Le jeudi 25 juin 2015 09:17:32 vous avez écrit : >> On 25 June 2015 at 06:53, Hervé BOUTEMY wrote: >> > Sebb, >> > >> > as main maintainer of current http://projects.apache.org/ (AFAIK), are you >> > ok with switching the url to the new service and renaming current service >> > to projects-old (to let use time to continue content migration withotu >> > loosing anything)? Do you see any show stopper? >> >> The main item missing from projects-new is documentation - it >> currently points to projects. >> It's not immediately obvious how to provide data for the site. >> I think the main page needs to provide more of an overview. >> >> I think the first step needs to be to improve the projects-new >> documentation so it does not rely on the current project pages. >> >> Also I notice that it seems p-new relies on parsing >> http://people.apache.org/committer-index.html >> which in turn parses other data sources. >> >> That needs to be fixed. >> >> > Of course, I'm interested in your help to maintain the new projects site: >> > don't hesitate to comment on or change the code. >> > >> > Regards, >> > >> > Hervé >> > >> > Le dimanche 21 juin 2015 17:16:07 jan i a écrit : >> >> +1 switch as soon as possible, and then continue working on the data end. >> >> >> >> rgds >> >> jan i >> >> >> >> On Sunday, June 21, 2015, Hervé BOUTEMY wrote: >> >> > Le dimanche 21 juin 2015 15:54:29 jan i a écrit : >> >> > > On 21 June 2015 at 15:48, Daniel Gruno > >> > >> >> > > wrote: >> >> > > > On 2015-06-21 02:45, Hervé BOUTEMY wrote: >> >> > > >> for me, the new site is ready: there is of course room for >> >> > >> >> > improvements, >> >> > >> >> > > >> but >> >> > > >> it is stable and maintainable, waiting for contributions >> >> > > >> >> >> > > >> notice: I changed the wording to stop using "TLP", but use >> >> > > >> "Committee" >> >> > > >> instead, since TLP cause issues when trying to describe each >> >> > > >> projects >> >> > > >> (the >> >> > > >> software) as TLP or sub-projects >> >> > > >> >> >> > > >> >> >> > > >> when doing the switch, we'll need to rename current site as >> >> > > >> projects- >> >> > > >> old.apache.org: there is some content to migrate (DOAP, >> >> > >> >> > documentation) >> >> > >> >> > > >> associated to communication with projects on the changes that has >> >> > > >> to >> >> > >> >> > be >> >> > >> >> > > >> decoupled from public vizualisation. I'll continue working on it. >> >> > > >> >> >> > > >> There one choice to do: continue serving the pages from current VM >> >> > > >> or >> >> > > >> serve >> >> > > >> through standard resilient httpds. The VM is useful for cron jobs, >> >> > >> >> > but is >> >> > >> >> > > >> not >> >> > > >> absolutely necessary for serving content since I removed online >> >> > >> >> > content >> >> > >> >> > > >> editing that caused the VM requirement for content serving AFAIK. >> >> > >> >> > Using >> >> > >> >> > > >> standard httpd will avoid SPOF or eventual load issue. >> >> > > > >> >> > > > What do you mean by 'standard httpd'? It already uses...standard >> >> > > > http
Bestätigung
francoperrun...@gmail.com
Re: Twitter account, barcamp.
On 26 June 2015 at 14:59, Marvin Humphrey wrote: > On Fri, Jun 26, 2015 at 3:36 AM, jan i wrote: > > > Does anybody which email is registred for our barcamp twitter account. > > > > Help is: > > > > > > *co@a*. > > Have you tried commun...@apache.org? > yeah no luck. rgds jan i. > > Marvin Humphrey >
Re: Twitter account, barcamp.
On Fri, Jun 26, 2015 at 3:36 AM, jan i wrote: > Does anybody which email is registred for our barcamp twitter account. > > Help is: > > > *co@a*. Have you tried commun...@apache.org? Marvin Humphrey
Re: Is https://projects-new.apache.org/ ready for prime time?
On 26 June 2015 at 08:12, Hervé BOUTEMY wrote: > that's why I want to switch projects to projects-old and projects-new to > projects: be able to work on extracting documentation from projects-old and > updating it to match the new location > If we wait too long, too many people start using projects-new. I do not think it is possible to make the perfect site, especially not in advance. > > I proposed http://svn.apache.org/viewvc/comdev/projects.apache.org/data/ > as > the new location of DOAP files lists (both PMC and projects) but got no > answer > ups, I did not see it as a question, but as a decision to which I had no objections. > > if we're ok with that new location, the next step is to stop modifying > equivalent files in > http://svn.apache.org/viewvc/infrastructure/site-tools/trunk/projects/ > (or even remove them) but point to the new location > > Of course, if ok with the new location, we can immediately add > committees.xml > and projects.xml pointers to https://projects-new.apache.org/about.html > IMHO the simple file names and location in about.html would make things > very > clear before diggin into more details on DOAP format and conventions (which > could be in the Wiki for ease of editing) > > > can we agree: > 1. on the new data location and content: > http://svn.apache.org/viewvc/comdev/projects.apache.org/data/ > +1 > > 2. on the switch then update of everything to match the new location (and > stop > updating projects-old) > +1 I do not have a lot of spare cycles due to apacheCON, but I am always availble if you need a bit of testing. rgds jan i. > > Regards, > > Hervé > > Le jeudi 25 juin 2015 09:17:32 vous avez écrit : > > On 25 June 2015 at 06:53, Hervé BOUTEMY wrote: > > > Sebb, > > > > > > as main maintainer of current http://projects.apache.org/ (AFAIK), > are you > > > ok with switching the url to the new service and renaming current > service > > > to projects-old (to let use time to continue content migration withotu > > > loosing anything)? Do you see any show stopper? > > > > The main item missing from projects-new is documentation - it > > currently points to projects. > > It's not immediately obvious how to provide data for the site. > > I think the main page needs to provide more of an overview. > > > > I think the first step needs to be to improve the projects-new > > documentation so it does not rely on the current project pages. > > > > Also I notice that it seems p-new relies on parsing > > http://people.apache.org/committer-index.html > > which in turn parses other data sources. > > > > That needs to be fixed. > > > > > Of course, I'm interested in your help to maintain the new projects > site: > > > don't hesitate to comment on or change the code. > > > > > > Regards, > > > > > > Hervé > > > > > > Le dimanche 21 juin 2015 17:16:07 jan i a écrit : > > >> +1 switch as soon as possible, and then continue working on the data > end. > > >> > > >> rgds > > >> jan i > > >> > > >> On Sunday, June 21, 2015, Hervé BOUTEMY > wrote: > > >> > Le dimanche 21 juin 2015 15:54:29 jan i a écrit : > > >> > > On 21 June 2015 at 15:48, Daniel Gruno > >> > > > >> > > wrote: > > >> > > > On 2015-06-21 02:45, Hervé BOUTEMY wrote: > > >> > > >> for me, the new site is ready: there is of course room for > > >> > > > >> > improvements, > > >> > > > >> > > >> but > > >> > > >> it is stable and maintainable, waiting for contributions > > >> > > >> > > >> > > >> notice: I changed the wording to stop using "TLP", but use > > >> > > >> "Committee" > > >> > > >> instead, since TLP cause issues when trying to describe each > > >> > > >> projects > > >> > > >> (the > > >> > > >> software) as TLP or sub-projects > > >> > > >> > > >> > > >> > > >> > > >> when doing the switch, we'll need to rename current site as > > >> > > >> projects- > > >> > > >> old.apache.org: there is some content to migrate (DOAP, > > >> > > > >> > documentation) > > >> > > > >> > > >> associated to communication with projects on the changes that > has > > >> > > >> to > > >> > > > >> > be > > >> > > > >> > > >> decoupled from public vizualisation. I'll continue working on > it. > > >> > > >> > > >> > > >> There one choice to do: continue serving the pages from > current VM > > >> > > >> or > > >> > > >> serve > > >> > > >> through standard resilient httpds. The VM is useful for cron > jobs, > > >> > > > >> > but is > > >> > > > >> > > >> not > > >> > > >> absolutely necessary for serving content since I removed online > > >> > > > >> > content > > >> > > > >> > > >> editing that caused the VM requirement for content serving > AFAIK. > > >> > > > >> > Using > > >> > > > >> > > >> standard httpd will avoid SPOF or eventual load issue. > > >> > > > > > >> > > > What do you mean by 'standard httpd'? It already uses...standard > > >> > > > httpd > > >> > > > >> > for > > >> > > > >> > > > serving the site. > > >> > > > The cron jobs are needed for updating various statistics and > data > > >> > > > on > > >> > > > >> >
Re: apacheCON: core, barcamp.
On 26 June 2015 at 13:03, jean-frederic clere wrote: > On 06/26/2015 12:42 PM, jan i wrote: > >> Hi >> >> apacheCON: core is 2 days in budapest (october 1-2), but there will still >> be place to hold a >> barcamp. >> > > +1 I can do it as last time ;-) > you just got a job :-) Please add a presentation type "lab" with the title "barcamp" so we can schedule it. rgds jan i. > > Cheers > > Jean-Frederic >
Re: apacheCON: core, barcamp.
On 06/26/2015 12:42 PM, jan i wrote: Hi apacheCON: core is 2 days in budapest (october 1-2), but there will still be place to hold a barcamp. +1 I can do it as last time ;-) Cheers Jean-Frederic
apacheCON: core, barcamp.
Hi apacheCON: core is 2 days in budapest (october 1-2), but there will still be place to hold a barcamp. We look for a volunteer to help organize it, if you are interested please email me. Please do not forget to submit your talks, CFP for this event closes july 1, and currently we have plenty of free slots. on behalf of the apacheCON team jan i.
Twitter account, barcamp.
Hi. Does anybody which email is registred for our barcamp twitter account. Help is: *co@a*. I wanted to login and tweet about apacheCON, but got stuck by this mail question. thanks in advance for fast help. rgds jan i.
Re: Can't reporter.a.o automatically detect version number and release date?
On 25.06.2015 17:40, Martijn Dashorst wrote: > And there is no rule (yet) that there is only one format to rule them > all. A transformation rule specified at project level in the reporter > tool could do the trick as well. Yah ... have each project define a (set of) regular expressions and use the contents of \1. -- Brane > > On Thu, Jun 25, 2015 at 5:17 PM, Niclas Hedhman wrote: >> Alex, >> I think you made an assumption that "format" meant naming schemes of >> releases, but it didn't. Simple "a defined way" to make that available for >> reporter to pick it up with relative ease. >> Your suggestion of a doap-based solution is equally a "format". The >> important part, I think, is that "whatever way is chosen", that it is >> documented and notified to PMCs, with optionality to use it. >> >> For me; DOAP is as good as anything, although there are probably a great >> demand for linking that with Maven publishing "somehow". Since our Gradle >> build is generating all kinds of meta data output anyway, one more wouldn't >> hurt much. >> >> Cheers >> >> On Thu, Jun 25, 2015 at 10:31 PM, Alex Harui wrote: >> >>> >>> On 6/25/15, 7:18 AM, "hedh...@gmail.com on behalf of Niclas Hedhman" >>> wrote: >>> If the "format" is published, and the "reward" of following it would be that the reporter picks it up automatically, it could lead to swift adoption ;-) >>> You might get push back about having to change naming schemes. >>> >>> I’m interested in a list of all current and past releases for my project. >>> I was trying to figure out how to mine archive.a.o or the svn log for it. >>> I’d be willing to maintain an xml file like in DOAP or elsewhere of not >>> just the last, but all releases and links to their downloads with >>> “friendly” names for the releases. Then reporter.a.o could grab from that. >>> >>> -Alex >>> On Thu, Jun 25, 2015 at 9:26 PM, Daniel Gruno wrote: > It has been tried, and it did not work. > People are too inconsistent across projects in how they name their > release > files, grabbing the version is nigh impossible. > If we had some form of agreement on how to name files, then it would be > possible. > > With regards, > Daniel. > > > On 2015-06-25 15:11, Martijn Dashorst wrote: > >> Is there a reason why the reporter.a.o can send a message to a release >> manager that it detected a new release, but is incapable of >> determining a version number and release date? >> >> Martijn >> > -- Niclas Hedhman, Software Developer http://zest.apache.org - New Energy for Java >>> >> >> -- >> Niclas Hedhman, Software Developer >> http://zest.apache.org - New Energy for Java > >
