Re: New maintenance.

[sebb]

On 22 April 2018 at 15:53, Henk P. Penning  wrote:
> On Sun, 22 Apr 2018, j...@apache.org wrote:
>
>> Date: Sun, 22 Apr 2018 15:53:52 +0200
>> From: j...@apache.org
>> To: general@attic.apache.org
>> Subject: New maintenance.
>
>
>> Based on site-json I propose the following changes:
>>
>> Change docs/scripts/attic.js to project.json (kept as pure json outside
>> docs).
>
>
>   Also, I /really/ would like to have the .json available for 'others',
>   so inside docs/ please.

Fine.

However the source of the data does not have to be in docs so long as
there is a generated copy in docs.

There may be info in the source that is not really needed externally
(so it can be omitted from the docs copy).
For example 'apply-banner' does not really seem to be relevant to 3rd parties.

It is easy enough to create a single data file in a suitable format
for external use as part of the site generation.

>   Let's call the .json 'attic.json' ;
>   for 'others' the .json describes what PMC attic has done.

OK.

>> Remove xdocs.
>
>
>   Ok.
>
>> Allow a build job to monitor for svn changes and if any active a
>> generation script.
>>
>> The generation script does the following:
>> - generate a sidebar.inc which is included (physically in all files)
>> - Generate a page pr. project in projects, based on a 1 template
>>   “project.md” or similar
>
>
>   Eh, no ; if the build scripts creates the attic.js (from a template
>   and 'attic.json') we are done ; this is much closer to what we have
>   now.

What we have now is one XML file per project.
I am suggesting one Markdown file per project instead.

This would contain a header with the data values, followed by optional
body text.
The data would be processed against a template.

>> - Generate a flagged directory (if field “flag” is present in the JSON
>> object”)
>
>
>   perhaps we should go with 'retired' (as opposed to 'flagged/')
>   after all ; this makes it easier to fix the httpd config as
>   a separate issue ; we'll rm -rf flagged/ later.

I think the name should relate to the function.
'retired' is too general.
Why not 'add-banner' ?

>> Ps. I can help to change attic.js, but I am afraid the generate script is
>> for someone else to write.
>
>
>   Can we please go for a simple Makefile ? So we can simply do :
>
> -- svn up
> -- edit json
> -- make
> -- commit
>
>
> Sebb,
>
>   I am totally ignorant re: build stuff ; can the build stuff run a make ?

The buildbot can run any shell command, so it could run make.

But a simple shell script is likely to be sufficient.
I don't see any need to use make.

>   Groeten,
>
>   HPP
>
>    _
> Henk P. Penning, ICT-beta R Uithof MG-403_/ \_
> Faculty of Science, Utrecht UniversityT +31 30 253 4106 / \_/ \
> Leuvenlaan 4, 3584CE Utrecht, NL  F +31 30 253 4553 \_/ \_/
> http://www.staff.science.uu.nl/~penni101/ M penn...@uu.nl \_/

Re: New maintenance.

[sebb]

On 22 April 2018 at 15:48, Jan Iversen  wrote:
>
>
>> On 22 Apr 2018, at 16:41, sebb  wrote:
>>
>> On 22 April 2018 at 14:53,  > wrote:
>>> Hi
>>>
>>> Looking at the latest emails, it seems like a compromise between the 2 
>>> solutions are the best solution.
>>>
>>> How about if the combine the proposals to the following (that would make my 
>>> life easier, and hopefully satisfy the majority of problems Sebb see).
>>>
>>>
>>> Based on site-json I propose the following changes:
>>>
>>> Change docs/scripts/attic.js to project.json (kept as pure json outside 
>>> docs).
>>> Remove xdocs.
>>>
>>> Allow a build job to monitor for svn changes and if any active a generation 
>>> script.
>>>
>>> The generation script does the following:
>>> - generate a sidebar.inc which is included (physically in all files)
>>
>> Not sure how you mean the inclusion to work.
>> Do you mean a server-side include? That increases the load on the
>> server, but Infra may agree to it.
>> Or would the project.md template be processed to include the contents?
>
> Sorry for not being clear, yes project.md should automatically include it if 
> possible, otherwise the generator.sh should write it. We want the site to be 
> totally static.
>

OK, so there will need to be a generator script to take the template
and apply each section of the data file to it.

I don't think it makes sense to design a new templating system, so I
think we need to use an existing one.

Do you still object to using Jekyll?

>>
>>> - Generate a page pr. project in projects, based on a 1 template 
>>> “project.md” or similar
>>
>> What would convert project.md into projects/project.html?
> generate.sh or something similar.
>>
>> What about the additional data that is present in many of the XML files?
>> Where would that be stored?
> I suggest to use “description” or add a second field “additional” in JSON, 
> both solutions are OK with me.

Description is not suitable for all the data.

>> It's really awkward to put it in projects.json.
>
> For me, only touching1 file is the highest importance in a new maintenance 
> model, apart from that, you talk about history, this has not happened for a 
> very long time, so it is a onetime effort.

I still don't understand why it is so important to have all the
project data in a single file.

I agree that one should not have to edit two different files to record
the data for a single project, but I don't see what the problem is
with having a single file for each project.
There would still only be a single file to edit, but it would be a
different file for each project.

>>
>>> - Generate a flagged directory (if field “flag” is present in the JSON 
>>> object”)
>>
>> OK.
>>
>>> This solves all URL issues, the concern about JS, all redirection issues as 
>>> far as I can see…and (to me) importantly maintenance is updating 
>>> projects.json and nothing more (related to the site).
>>>
>>> How do you all feel about this compromise ?
>>
>> I think it is closer, but it does not cover the requirement to
>> preserve the existing additional data in the XML files.
>
> Yes, either in “description” (one time effort, even though e.x. taglibs 
> require some editing) or in an additional field (same work).

In either case, adding more than a few words of text to a JSON value
is hard work, especially if there are HTML tags and quotes involved.
Any subsequent maintenance is hard (e.g. to correct spelling etc.)
It is similar to editing compressed CSS.
We should not be creating unmaintainable data files.

> I can guarantee as long as I am the maintener there will not be additional 
> projects with this feature, mainly because that information should already be 
> available on the respective HP.

The information is generally not on the home page because it is not
relevant to an active project.
It is only after the project retires that the additional information
may need to be provided.

> rgds
> Jan I
>>
>>> rgds
>>> Jan I.
>>>
>>> Ps. I can help to change attic.js, but I am afraid the generate script is 
>>> for someone else to write.
>

Re: New maintenance.

[Jan Iversen]

> On 22 Apr 2018, at 16:53, Henk P. Penning  wrote:
> 
> On Sun, 22 Apr 2018, j...@apache.org wrote:
> 
>> Date: Sun, 22 Apr 2018 15:53:52 +0200
>> From: j...@apache.org
>> To: general@attic.apache.org
>> Subject: New maintenance.
> 
>> Based on site-json I propose the following changes:
>> 
>> Change docs/scripts/attic.js to project.json (kept as pure json outside 
>> docs).
> 
>  Also, I /really/ would like to have the .json available for 'others',
>  so inside docs/ please.
> 
>  Let's call the .json 'attic.json' ;
>  for 'others' the .json describes what PMC attic has done.
OK
> 
>> Remove xdocs.
> 
>  Ok.
> 
>> Allow a build job to monitor for svn changes and if any active a
>> generation script.
>> 
>> The generation script does the following:
>> - generate a sidebar.inc which is included (physically in all files)
>> - Generate a page pr. project in projects, based on a 1 template
>>  “project.md” or similar
> 
>  Eh, no ; if the build scripts creates the attic.js (from a template
>  and 'attic.json') we are done ; this is much closer to what we have
>  now.
> 

I would not use attic.js any longer, it is not needed if we have a build job 
that generates whatever needs to be generated.

>> - Generate a flagged directory (if field “flag” is present in the JSON
>> object”)
> 
>  perhaps we should go with 'retired' (as opposed to 'flagged/')
>  after all ; this makes it easier to fix the httpd config as
>  a separate issue ; we'll rm -rf flagged/ later.
Agree to that.

> 
>> Ps. I can help to change attic.js, but I am afraid the generate script is 
>> for someone else to write.
> 
>  Can we please go for a simple Makefile ? So we can simply do :
> 
>-- svn up
>-- edit json
The part above is online and not part of the build job
>-- make
>— commit
Those 2 should be build job.

> 
> Sebb,
> 
>  I am totally ignorant re: build stuff ; can the build stuff run a make ?
Make or just a script, that is something I would leave to Sebb to decide 
whatever is easier to make and maintain.

To me the “edit json” is the real important part, the rest is just “magic” 
happening :-)

rgds
Jan I
> 
>  Groeten,
> 
>  HPP
> 
>    _
> Henk P. Penning, ICT-beta R Uithof MG-403_/ \_
> Faculty of Science, Utrecht UniversityT +31 30 253 4106 / \_/ \
> Leuvenlaan 4, 3584CE Utrecht, NL  F +31 30 253 4553 \_/ \_/
> http://www.staff.science.uu.nl/~penni101/ M penn...@uu.nl \_/

Re: New maintenance.

[Henk P. Penning]

On Sun, 22 Apr 2018, j...@apache.org wrote:


Date: Sun, 22 Apr 2018 15:53:52 +0200
From: j...@apache.org
To: general@attic.apache.org
Subject: New maintenance.



Based on site-json I propose the following changes:

Change docs/scripts/attic.js to project.json (kept as pure json outside docs).


  Also, I /really/ would like to have the .json available for 'others',
  so inside docs/ please.

  Let's call the .json 'attic.json' ;
  for 'others' the .json describes what PMC attic has done.


Remove xdocs.


  Ok.


Allow a build job to monitor for svn changes and if any active a
generation script.

The generation script does the following:
- generate a sidebar.inc which is included (physically in all files)
- Generate a page pr. project in projects, based on a 1 template
  “project.md” or similar


  Eh, no ; if the build scripts creates the attic.js (from a template
  and 'attic.json') we are done ; this is much closer to what we have
  now.


- Generate a flagged directory (if field “flag” is present in the JSON
object”)


  perhaps we should go with 'retired' (as opposed to 'flagged/')
  after all ; this makes it easier to fix the httpd config as
  a separate issue ; we'll rm -rf flagged/ later.


Ps. I can help to change attic.js, but I am afraid the generate script is for 
someone else to write.


  Can we please go for a simple Makefile ? So we can simply do :

-- svn up
-- edit json
-- make
-- commit

Sebb,

  I am totally ignorant re: build stuff ; can the build stuff run a make ?

  Groeten,

  HPP

   _
Henk P. Penning, ICT-beta R Uithof MG-403_/ \_
Faculty of Science, Utrecht UniversityT +31 30 253 4106 / \_/ \
Leuvenlaan 4, 3584CE Utrecht, NL  F +31 30 253 4553 \_/ \_/
http://www.staff.science.uu.nl/~penni101/ M penn...@uu.nl \_/

Re: New maintenance.

[Jan Iversen]

> On 22 Apr 2018, at 16:41, sebb  wrote:
> 
> On 22 April 2018 at 14:53,  > wrote:
>> Hi
>> 
>> Looking at the latest emails, it seems like a compromise between the 2 
>> solutions are the best solution.
>> 
>> How about if the combine the proposals to the following (that would make my 
>> life easier, and hopefully satisfy the majority of problems Sebb see).
>> 
>> 
>> Based on site-json I propose the following changes:
>> 
>> Change docs/scripts/attic.js to project.json (kept as pure json outside 
>> docs).
>> Remove xdocs.
>> 
>> Allow a build job to monitor for svn changes and if any active a generation 
>> script.
>> 
>> The generation script does the following:
>> - generate a sidebar.inc which is included (physically in all files)
> 
> Not sure how you mean the inclusion to work.
> Do you mean a server-side include? That increases the load on the
> server, but Infra may agree to it.
> Or would the project.md template be processed to include the contents?

Sorry for not being clear, yes project.md should automatically include it if 
possible, otherwise the generator.sh should write it. We want the site to be 
totally static.


> 
>> - Generate a page pr. project in projects, based on a 1 template 
>> “project.md” or similar
> 
> What would convert project.md into projects/project.html?
generate.sh or something similar.
> 
> What about the additional data that is present in many of the XML files?
> Where would that be stored?
I suggest to use “description” or add a second field “additional” in JSON, both 
solutions are OK with me.

> It's really awkward to put it in projects.json.

For me, only touching1 file is the highest importance in a new maintenance 
model, apart from that, you talk about history, this has not happened for a 
very long time, so it is a onetime effort.

> 
>> - Generate a flagged directory (if field “flag” is present in the JSON 
>> object”)
> 
> OK.
> 
>> This solves all URL issues, the concern about JS, all redirection issues as 
>> far as I can see…and (to me) importantly maintenance is updating 
>> projects.json and nothing more (related to the site).
>> 
>> How do you all feel about this compromise ?
> 
> I think it is closer, but it does not cover the requirement to
> preserve the existing additional data in the XML files.

Yes, either in “description” (one time effort, even though e.x. taglibs require 
some editing) or in an additional field (same work). 

I can guarantee as long as I am the maintener there will not be additional 
projects with this feature, mainly because that information should already be 
available on the respective HP.

rgds
Jan I
> 
>> rgds
>> Jan I.
>> 
>> Ps. I can help to change attic.js, but I am afraid the generate script is 
>> for someone else to write.

Re: New maintenance.

[sebb]

On 22 April 2018 at 14:53,   wrote:
> Hi
>
> Looking at the latest emails, it seems like a compromise between the 2 
> solutions are the best solution.
>
> How about if the combine the proposals to the following (that would make my 
> life easier, and hopefully satisfy the majority of problems Sebb see).
>
>
> Based on site-json I propose the following changes:
>
> Change docs/scripts/attic.js to project.json (kept as pure json outside docs).
> Remove xdocs.
>
> Allow a build job to monitor for svn changes and if any active a generation 
> script.
>
> The generation script does the following:
> - generate a sidebar.inc which is included (physically in all files)

Not sure how you mean the inclusion to work.
Do you mean a server-side include? That increases the load on the
server, but Infra may agree to it.
Or would the project.md template be processed to include the contents?

> - Generate a page pr. project in projects, based on a 1 template “project.md” 
> or similar

What would convert project.md into projects/project.html?

What about the additional data that is present in many of the XML files?
Where would that be stored?
It's really awkward to put it in projects.json.

> - Generate a flagged directory (if field “flag” is present in the JSON 
> object”)

OK.

> This solves all URL issues, the concern about JS, all redirection issues as 
> far as I can see…and (to me) importantly maintenance is updating 
> projects.json and nothing more (related to the site).
>
> How do you all feel about this compromise ?

I think it is closer, but it does not cover the requirement to
preserve the existing additional data in the XML files.

> rgds
> Jan I.
>
> Ps. I can help to change attic.js, but I am afraid the generate script is for 
> someone else to write.

Re: svn commit: r1829770 - in /attic/site-json: build.props build.sh build.xml docs/projects/ lib/ xdocs/

[Jan Iversen]

> On 22 Apr 2018, at 16:24, Henk P. Penning  wrote:
> 
> On Sun, 22 Apr 2018, Jan Iversen wrote:
> 
>> Date: Sun, 22 Apr 2018 14:34:29 +0200
>> From: Jan Iversen 
>> To: general@attic.apache.org
>> Subject: Re: svn commit: r1829770 - in /attic/site-json: build.props build.sh
>>build.xml docs/projects/ lib/ xdocs/
> 
 The 'name' attribute in the JSON in "attic.js".
> 
>>> That is the text for the project list in the RH menu, and is free-format.
>>> It's not directly convertible into a dist/ directory name.
>>> So I agree that a dist attribute would be needed for at least some entries.
> 
>> That is the reason for the “website” field. If we want to use the name
>> alone, that field could be split in 2.
> 
>  IHMO it is better to derive attribute 'website' (as $dist.apache.org)
>  from a 'dist' attribute, than the other way around ; nevermind.
> 
>>> I hope dist names are the same as TLP website names but I've not checked.
>> The field “board” was added where I had problems between the TLP name
>> used in Whimsy and the normal name.
> 
>  I see only two entries with non-empty "board" fields ;
>  the first isn't necessary ; the second isn't helpful
>  in mapping to the right /dist/GHOST tag :
> 
>"name":"Crimson",
>"board":   "crimson",
> 
>"name":"Standard C++ Library (STDCXX)",
>"board":   "Cxx_Standard_Library",
> 
>  Let's have a 'dist' attribute for entries that need it.
>  default : lowercase($name).
>  sanity  : if $name matches whitespace then $dist must not be empty.
> 
>  Let's remove 'board' in entries where board == ‘'.
Agreed to all.

rgds
Jan I
> 
>  Regards,
> 
>  HPP
> 
>    _
> Henk P. Penning, ICT-beta R Uithof MG-403_/ \_
> Faculty of Science, Utrecht UniversityT +31 30 253 4106 / \_/ \
> Leuvenlaan 4, 3584CE Utrecht, NL  F +31 30 253 4553 \_/ \_/
> http://www.staff.science.uu.nl/~penni101/ M penn...@uu.nl \_/

Re: svn commit: r1829770 - in /attic/site-json: build.props build.sh build.xml docs/projects/ lib/ xdocs/

[Henk P. Penning]

On Sun, 22 Apr 2018, Jan Iversen wrote:


Date: Sun, 22 Apr 2018 14:34:29 +0200
From: Jan Iversen 
To: general@attic.apache.org
Subject: Re: svn commit: r1829770 - in /attic/site-json: build.props build.sh
build.xml docs/projects/ lib/ xdocs/



 The 'name' attribute in the JSON in "attic.js".



That is the text for the project list in the RH menu, and is free-format.
It's not directly convertible into a dist/ directory name.
So I agree that a dist attribute would be needed for at least some entries.



That is the reason for the “website” field. If we want to use the name
alone, that field could be split in 2.


  IHMO it is better to derive attribute 'website' (as $dist.apache.org)
  from a 'dist' attribute, than the other way around ; nevermind.


I hope dist names are the same as TLP website names but I've not checked.

The field “board” was added where I had problems between the TLP name
used in Whimsy and the normal name.


  I see only two entries with non-empty "board" fields ;
  the first isn't necessary ; the second isn't helpful
  in mapping to the right /dist/GHOST tag :

"name":"Crimson",
"board":   "crimson",

"name":"Standard C++ Library (STDCXX)",
"board":   "Cxx_Standard_Library",

  Let's have a 'dist' attribute for entries that need it.
  default : lowercase($name).
  sanity  : if $name matches whitespace then $dist must not be empty.

  Let's remove 'board' in entries where board == ''.

  Regards,

  HPP

   _
Henk P. Penning, ICT-beta R Uithof MG-403_/ \_
Faculty of Science, Utrecht UniversityT +31 30 253 4106 / \_/ \
Leuvenlaan 4, 3584CE Utrecht, NL  F +31 30 253 4553 \_/ \_/
http://www.staff.science.uu.nl/~penni101/ M penn...@uu.nl \_/

New maintenance.

[jani]

Hi

Looking at the latest emails, it seems like a compromise between the 2 
solutions are the best solution.

How about if the combine the proposals to the following (that would make my 
life easier, and hopefully satisfy the majority of problems Sebb see).


Based on site-json I propose the following changes:

Change docs/scripts/attic.js to project.json (kept as pure json outside docs).
Remove xdocs.

Allow a build job to monitor for svn changes and if any active a generation 
script.

The generation script does the following:
- generate a sidebar.inc which is included (physically in all files)
- Generate a page pr. project in projects, based on a 1 template “project.md” 
or similar
- Generate a flagged directory (if field “flag” is present in the JSON object”)

This solves all URL issues, the concern about JS, all redirection issues as far 
as I can see…and (to me) importantly maintenance is updating projects.json and 
nothing more (related to the site).

How do you all feel about this compromise ?

rgds
Jan I.

Ps. I can help to change attic.js, but I am afraid the generate script is for 
someone else to write.

Re: svn commit: r1829770 - in /attic/site-json: build.props build.sh build.xml docs/projects/ lib/ xdocs/

[sebb]

On 22 April 2018 at 13:04, Henk P. Penning  wrote:
> On Sun, 22 Apr 2018, sebb wrote:
>
>> Date: Sun, 22 Apr 2018 13:53:15 +0200
>> From: sebb 
>> To: general@attic.apache.org
>> Subject: Re: svn commit: r1829770 - in /attic/site-json: build.props
>> build.sh
>> build.xml docs/projects/ lib/ xdocs/
>
>
>>>   Eh ; just a reminder ; the httpd config for www.a.o uses :
>>>
>>> RewriteCond "%%{}{REQUEST_URI}" "^/dist/([-a-zA-Z0-9]+)"
>>> RewriteCond "/var/www/attic.apache.org/projects/%1.html" -f
>>> RewriteRule ".*" "http://attic.apache.org/projects/%1.html; [R=307,L]
>>>
>>>   In other words : the /dist/GHOST/ redirects are triggered
>>>   by the presence of "attic.apache.org/projects/GHOST.html".
>>>
>>>   The point is that the lookup [-f] has to fast.
>>>   In the future we should create a directory (like "flagged/") ;
>>>   possibly combine the two, as in :
>>>
>>> attic.a.o/retired/
>>> attic.a.o/retired/GHOST/# retired flag
>>> attic.a.o/retired/GHOST/add-banner  # banner flag
>>
>>
>> The dist redirect needs the plain host name, e.g. ace, whereas AFAIK
>> the banner processing needs FQDN, e.g. ace[.eu|us].apache.org.
>> So that won't work unless the banner processing can be changed to use
>> the plain host name.
>
>
>   Right ; if we stay with /flagged/, the dist trigger can changed as :
>
>   - RewriteCond "/var/www/attic.apache.org/projects/%1.html" -f
>   + RewriteCond "/var/www/attic.apache.org/flagged/%1.apache.org/" -d
>
>   ... and the banner-trigger :
>
>   - 
>   + 

Surely HTTP_HOST is GHOST.apache.org?
For example we currently have:

https://svn.apache.org/repos/asf/attic/site-json/docs/flagged/oltu.apache.org/oltu.apache.org

>> But I agree it would be good to reduce the number of files that have
>> to be created/amended for a new retirement.
>
>
>   Eventually, we should generate the 'flagged' stuff.

That would require a buildbot job or similar in order to make it
simpler for tablet users.

>>>   Does it make sense to have an (optional) 'dist' attribute,
>>>   for sites where "lowercase(name)" is not equal to the
>>>   the NAME in /dist/NAME ?
>>
>>
>> Which 'name' are you referring to here?
>
>
>   The 'name' attribute in the JSON in "attic.js".

I see.
That is the text for the project list in the RH menu, and is free-format.
It's not directly convertible into a dist/ directory name.
So I agree that a dist attribute would be needed for at least some entries.

I hope dist names are the same as TLP website names but I've not checked.

>   Regards,
>
>
>   HPP
>
>    _
> Henk P. Penning, ICT-beta R Uithof MG-403_/ \_
> Faculty of Science, Utrecht UniversityT +31 30 253 4106 / \_/ \
> Leuvenlaan 4, 3584CE Utrecht, NL  F +31 30 253 4553 \_/ \_/
> http://www.staff.science.uu.nl/~penni101/ M penn...@uu.nl \_/

Re: svn commit: r1829770 - in /attic/site-json: build.props build.sh build.xml docs/projects/ lib/ xdocs/

[Henk P. Penning]

On Sun, 22 Apr 2018, sebb wrote:


Date: Sun, 22 Apr 2018 13:53:15 +0200
From: sebb 
To: general@attic.apache.org
Subject: Re: svn commit: r1829770 - in /attic/site-json: build.props build.sh
build.xml docs/projects/ lib/ xdocs/



  Eh ; just a reminder ; the httpd config for www.a.o uses :

RewriteCond "%%{}{REQUEST_URI}" "^/dist/([-a-zA-Z0-9]+)"
RewriteCond "/var/www/attic.apache.org/projects/%1.html" -f
RewriteRule ".*" "http://attic.apache.org/projects/%1.html; [R=307,L]

  In other words : the /dist/GHOST/ redirects are triggered
  by the presence of "attic.apache.org/projects/GHOST.html".

  The point is that the lookup [-f] has to fast.
  In the future we should create a directory (like "flagged/") ;
  possibly combine the two, as in :

attic.a.o/retired/
attic.a.o/retired/GHOST/# retired flag
attic.a.o/retired/GHOST/add-banner  # banner flag


The dist redirect needs the plain host name, e.g. ace, whereas AFAIK
the banner processing needs FQDN, e.g. ace[.eu|us].apache.org.
So that won't work unless the banner processing can be changed to use
the plain host name.


  Right ; if we stay with /flagged/, the dist trigger can changed as :

  - RewriteCond "/var/www/attic.apache.org/projects/%1.html" -f
  + RewriteCond "/var/www/attic.apache.org/flagged/%1.apache.org/" -d

  ... and the banner-trigger :

  - 
  + 


But I agree it would be good to reduce the number of files that have
to be created/amended for a new retirement.


  Eventually, we should generate the 'flagged' stuff.


  Does it make sense to have an (optional) 'dist' attribute,
  for sites where "lowercase(name)" is not equal to the
  the NAME in /dist/NAME ?


Which 'name' are you referring to here?


  The 'name' attribute in the JSON in "attic.js".

  Regards,

  HPP

   _
Henk P. Penning, ICT-beta R Uithof MG-403_/ \_
Faculty of Science, Utrecht UniversityT +31 30 253 4106 / \_/ \
Leuvenlaan 4, 3584CE Utrecht, NL  F +31 30 253 4553 \_/ \_/
http://www.staff.science.uu.nl/~penni101/ M penn...@uu.nl \_/

Re: svn commit: r1829770 - in /attic/site-json: build.props build.sh build.xml docs/projects/ lib/ xdocs/

[sebb]

On 22 April 2018 at 12:12, Henk P. Penning  wrote:
> On Sun, 22 Apr 2018, Jan Iversen wrote:
>
>> Date: Sun, 22 Apr 2018 12:42:39 +0200
>> From: Jan Iversen 
>> To: general@attic.apache.org
>> Subject: Re: svn commit: r1829770 - in /attic/site-json: build.props
>> build.sh
>> build.xml docs/projects/ lib/ xdocs/
>
>
>>>attic/site-json/docs/projects/
>>
>> I think this is wrong ? The idea was to have projects/.htaccess with
>> the rewrite to attic.js
>
>
>   Eh ; just a reminder ; the httpd config for www.a.o uses :
>
> RewriteCond "%%{}{REQUEST_URI}" "^/dist/([-a-zA-Z0-9]+)"
> RewriteCond "/var/www/attic.apache.org/projects/%1.html" -f
> RewriteRule ".*" "http://attic.apache.org/projects/%1.html; [R=307,L]
>
>   In other words : the /dist/GHOST/ redirects are triggered
>   by the presence of "attic.apache.org/projects/GHOST.html".
>
>   The point is that the lookup [-f] has to fast.
>   In the future we should create a directory (like "flagged/") ;
>   possibly combine the two, as in :
>
> attic.a.o/retired/
> attic.a.o/retired/GHOST/# retired flag
> attic.a.o/retired/GHOST/add-banner  # banner flag

The dist redirect needs the plain host name, e.g. ace, whereas AFAIK
the banner processing needs FQDN, e.g. ace[.eu|us].apache.org.
So that won't work unless the banner processing can be changed to use
the plain host name.

But I agree it would be good to reduce the number of files that have
to be created/amended for a new retirement.

>   Does it make sense to have an (optional) 'dist' attribute,
>   for sites where "lowercase(name)" is not equal to the
>   the NAME in /dist/NAME ?

Which 'name' are you referring to here?

>> Jan I
>
>
>   HPP
>
>    _
> Henk P. Penning, ICT-beta R Uithof MG-403_/ \_
> Faculty of Science, Utrecht UniversityT +31 30 253 4106 / \_/ \
> Leuvenlaan 4, 3584CE Utrecht, NL  F +31 30 253 4553 \_/ \_/
> http://www.staff.science.uu.nl/~penni101/ M penn...@uu.nl \_/

svn commit: r1829781 - /attic/site/docs/.htaccess

[sebb]

Author: sebb
Date: Sun Apr 22 11:36:22 2018
New Revision: 1829781

URL: http://svn.apache.org/viewvc?rev=1829781=rev
Log:
It does; remove the test file

Removed:
attic/site/docs/.htaccess

svn commit: r1829780 - /attic/site/docs/.htaccess

[sebb]

Author: sebb
Date: Sun Apr 22 11:35:31 2018
New Revision: 1829780

URL: http://svn.apache.org/viewvc?rev=1829780=rev
Log:
Does .htaccess work?

Added:
attic/site/docs/.htaccess   (with props)

Added: attic/site/docs/.htaccess
URL: 
http://svn.apache.org/viewvc/attic/site/docs/.htaccess?rev=1829780=auto
==
--- attic/site/docs/.htaccess (added)
+++ attic/site/docs/.htaccess Sun Apr 22 11:35:31 2018
@@ -0,0 +1,2 @@
+# Temporary test to see if Redirect works:
+Redirect /projects/ACE.html /projects/ace.html
\ No newline at end of file

Propchange: attic/site/docs/.htaccess
--
svn:eol-style = native

Re: svn commit: r1829770 - in /attic/site-json: build.props build.sh build.xml docs/projects/ lib/ xdocs/

[sebb]

On 22 April 2018 at 11:42, Jan Iversen  wrote:
>
>
>> On 22 Apr 2018, at 12:41, s...@apache.org wrote:
>>
>> Author: sebb
>> Date: Sun Apr 22 10:41:16 2018
>> New Revision: 1829770
>>
>> URL: http://svn.apache.org/viewvc?rev=1829770=rev
>> Log:
>> Reduce to proposed source files
>>
>> Removed:
>>attic/site-json/build.props
>>attic/site-json/build.sh
>>attic/site-json/build.xml
>>attic/site-json/docs/projects/
> I think this is wrong ? The idea was to have projects/.htaccess with the 
> rewrite to attic.js

The intention was to ensure that the old html files were not used accidentally.

Note that an .htaccess file could also be placed in the main directory
or the redirect could be done by the server config.
Indeed it may have to be done there if .htaccess files are disallowed.

But it is easy enough to add the folder back if/when it is needed.

>>attic/site-json/lib/
>>attic/site-json/xdocs/
>>
>
>
> Rgds
> Jan I
>

svn commit: r1829775 - /attic/site-json/docs/scripts/attic.js

[sebb]

Author: sebb
Date: Sun Apr 22 10:50:01 2018
New Revision: 1829775

URL: http://svn.apache.org/viewvc?rev=1829775=rev
Log:
Jakarta parent should be displayed first (agrees with existing)

Modified:
attic/site-json/docs/scripts/attic.js

Modified: attic/site-json/docs/scripts/attic.js
URL: 
http://svn.apache.org/viewvc/attic/site-json/docs/scripts/attic.js?rev=1829775=1829774=1829775=diff
==
--- attic/site-json/docs/scripts/attic.js (original)
+++ attic/site-json/docs/scripts/attic.js Sun Apr 22 10:50:01 2018
@@ -250,6 +250,18 @@ var jsonObj = JSON.parse(`
"description": "iBATIS was a data mapper framework that made it easier to 
use a relational database with object-oriented applications. There were both 
Java and .Net implementations."
 },
 {
+   "name":"Jakarta",
+   "website": "http://jakarta.apache.org;,
+   "retired": "12/2011",
+   "source code": "http://svn.apache.org/repos/asf/jakarta;,
+   "issues":  "",
+   "wiki":"https://wiki.apache.org/jakarta;,
+   "maillists":   {"announcements": 
"http://mail-archives.apache.org/mod_mbox/jakarta-announcements;,
+   "dev": 
"http://mail-archives.apache.org/mod_mbox/jakarta-dev;
+  },
+   "description": "Jakarta Project housed a diverse set of popular open source 
Java solutions."
+},
+{
"name":"Jakarta Cactus",
"website": "http://jakarta.apache.org/cactus;,
"retired": "08/2011",
@@ -326,18 +338,6 @@ var jsonObj = JSON.parse(`
"description": "Jakarta hosted the Jakarta Taglibs project, a large 
collection of JSP Tag Libraries. They ranged from simple utility libraries and 
UI libraries, to Dreamweaver extensions and an implementation of the JSP 
Standard Tag Library (JSTL) specification."
 },
 {
-   "name":"Jakarta",
-   "website": "http://jakarta.apache.org;,
-   "retired": "12/2011",
-   "source code": "http://svn.apache.org/repos/asf/jakarta;,
-   "issues":  "",
-   "wiki":"https://wiki.apache.org/jakarta;,
-   "maillists":   {"announcements": 
"http://mail-archives.apache.org/mod_mbox/jakarta-announcements;,
-   "dev": 
"http://mail-archives.apache.org/mod_mbox/jakarta-dev;
-  },
-   "description": "Jakarta Project housed a diverse set of popular open source 
Java solutions."
-},
-{
"name":"Lenya",
"website": "http://lenya.apache.org;,
"retired": "04/2015",

svn commit: r1829774 - /attic/site-json/docs/scripts/attic.js

[sebb]

Author: sebb
Date: Sun Apr 22 10:48:24 2018
New Revision: 1829774

URL: http://svn.apache.org/viewvc?rev=1829774=rev
Log:
Fix up project names to agree with existing

Modified:
attic/site-json/docs/scripts/attic.js

Modified: attic/site-json/docs/scripts/attic.js
URL: 
http://svn.apache.org/viewvc/attic/site-json/docs/scripts/attic.js?rev=1829774=1829773=1829774=diff
==
--- attic/site-json/docs/scripts/attic.js (original)
+++ attic/site-json/docs/scripts/attic.js Sun Apr 22 10:48:24 2018
@@ -302,6 +302,18 @@ var jsonObj = JSON.parse(`
"description": "Jakarta previously hosted Regexp, a 100% Pure Java Regular 
Expression package."
 },
 {
+   "name":"Jakarta Slide",
+   "website": "http://jakarta.apache.org/slide;,
+   "retired": "11/2007",
+   "source code": "http://svn.apache.org/repos/asf/jakarta/slide;,
+   "issues":  
"https://bz.apache.org/bugzilla/describecomponents.cgi?product=Slide;,
+   "wiki":"https://wiki.apache.org/jakarta-slide;,
+   "maillists":   {"dev": 
"http://mail-archives.apache.org/mod_mbox/jakarta-slide-dev;,
+   "user":
"http://mail-archives.apache.org/mod_mbox/jakarta-slide-user;
+  },
+   "description": "Jakarta previously hosted Slide, a content repository which 
could serve as a basis for a content management system as well as other 
purposes. Among its features was full WebDAV support."
+},
+{
"name":"Jakarta Taglibs",
"website": "",
"retired": "06/2008",
@@ -352,7 +364,7 @@ var jsonObj = JSON.parse(`
"description": "Apache MRUnit was a Java library that helped developers 
unit test Apache Hadoop map reduce jobs."
 },
 {
-   "name":"OJB",
+   "name":"ObJectRelationalBridge (OJB)",
"website": "http://db.apache.org/ojb;,
"retired": "01/2011",
"source code": "http://svn.apache.org/repos/asf/db/ojb;,
@@ -444,19 +456,7 @@ var jsonObj = JSON.parse(`
"description": "Apache Shindig was an OpenSocial container to help you to 
start hosting OpenSocial apps quickly."
 },
 {
-   "name":"Slide",
-   "website": "http://jakarta.apache.org/slide;,
-   "retired": "11/2007",
-   "source code": "http://svn.apache.org/repos/asf/jakarta/slide;,
-   "issues":  
"https://bz.apache.org/bugzilla/describecomponents.cgi?product=Slide;,
-   "wiki":"https://wiki.apache.org/jakarta-slide;,
-   "maillists":   {"dev": 
"http://mail-archives.apache.org/mod_mbox/jakarta-slide-dev;,
-   "user":
"http://mail-archives.apache.org/mod_mbox/jakarta-slide-user;
-  },
-   "description": "Jakarta previously hosted Slide, a content repository which 
could serve as a basis for a content management system as well as other 
purposes. Among its features was full WebDAV support."
-},
-{
-   "name":"STDCXX",
+   "name":"Standard C++ Library (STDCXX)",
"website": "http://stdcxx.apache.org;,
"retired": "07/2013",
"source code": "http://svn.apache.org/repos/asf/stdcxx;,

Re: svn commit: r1829770 - in /attic/site-json: build.props build.sh build.xml docs/projects/ lib/ xdocs/

[Jan Iversen]

> On 22 Apr 2018, at 12:41, s...@apache.org wrote:
> 
> Author: sebb
> Date: Sun Apr 22 10:41:16 2018
> New Revision: 1829770
> 
> URL: http://svn.apache.org/viewvc?rev=1829770=rev
> Log:
> Reduce to proposed source files
> 
> Removed:
>attic/site-json/build.props
>attic/site-json/build.sh
>attic/site-json/build.xml
>attic/site-json/docs/projects/
I think this is wrong ? The idea was to have projects/.htaccess with the 
rewrite to attic.js

>attic/site-json/lib/
>attic/site-json/xdocs/
> 


Rgds
Jan I

svn commit: r1829770 - in /attic/site-json: build.props build.sh build.xml docs/projects/ lib/ xdocs/

[sebb]

Author: sebb
Date: Sun Apr 22 10:41:16 2018
New Revision: 1829770

URL: http://svn.apache.org/viewvc?rev=1829770=rev
Log:
Reduce to proposed source files

Removed:
attic/site-json/build.props
attic/site-json/build.sh
attic/site-json/build.xml
attic/site-json/docs/projects/
attic/site-json/lib/
attic/site-json/xdocs/

svn commit: r1829768 - in /attic/site-json/docs: index.html test.html

[sebb]

Author: sebb
Date: Sun Apr 22 10:31:28 2018
New Revision: 1829768

URL: http://svn.apache.org/viewvc?rev=1829768=rev
Log:
Replace HOME page

Added:
attic/site-json/docs/index.html
  - copied unchanged from r1829767, attic/site-json/docs/test.html
Removed:
attic/site-json/docs/test.html

svn commit: r1829767 - /attic/site-json/

[sebb]

Author: sebb
Date: Sun Apr 22 10:28:47 2018
New Revision: 1829767

URL: http://svn.apache.org/viewvc?rev=1829767=rev
Log:
Initial checkin for JSON proposal

Added:
attic/site-json/
  - copied from r1829765, attic/site/

Re: Discussion on proposed solutions for simplified maintenance.

[sebb]

On 22 April 2018 at 11:12, Henk P. Penning  wrote:
> On Sun, 22 Apr 2018, Jan Iversen wrote:
>
>> Date: Sun, 22 Apr 2018 11:57:33 +0200
>> From: Jan Iversen 
>> To: general@attic.apache.org
>> Subject: Re: Discussion on proposed solutions for simplified maintenance.
>
>
>>> On 22 Apr 2018, at 11:33, sebb  wrote:
>
>
>>> For proper comparison I think we need to see the whole solution.
>>> This will obviously have to be done so that it does not impact the live
>>> site.
>>
>> I believe the sample I have made with test.html and generation of all
>> project files are sufficient. No need to waste more time on that. Time
>> saving is important to me, and it does not make sense to waste
>> resources on making two complete solutions just to scrap one of them.
>
>
>   Right ; I think Jan's stuff is ok ; basicly it doesn't have
>   to be more complicated than that. It is a good starting
>   point for further development.

It does not (yet) handle all the existing information on Attic website.
Nor does it yet keep the URLs unchanged.

I think think it would be wrong to replace the existing site until
that has been addressed.
Which is why I think there should be a PoC that can be tested.

I will create a new branch so the existing proposal can be developed further.

>   Personally I would separate the (json) data from the program,
>   but that is a minor detail.

Agreed; if JSON is to be used it should be in a separate file.

>   Regards,
>
>   Henk Penning
>
>    _
> Henk P. Penning, ICT-beta R Uithof MG-403_/ \_
> Faculty of Science, Utrecht UniversityT +31 30 253 4106 / \_/ \
> Leuvenlaan 4, 3584CE Utrecht, NL  F +31 30 253 4553 \_/ \_/
> http://www.staff.science.uu.nl/~penni101/ M penn...@uu.nl \_/

Re: Discussion on proposed solutions for simplified maintenance.

[Henk P. Penning]

On Sun, 22 Apr 2018, Jan Iversen wrote:


Date: Sun, 22 Apr 2018 11:57:33 +0200
From: Jan Iversen 
To: general@attic.apache.org
Subject: Re: Discussion on proposed solutions for simplified maintenance.



On 22 Apr 2018, at 11:33, sebb  wrote:



For proper comparison I think we need to see the whole solution.
This will obviously have to be done so that it does not impact the live site.

I believe the sample I have made with test.html and generation of all
project files are sufficient. No need to waste more time on that. Time
saving is important to me, and it does not make sense to waste
resources on making two complete solutions just to scrap one of them.


  Right ; I think Jan's stuff is ok ; basicly it doesn't have
  to be more complicated than that. It is a good starting
  point for further development.

  Personally I would separate the (json) data from the program,
  but that is a minor detail.

  Regards,

  Henk Penning

   _
Henk P. Penning, ICT-beta R Uithof MG-403_/ \_
Faculty of Science, Utrecht UniversityT +31 30 253 4106 / \_/ \
Leuvenlaan 4, 3584CE Utrecht, NL  F +31 30 253 4553 \_/ \_/
http://www.staff.science.uu.nl/~penni101/ M penn...@uu.nl \_/

Re: Discussion on proposed solutions for simplified maintenance.

[Jan Iversen]

> On 22 Apr 2018, at 11:33, sebb  wrote:
> 
> On 22 April 2018 at 09:54, Jan Iversen  > wrote:
>> 
>> 
>>> On 22 Apr 2018, at 10:17, sebb  wrote:
>>> 
>>> On 21 April 2018 at 12:57,   wrote:
 Hi.
 
 After having studied the solution proposed by Sebb, I have decided to add 
 my proposal again.
 
 My proposal has one outstanding TODO:
 - add a .htaccess to projects that catches * and redirect to 
 attic.js?
>>> 
>>> That needs testing to ensure it works properly.
>> Just as with your solution, testing is always needed. That is the reason I 
>> did not touch any production files, but added test.html
> 
> For proper comparison I think we need to see the whole solution.
> This will obviously have to be done so that it does not impact the live site.
I believe the sample I have made with test.html and generation of all project 
files are sufficient. No need to waste more time on that. Time saving is 
important to me, and it does not make sense to waste resources on making two 
complete solutions just to scrap one of them.

The real key here which person will do the maintenance in the future. As the 
person who have done the maintenance in the past and if nothing changes will 
continue to do so, I believe it is fair to make a system that makes my life 
easier. If of course needs to be a system, that can be easy handled in case I 
need a substitute. In the case I am not supposed to do the maintenance in the 
future my opinions carry a lot less weight.

> 
> Which is why I created the branch; this contains everything needed to
> set up the website.
> I have been able to test it locally.
Well you can also test it live, as I do www.attic.org/test.html 


> 
>>> 
 - change attic.js to use project name instead of a number
 Apart from that my solution is working, and seen from the outside the 
 Attic site is identical, responding to the same url as before.
>>> 
>>> Apart from:
>>> The non-project HTML file resolution.html does not use the new list of 
>>> projects
>> It will, look in test.html then you can see how that will be done in the 
>> production files that non-project.
>> 
>>> The project/* files don't allow for additional info such as is present
>>> in some of the existing XML files
>> It actually does, just add that information to the description field.
> 
> OK, so try that with Taglibs.
Quite hard to do, as we do not have Taglibs as a retired project.

> 
>> 
>>> The site does not work if a client does not support Javascript
>> Correct, but nowadays that is hardly a problem.
> 
> We still need to support such clients.
I beg to differ. We also do not support all old browser applications (like the 
ones who only support HTML 1), somewhere you have to set a limit.

rgds
Jan I.

> 
>>> 
 The proposal from Sebb, involves new technology (Jekyll, YAML, bot) as 
 well as a markdown file pr project and are also working.
 
 Can we please have an open discussion to choose between these 2 variants 
 and if needed (which I hope we can avoid) a vote.
 
 —
 My pow:
 
 JS is not the best solution I preferred PHP, but needed in order to have a 
 static server side. The JSON embedded in attic.js is valid json, and easy 
 to extract with a simple sed, should anybody need it.
 
 The solution from Sebb introduces a number of new technologies, and adds a 
 bot that runs and eat resources.
 
 As the one who have done the maintenance the last year, I look for a 
 solution where we update a single file, and avoid complications (like 
 looking after a build job).
 
 —
 
 Please add your comments and let aim at making a decision this month.
 
 Have a nice weekend
 rgds
 Jan I.

Re: Discussion on proposed solutions for simplified maintenance.

[sebb]

On 22 April 2018 at 09:54, Jan Iversen  wrote:
>
>
>> On 22 Apr 2018, at 10:17, sebb  wrote:
>>
>> On 21 April 2018 at 12:57,   wrote:
>>> Hi.
>>>
>>> After having studied the solution proposed by Sebb, I have decided to add 
>>> my proposal again.
>>>
>>> My proposal has one outstanding TODO:
>>> - add a .htaccess to projects that catches * and redirect to 
>>> attic.js?
>>
>> That needs testing to ensure it works properly.
> Just as with your solution, testing is always needed. That is the reason I 
> did not touch any production files, but added test.html

For proper comparison I think we need to see the whole solution.
This will obviously have to be done so that it does not impact the live site.

Which is why I created the branch; this contains everything needed to
set up the website.
I have been able to test it locally.

>>
>>> - change attic.js to use project name instead of a number
>>> Apart from that my solution is working, and seen from the outside the Attic 
>>> site is identical, responding to the same url as before.
>>
>> Apart from:
>> The non-project HTML file resolution.html does not use the new list of 
>> projects
> It will, look in test.html then you can see how that will be done in the 
> production files that non-project.
>
>> The project/* files don't allow for additional info such as is present
>> in some of the existing XML files
> It actually does, just add that information to the description field.

OK, so try that with Taglibs.

>
>> The site does not work if a client does not support Javascript
> Correct, but nowadays that is hardly a problem.

We still need to support such clients.

>>
>>> The proposal from Sebb, involves new technology (Jekyll, YAML, bot) as well 
>>> as a markdown file pr project and are also working.
>>>
>>> Can we please have an open discussion to choose between these 2 variants 
>>> and if needed (which I hope we can avoid) a vote.
>>>
>>> —
>>> My pow:
>>>
>>> JS is not the best solution I preferred PHP, but needed in order to have a 
>>> static server side. The JSON embedded in attic.js is valid json, and easy 
>>> to extract with a simple sed, should anybody need it.
>>>
>>> The solution from Sebb introduces a number of new technologies, and adds a 
>>> bot that runs and eat resources.
>>>
>>> As the one who have done the maintenance the last year, I look for a 
>>> solution where we update a single file, and avoid complications (like 
>>> looking after a build job).
>>>
>>> —
>>>
>>> Please add your comments and let aim at making a decision this month.
>>>
>>> Have a nice weekend
>>> rgds
>>> Jan I.
>

Re: Second proposal for new site maintenance.

[Jan Iversen]

> On 22 Apr 2018, at 11:27, sebb  wrote:
> 
> On 22 April 2018 at 09:51, Jan Iversen  > wrote:
>> 
>> 
>>> On 22 Apr 2018, at 09:43, sebb  wrote:
>>> 
>>> On 20 April 2018 at 12:11,   wrote:
 Hi
 
 I have given some thought to the proposal by Sebb that replaces my 
 proposal.
 
 There have been on/off talks over a long time about simplifying the 
 maintenance, common for the talks are the wish to only maintain a single 
 file, preferable json format.
>>> 
>>> Why is a single file necessary?
>>> 
 The proposal from Sebb have a lot of good qualities, but the latest 
 suggestion is a file pr project combined with yaml files, this is far from 
 the original wish and something I cannot support.
>>> 
>>> Why not?
>> Because it is multiple files instead of 1 file.
> 
> Huh?
> Unless you are updating multiple projects, it is only one file.
Correct, but it is a new file every time, and not the same file.

> 
>> You need to edit the .md, which eventually will lead to different 
>> content/look project files (with content I mean different classes of 
>> content, like some will have related projects others will not even have the 
>> field…also with .md it is possible to reorder the information).
> 
> How is that different from JSON data?
Because with JSON data, each project file is generated, and thus guaranteed to 
have the same layout.

> JSON does not have mandatory attributes, nor does it insist on a
> particular order.
> And what does the order matter?
The order in the JSON file does not matter, but the layout of the project file 
matters, they should all be identical
> 
>>> 
 I am also a bit concerned about having a bot running for something that 
 changes 3-4 times pr year, it seem like a waste of Infra resources.
>>> 
>>> This same bot is used for lots of sites.
>>> 
 It is important that the maintenance can be carried out easily and it is 
 important that the look/feel of the site stays identical e.g. old urls 
 must remain available.
>>> 
>>> Agreed.
>>> 
 Adding a struct in a json file secures easy maintenance, as in the 
 original proposal.
>>> 
>>> I disagree that JSON is the way to go.
>>> 
 Please let us not complicate things.
>>> 
>>> JSON is complicated to use with anything other than small amounts of
>>> textual data.
>> Not really, at least not from my pow, and after all I just converted all 
>> projects to json, that should count for some experience.
> 
> As I wrote elsewhere, not all the information in the existing XML
> files has been transferred.
Well, then you do not talk about a missing feature, but an error in the update 
(which I already have mentioned earlier).

> 
> It was when I started looking at how to do that with JSON that I
> started to think that JSON is not the right format.
> 
> Have a look at how to transfer the additional information from some of
> the following:
> 
> Abdera
> AxKit
> Beehive
> Crimson
> DeviceMap
> Excalibur
> HiveMind
> iBatis
> ECS
> ORO
> Regexp
> Slide
> Taglibs (this has a lot of info)
> Muse
> OJB
> Shale
> Whirr
> Xang
> XML
> XMLBeans
> 
> Some of that info could perhaps be added to the description field.
> But I don't think it's practical for everything.
I politely have a different opinion
> 
> And I don't think it's right to drop the information.
We can agree on that, and that is solvable in both solutions.

rgds
Jan I.
> 
>>> 
 This started because I wanted to simplify my life and have grown into 
 something bigger.
>>> 
 Bigger might be better, but is it really needed, and are there somebody 
 willing to do our job (move retired project to the Attic) ?
>>> 
>>> Personally, I would much rather create/edit a single YAML file per
>>> project than a large slab of JSON.
>> YAML would solve the problem of a single file, but for that you need to 
>> think about how to online validate the file, before committing. As a 
>> personal opinion I find YAML with its less restrictive format a lot more 
>> error prone.
>> 
>> 
>> rgds
>> Jan I.
>>> 
 rgds
 Jan I.

Re: Second proposal for new site maintenance.

[sebb]

On 22 April 2018 at 09:51, Jan Iversen  wrote:
>
>
>> On 22 Apr 2018, at 09:43, sebb  wrote:
>>
>> On 20 April 2018 at 12:11,   wrote:
>>> Hi
>>>
>>> I have given some thought to the proposal by Sebb that replaces my proposal.
>>>
>>> There have been on/off talks over a long time about simplifying the 
>>> maintenance, common for the talks are the wish to only maintain a single 
>>> file, preferable json format.
>>
>> Why is a single file necessary?
>>
>>> The proposal from Sebb have a lot of good qualities, but the latest 
>>> suggestion is a file pr project combined with yaml files, this is far from 
>>> the original wish and something I cannot support.
>>
>> Why not?
> Because it is multiple files instead of 1 file.

Huh?
Unless you are updating multiple projects, it is only one file.

> You need to edit the .md, which eventually will lead to different 
> content/look project files (with content I mean different classes of 
> content, like some will have related projects others will not even have the 
> field…also with .md it is possible to reorder the information).

How is that different from JSON data?
JSON does not have mandatory attributes, nor does it insist on a
particular order.
And what does the order matter?

>>
>>> I am also a bit concerned about having a bot running for something that 
>>> changes 3-4 times pr year, it seem like a waste of Infra resources.
>>
>> This same bot is used for lots of sites.
>>
>>> It is important that the maintenance can be carried out easily and it is 
>>> important that the look/feel of the site stays identical e.g. old urls must 
>>> remain available.
>>
>> Agreed.
>>
>>> Adding a struct in a json file secures easy maintenance, as in the original 
>>> proposal.
>>
>> I disagree that JSON is the way to go.
>>
>>> Please let us not complicate things.
>>
>> JSON is complicated to use with anything other than small amounts of
>> textual data.
> Not really, at least not from my pow, and after all I just converted all 
> projects to json, that should count for some experience.

As I wrote elsewhere, not all the information in the existing XML
files has been transferred.

It was when I started looking at how to do that with JSON that I
started to think that JSON is not the right format.

Have a look at how to transfer the additional information from some of
the following:

Abdera
AxKit
Beehive
Crimson
DeviceMap
Excalibur
HiveMind
iBatis
ECS
ORO
Regexp
Slide
Taglibs (this has a lot of info)
Muse
OJB
Shale
Whirr
Xang
XML
XMLBeans

Some of that info could perhaps be added to the description field.
But I don't think it's practical for everything.

And I don't think it's right to drop the information.

>>
>>> This started because I wanted to simplify my life and have grown into 
>>> something bigger.
>>
>>> Bigger might be better, but is it really needed, and are there somebody 
>>> willing to do our job (move retired project to the Attic) ?
>>
>> Personally, I would much rather create/edit a single YAML file per
>> project than a large slab of JSON.
> YAML would solve the problem of a single file, but for that you need to think 
> about how to online validate the file, before committing. As a personal 
> opinion I find YAML with its less restrictive format a lot more error prone.
>
>
> rgds
> Jan I.
>>
>>> rgds
>>> Jan I.
>

Re: Discussion on proposed solutions for simplified maintenance.

[Jan Iversen]

> On 22 Apr 2018, at 10:17, sebb  wrote:
> 
> On 21 April 2018 at 12:57,   wrote:
>> Hi.
>> 
>> After having studied the solution proposed by Sebb, I have decided to add my 
>> proposal again.
>> 
>> My proposal has one outstanding TODO:
>> - add a .htaccess to projects that catches * and redirect to 
>> attic.js?
> 
> That needs testing to ensure it works properly.
Just as with your solution, testing is always needed. That is the reason I did 
not touch any production files, but added test.html

> 
>> - change attic.js to use project name instead of a number
>> Apart from that my solution is working, and seen from the outside the Attic 
>> site is identical, responding to the same url as before.
> 
> Apart from:
> The non-project HTML file resolution.html does not use the new list of 
> projects
It will, look in test.html then you can see how that will be done in the 
production files that non-project.

> The project/* files don't allow for additional info such as is present
> in some of the existing XML files
It actually does, just add that information to the description field.

> The site does not work if a client does not support Javascript
Correct, but nowadays that is hardly a problem.

> 
>> The proposal from Sebb, involves new technology (Jekyll, YAML, bot) as well 
>> as a markdown file pr project and are also working.
>> 
>> Can we please have an open discussion to choose between these 2 variants and 
>> if needed (which I hope we can avoid) a vote.
>> 
>> —
>> My pow:
>> 
>> JS is not the best solution I preferred PHP, but needed in order to have a 
>> static server side. The JSON embedded in attic.js is valid json, and easy to 
>> extract with a simple sed, should anybody need it.
>> 
>> The solution from Sebb introduces a number of new technologies, and adds a 
>> bot that runs and eat resources.
>> 
>> As the one who have done the maintenance the last year, I look for a 
>> solution where we update a single file, and avoid complications (like 
>> looking after a build job).
>> 
>> —
>> 
>> Please add your comments and let aim at making a decision this month.
>> 
>> Have a nice weekend
>> rgds
>> Jan I.

Re: Second proposal for new site maintenance.

[sebb]

On 20 April 2018 at 12:11,   wrote:
> Hi
>
> I have given some thought to the proposal by Sebb that replaces my proposal.
>
> There have been on/off talks over a long time about simplifying the 
> maintenance, common for the talks are the wish to only maintain a single 
> file, preferable json format.

Why is a single file necessary?

> The proposal from Sebb have a lot of good qualities, but the latest 
> suggestion is a file pr project combined with yaml files, this is far from 
> the original wish and something I cannot support.

Why not?

> I am also a bit concerned about having a bot running for something that 
> changes 3-4 times pr year, it seem like a waste of Infra resources.

This same bot is used for lots of sites.

> It is important that the maintenance can be carried out easily and it is 
> important that the look/feel of the site stays identical e.g. old urls must 
> remain available.

Agreed.

> Adding a struct in a json file secures easy maintenance, as in the original 
> proposal.

I disagree that JSON is the way to go.

> Please let us not complicate things.

JSON is complicated to use with anything other than small amounts of
textual data.

> This started because I wanted to simplify my life and have grown into 
> something bigger.

> Bigger might be better, but is it really needed, and are there somebody 
> willing to do our job (move retired project to the Attic) ?

Personally, I would much rather create/edit a single YAML file per
project than a large slab of JSON.

> rgds
> Jan I.