[kontact] [Bug 471414] Application: Kontact (kontact), signal: Segmentation fault

[Jan Iversen]

https://bugs.kde.org/show_bug.cgi?id=471414

Jan Iversen  changed:

   What|Removed |Added

 CC||jan.iver...@mailbox.org

-- 
You are receiving this mail because:
You are watching all bug changes.

[kontact] [Bug 471414] Application: Kontact (kontact), signal: Segmentation fault

[Jan Iversen]

https://bugs.kde.org/show_bug.cgi?id=471414

Jan Iversen  changed:

   What|Removed |Added

 CC||jan.iver...@mailbox.org

-- 
You are receiving this mail because:
You are the assignee for the bug.

Unsubscribe from TestFlight

[jan iversen via subsurface]

j...@casacondor.com wants to stop receiving TestFlight emails about 
Subsurface-mobile


Enviado desde mi iPad
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: Gone for a week

[Jan Iversen]

Happy vacation time !!

Hope you manage better than me, to stay offline :-)

rgds
jan i

ps. apart from the bug solve PR you already commented in, I will wait with new 
PR´s.

Enviado desde mi iPad

> El 16 ago 2018, a las 16:26, Dirk Hohndel  escribió:
> 
> 
> Hi there,
> 
> I'm heading on family vacation for a week. There will be a couple of days of 
> data acquisition, but since I'm the only one in the family who dives, the 
> rest of the trip I'll spend with them...
> 
> Why am I telling you? Because I'm going to try to not be at my computer all 
> that much. Which means it would be nice if some of you could respond to the 
> support email here and especially in the user forum / Google group. And maybe 
> some of the other maintainers could help out with PR reviews and issues on 
> GitHub, etc.
> 
> I won't be offline, but I'm hoping to be less online :-)
> 
> /D
> ___
> subsurface mailing list
> subsurface@subsurface-divelog.org
> http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: OT: Subsurface IRC-channel swamped by ads

[Jan Iversen]

Enviado desde mi iPad

> El 2 ago 2018, a las 17:16, Dirk Hohndel  escribió:
> 
> There is nothing in this world that spammers aren't happy to destroy.
> 
> But admittedly, I haven't spent time on IRC in ages. It just doesn't fit my 
> normal workflow. And if I scroll back through the history, it's been a long 
> time that there was any meaningful discussion there.
> 
> So I don't know what's the right thing to do.
I posted questions long time ago, and never got a response, which frustrated 
me. I actually only had 2 times where there were response (both sessions 
initiated by you)

Not having an IRC might be seen as bad, but having one that is non-responsive 
is a lot worse, so closing it would
1) not harm anybody (since it is unused)
2) stop frustrating people who post a question
3) be the truth, since it isnt a way to communicate with the project.

rgds
jan i
> 
> /D
> 
>> On Aug 1, 2018, at 11:05 PM, Paul-Erik Törrönen  wrote:
>> 
>> There's not much activity on the IRC channel but would it be possible to 
>> reconsider the policy of joining.
>> 
>> The issue is that for the last couple of days the channel has been hosed 
>> with 'IRC ad service' spam. This means that I get a false notification of 
>> activity, and, because of the volume of spam, it is quite hard to find 
>> whether anything about Subsurface has actually been discussed.
>> 
>> One way to combat this is to use registration (+r mode). Another one could 
>> be to drop the channel altogether.
>> 
>> Poltsi
>> ___
>> subsurface mailing list
>> subsurface@subsurface-divelog.org
>> http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
> 
> ___
> subsurface mailing list
> subsurface@subsurface-divelog.org
> http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: how to translate a static array?

[Jan Iversen]

Thanks, that is easy, I was afraid the translation required a function call.

rgds
jan I

Enviado desde mi iPad

> El 1 ago 2018, a las 20:49, Dirk Hohndel  escribió:
> 
> 
>> On Aug 1, 2018, at 9:54 AM, Jan Iversen  wrote:
>> 
>> Hi
>> 
>> If I have something like
>> 
>> struct 
>> {
>>  enum {METERS, FEET} length;
>>  char *strings[] = {“meter”, “feet”};
>> }
>> 
>> How do I mark these strings as to be translated?
> 
> You mark them with QT_TRANSLATE_NOOP, see for example this beauty in 
> libdivecomputer.c:
> 
> static const char *events[] = {
> QT_TRANSLATE_NOOP("gettextFromC", "none"), 
> QT_TRANSLATE_NOOP("gettextFromC", "deco stop"), 
> QT_TRANSLATE_NOOP("gettextFromC", "rbt"), QT_TRANSLATE_NOOP("gettextFromC", 
> "ascent"), QT_TRANSLATE_NOOP("gettextFromC", "ceiling"), 
> QT_TRANSLATE_NOOP("gettextFromC", "workload"),
> QT_TRANSLATE_NOOP("gettextFromC", "transmitter"), 
> QT_TRANSLATE_NOOP("gettextFromC", "violation"), 
> QT_TRANSLATE_NOOP("gettextFromC", "bookmark"), 
> QT_TRANSLATE_NOOP("gettextFromC", "surface"), 
> QT_TRANSLATE_NOOP("gettextFromC", "safety stop"),
> QT_TRANSLATE_NOOP("gettextFromC", "gaschange"), 
> QT_TRANSLATE_NOOP("gettextFromC", "safety stop (voluntary)"), 
> QT_TRANSLATE_NOOP("gettextFromC", "safety stop (mandatory)"),
> QT_TRANSLATE_NOOP("gettextFromC", "deepstop"), 
> QT_TRANSLATE_NOOP("gettextFromC", "ceiling (safety stop)"), 
> QT_TRANSLATE_NOOP3("gettextFromC", "below floor", "event showing dive is 
> below deco floor and adding deco time"), QT_TRANSLATE_NOOP("gettextFromC", 
> "divetime"),
> QT_TRANSLATE_NOOP("gettextFromC", "maxdepth"), 
> QT_TRANSLATE_NOOP("gettextFromC", "OLF"), QT_TRANSLATE_NOOP("gettextFromC", 
> "PO2"), QT_TRANSLATE_NOOP("gettextFromC", "airtime"), 
> QT_TRANSLATE_NOOP("gettextFromC", "rgbm"), QT_TRANSLATE_NOOP("gettextFromC", 
> "heading"),
> QT_TRANSLATE_NOOP("gettextFromC", "tissue level warning"), 
> QT_TRANSLATE_NOOP("gettextFromC", "gaschange"), 
> QT_TRANSLATE_NOOP("gettextFromC", "non stop time")
> };
> 
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

how to translate a static array?

[Jan Iversen]

Hi

If I have something like

struct 
{
enum {METERS, FEET} length;
char *strings[] = {“meter”, “feet”};
}

How do I mark these strings as to be translated?

thanks in advance for a answer.
rgds
jan I

Enviado desde mi iPad
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: Cloud storage does not load at startup since b9b1f03

[Jan Iversen]

Hi

Master was just updated with my fix, I hope that solves your problem.

rgds
jan i

Enviado desde mi iPad

> El 26 jul 2018, a las 8:06, Jan Iversen  escribió:
> 
> Thanks you sent me exactly what I was looking, sorry for not being precise (I 
> write in between changing bottles at the compressor).
> 
> rgds
> jan i
> 
> Enviado desde mi iPad
> 
>> El 26 jul 2018, a las 7:58, Gaetan Bisson  escribió:
>> 
>> [2018-07-26 07:34:56 +0200] Jan Iversen:
>>> Now this is strange, that works here. I use “cloud xml file”, and when I 
>>> click “File -> Open Cloud storage” I get all my dives (except that 
>>> sometimes the cloud connection runs into a timeout).
>> 
>> I'm using "Cloud storage default file" under "Preferences -> General ->
>> Dives" if that's what you mean. I'm attaching my Subsurface.conf
>> redacted only for the password under the CloudStorage section, as well
>> as screenshots of the relevant configuration panels.
>> 
>>> Could you please mail me your log file (from a simple startup, and click on 
>>> “open cloud storage”) so I can compare. Thanks in advance.
>> 
>> Do you mean what `subsurface -v` sends out to standard output/error? See
>> the file attached. I can also send you my cloud storage logbook exported
>> as XML file if that's what you meant but I doubt it'll be as useful.
>> 
>> Cheers.
>> 
>> -- 
>> Gaetan
>> 
>> 
>> 
>> 
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: Cloud storage does not load at startup since b9b1f03

[Jan Iversen]

Thanks you sent me exactly what I was looking, sorry for not being precise (I 
write in between changing bottles at the compressor).

rgds
jan i

Enviado desde mi iPad

> El 26 jul 2018, a las 7:58, Gaetan Bisson  escribió:
> 
> [2018-07-26 07:34:56 +0200] Jan Iversen:
>> Now this is strange, that works here. I use “cloud xml file”, and when I 
>> click “File -> Open Cloud storage” I get all my dives (except that sometimes 
>> the cloud connection runs into a timeout).
> 
> I'm using "Cloud storage default file" under "Preferences -> General ->
> Dives" if that's what you mean. I'm attaching my Subsurface.conf
> redacted only for the password under the CloudStorage section, as well
> as screenshots of the relevant configuration panels.
> 
>> Could you please mail me your log file (from a simple startup, and click on 
>> “open cloud storage”) so I can compare. Thanks in advance.
> 
> Do you mean what `subsurface -v` sends out to standard output/error? See
> the file attached. I can also send you my cloud storage logbook exported
> as XML file if that's what you meant but I doubt it'll be as useful.
> 
> Cheers.
> 
> -- 
> Gaetan
> 
> 
> 
> 
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: Cloud storage does not load at startup since b9b1f03

[Jan Iversen]

Thanks to everybody for reporting issues, it is my top priority to solve these 
issues.

Stefan: can you please confirm that your problems is when using the desktop ? 
and before qCloudStorage it would load your local cache?

I just had a look at my jani.xml it has a lot of empty settings, can someone 
(stefan?) please send me  in private a filled xml working file, so I can adapt 
it to my xml file. THANKS IN ADVANCE.

It´s late here, but I will continue working tomorrow (after my training 
lessons).

Dirk: you write “a couple of scenarios” if that is more than the 2 I pursue now 
(cloud not loading automatically with cloud profile, and local profile tries to 
load from cloud) please be so kind and detail them so I can reproduce them.

Thanks to all for showing patience while I solve the problem I introduced.

rgds
jan I.



Enviado desde mi iPad

> El 25 jul 2018, a las 21:42, Dirk Hohndel  escribió:
> 
> 
>> On Jul 25, 2018, at 12:12 PM, Stefan Fuchs  wrote:
>> I also have to report some unintended behavior coming from the 
>> "qPrefCloudStorage" change.
>> My setup is the following:
>> I by default start Subsurface with a local .xml file ("Stefan.xml") and 
>> rather seldom use the cloud storage.
>> 
>> After the change Subsurface starts with a title bar showing "[Cloud storage 
>> for] Stefan.xml" which is obviously not correct because I want to have the 
>> local file. Also the menu entry "File->Cloud storage online" is active which 
>> is also incorrect. I have the feeling that also the overall behavior 
>> regarding which data is used is rather strange but that's just a guess.
> 
> 
> My quick test here with a couple of scenarios seems to indicate that we 
> misinterpret the setting for what to do at startup. Haven't had spent enough 
> time staring at the code to understand why.
> 
> This is always the risk with rewrites like this (and why Tomaz was not 
> excited to see another rewrite of the preferences subsystem, given that he 
> had done this before and felt the existing system was good enough...) but now 
> that we started, we should track down the little bugs but otherwise finish 
> things.
> 
> /D
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: Cloud storage does not load at startup since b9b1f03

[Jan Iversen]

I was finally able to confirm the problem.

I used a local xml profile and that prohibits cloud automatic loading, with a 
cloud based default xml, I can reproduce the problem, which is somewhere in 
qPrefCloudStorage.

Sorry for the multiple mails, but this one was not intuitive to confirm. I 
still have to understand why using a local profile stops automatic loading.

I am on debugging and hope to have a PR ready very soon.

Thanks for making me aware of the problem.
rgds
jan I

Enviado desde mi iPad

> El 24 jul 2018, a las 9:09, Gaetan Bisson  escribió:
> 
> Hi Jan,
> 
> I run a build of Subsurface's latest git master but since b9b1f03 I find
> that cloud storage does not load upon startup as it used to.
> 
> Is there any settings or such things I need to migrate to conform with
> the new qPrefCloudStorage?
> 
> Cheers.
> 
> -- 
> Gaetan
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: Cloud storage does not load at startup since b9b1f03

[Jan Iversen]

Hi Gaetan

I am confused, I have now compiled a number of commits before the 
qPrefCloudStorage commit, and finally I compiled b2422f885 (tagged v4.8.1) and 
none of them opens the cloudstorage automatically. 

I am on a virtual mac, high sierra 10.13, and I cannot rule out that e.g. 
qPrefCloudStorage ruined some settings, but it does seem odd, so maybe somebody 
else can confirm the problem.

I will see if I can make a fresh install, to secure against corrupted settings.

rgds
jan i

Enviado desde mi iPad

> El 24 jul 2018, a las 9:09, Gaetan Bisson  escribió:
> 
> Hi Jan,
> 
> I run a build of Subsurface's latest git master but since b9b1f03 I find
> that cloud storage does not load upon startup as it used to.
> 
> Is there any settings or such things I need to migrate to conform with
> the new qPrefCloudStorage?
> 
> Cheers.
> 
> -- 
> Gaetan
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: Cloud storage does not load at startup since b9b1f03

[Jan Iversen]

Hi

I do not know of any specific variables (except in mobile, you need to say you 
want to sync automatically). qPrefCloudStorage should not change that behavior, 
however I will try and debug around that. 

I assume you talk about the desktop version ?

rgds
jan i

Enviado desde mi iPad

> El 24 jul 2018, a las 9:09, Gaetan Bisson  escribió:
> 
> Hi Jan,
> 
> I run a build of Subsurface's latest git master but since b9b1f03 I find
> that cloud storage does not load upon startup as it used to.
> 
> Is there any settings or such things I need to migrate to conform with
> the new qPrefCloudStorage?
> 
> Cheers.
> 
> -- 
> Gaetan
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: Danish translation.

[Jan Iversen]

I just found out we do not use reviewers, I am used to that a string does not 
go into production before it have been accepted by a reviewer hence my concern.

I saw danish have 1001 strings waiting for review, and as pr above, that made 
me wonder when review happens.

I will simply bulk accept the translations not to have others ask the same 
question.

rgds
jan i

Enviado desde mi iPad

> El 15 jul 2018, a las 18:33, Dirk Hohndel  escribió:
> 
> 
>> On Jul 15, 2018, at 6:54 AM, Jan Iversen  wrote:
>> 
>> I opened transifix between dives today, and translated a number of strings, 
>> but it looks like wasted effort because there are 1001 strings missing 
>> control (revised). Can a reviewer please control and accept/eject the 
>> strings before I use more time.
> 
> I am not sure what these words mean, to be honest.
> 
> So you wasted effort by translating strings? Why?
> What does "there are 1001 strings missing control (revised)" mean? Are you 
> talking about "reviewed"?
> 
> We cannot turn off the "review" feature because we are on a free plan with 
> Transifex - but we don't use it at all.
> I am happy to make you a reviewer if that solves your concern.
> 
> If I misunderstand your concerns let me know and I'll figure out what to do 
> to address them.
> 
> /D
> 
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: transifix and acknowledgement

[Jan Iversen]

yeah .ts does not have the extra information. Remember in .po the last 
translator is pr translation unit and not pr file or pr language and thus 
significant.

I do not need or care about that kind of credit, but you publish a list of 
active developers and I think doing something similar for translators is a 
motivation factor. However if it cannot be done easily and automatically it is 
not worth the pain.

rgds
jan I

Ps. I personally do not like lists that single out who did how much for a 
release, because they often show a distorted picture (see my participation in 
4.8.1, which you correctly relativated), but I know from my mentoring jobs that 
many likes it, and thus accept it :-)

Enviado desde mi iPad

> El 15 jul 2018, a las 18:26, Dirk Hohndel  escribió:
> 
> 
>> On Jul 15, 2018, at 7:00 AM, Jan Iversen  wrote:
>> 
>> Hi
>> 
>> I just wondered why we do not acknowledge the translators when merging po 
>> files into git ?
>> 
>> the po contains the last author pr entry as pr:
>> https://docs.transifex.com/formats/gettext
>> 
> 
> We don't use .po files, we use .ts files, and those don't include translator 
> information.
> Also, the way .po files include it, last time I checked (back in the 
> Subsurface 3 days when we were Gtk based) only the LAST translator was listed 
> which meant for most languages where we have more than one translator this 
> wouldn't really make any sense, either.
> 
> If you would like explicit credit for your translations I can certainly 
> provide that.
> 
> /D
> 
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

transifix and acknowledgement

[Jan Iversen]

Hi

I just wondered why we do not acknowledge the translators when merging po files 
into git ?

the po contains the last author pr entry as pr:
https://docs.transifex.com/formats/gettext

rgds
jan i

Enviado desde mi iPad___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Danish translation.

[Jan Iversen]

I opened transifix between dives today, and translated a number of strings, but 
it looks like wasted effort because there are 1001 strings missing control 
(revised). Can a reviewer please control and accept/eject the strings before I 
use more time.

thanks in advance
rgds
jan i.

Ps. I got an error message when trying, that only “reviwers” can do bulk 
updates.

Enviado desde mi iPad
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: experimenting with milestones at github

[Jan Iversen]

Normal “deadly” people cannot set milestones, I just created #1468 and wanted 
to add the 4.8 milestone.

I understand that creating new labels and milestones should be restricted, but 
is it really a good idea that only “goods” can assign them ?

I suppose from my choice of words, my opinion is clear :-)

Rgds
Jan I.

Enviado desde mi iPad

> El 6 jul 2018, a las 13:34, Lubomir I. Ivanov  escribió:
> 
>> On 6 July 2018 at 08:48, Martin Gysel  wrote:
>> Am Freitag, 6. Juli 2018, 04:21:37 CEST schrieb Dirk Hohndel:
>> 
>>> I can't see a milestone on GitHub - am I looking at this wrong?
>> 
>> 
>> 
>> https://github.com/Subsurface-divelog/subsurface/milestones
>> 
> 
> yes, also on this page (issue):
> https://github.com/Subsurface-divelog/subsurface/issues/1461
> 
> the issue has a milestone set, on the right under labels.
> 
> lubomir
> --
> ___
> subsurface mailing list
> subsurface@subsurface-divelog.org
> http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: Run test suite.

[Jan Iversen]

Enviado desde mi iPad

> El 5 jul 2018, a las 21:31, Dirk Hohndel  escribió:
> 
> 
> 
>> On Jul 5, 2018, at 11:47 AM, Jan Iversen  wrote:
>> 
>> Just controlled CMakelists.txt it sets (as you wrote) MAKE_TESTS on, but 
>> when I do
>> 
>> c:subsurface jani$ vi CMakeLists.txt
>> janMac:subsurface jani$ make check
>> make: *** No rule to make target `check'.  Stop.
> 
> You need to be in your build directory, right?
> And then it may complain about not finding libgit2.26.dylib - so you need to 
> make sure that you either fix up the binaries or have that in your library 
> search path.

No comments, now it is building :-) will look at fixing binaries or search path

Rgds
Jan I.
> 
> After that it should work.
> 
> /D
> 
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

TestFlight beta feedback for Subsurface-mobile.

[Jan Iversen]

App Information:
App Name: Subsurface-mobile
App Version: 2.1.1 (4.8.0.39)
Installed App Version: 2.1.1 (4.8.0.39)

Device Information:
Device: iPad6,7
iOS Version: 11.4
Language: es-ES (español (España))
Carrier: N/A
Timezone: CEST
Architecture: N/A
Connection Status: WiFi
Paired Apple Watch: N/A


Runs nicely with spanish text on my ipad, and switches to english when I change 
the system language.
(Remark we really should make some of this fields in settings).

Changing cloud user works.

Rgds
Jan I


Enviado desde mi iPad___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: developer video call anyone?

[Jan Iversen]

Enviado desde mi iPad

> El 5 jul 2018, a las 20:46, Lubomir I. Ivanov  escribió:
> 
>> On 5 July 2018 at 19:31, Lubomir I. Ivanov  wrote:
>> the meeting is in 30 minutes.
>> 
>> our agenda and Zoom link is in here:
>> https://docs.google.com/document/d/1v745D3TznRG7rHOKInLR-nEmCQ6wMehehlWPtV40_HY/edit#heading=h.wkz4ubcmcwg8
>> 
> 
> thank you everyone for joining,
> i think we had a productive talk on a variety of topics
> .
> 
> we can potentially do this again next month.
It was very informative for me, and I look forward to repeat.

Thanks
Jan I.
> 
> lubomir
> --
> ___
> subsurface mailing list
> subsurface@subsurface-divelog.org
> http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: Run test suite.

[Jan Iversen]

Just controlled CMakelists.txt it sets (as you wrote) MAKE_TESTS on, but when I 
do

c:subsurface jani$ vi CMakeLists.txt
janMac:subsurface jani$ make check
make: *** No rule to make target `check'.  Stop.

What am I missing ?

Rgds
Jan I.
Enviado desde mi iPad

> El 5 jul 2018, a las 18:23, Dirk Hohndel  escribió:
> 
> You sent that to an odd github address :-)
> 
>> On Jul 5, 2018, at 9:05 AM, Jan Iversen  wrote:
>> 
>> It seems Linux2 on travis runs the test suite.
> 
> Indeed
> 
>> How can I build a test executable and run it on my mac ?
>> (I am about to write a lot of test cases, and would like to test locally 
>> before pushing the PR).
> 
> Make sure that MAKE_TESTS is set  to ON (that's the default).
> Then run 
> make check
> Right now that seems broken for me out of the box because it can't find the 
> libgit2 
> shared library - but that's easy to fix.
> 
> 
> /D
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: developer video call anyone?

[Jan Iversen]

Nice way to say “no excuse for not being there” :-) 

I am getting ready, hope my iPad will cooperate.

Rgds
Jan I.

Enviado desde mi iPad

> El 5 jul 2018, a las 18:31, Lubomir I. Ivanov  escribió:
> 
> the meeting is in 30 minutes.
> 
> our agenda and Zoom link is in here:
> https://docs.google.com/document/d/1v745D3TznRG7rHOKInLR-nEmCQ6wMehehlWPtV40_HY/edit#heading=h.wkz4ubcmcwg8
> 
> lubomir
> --
> ___
> subsurface mailing list
> subsurface@subsurface-divelog.org
> http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: iOS app no longer switching to device language

[Jan Iversen]

Enviado desde mi iPad

> El 3 jul 2018, a las 18:21, Dirk Hohndel  escribió:
> 
> 
>> On Jul 3, 2018, at 8:58 AM, Jan Iversen  wrote:
>> 
>> I have narrowed it down to be between 4.7.8.286 (works) and 4.7.8.357 (which 
>> do not work). As far as I can see my movement of packaging/ios/translations 
>> is within that range, so maybe you have a script that expect 
>> packaging/ios/translations.
> 
> I'll look at it over lunch today.
> 
>> I have built the “middle” version, but cannot load it (I am on a ssh to my 
>> server from my ipad), as the ipad does not allow me to download the binary 
>> package using ssh (any suggestions??)
> 
> No idea how to do that.
> 
>> A side question, how do build/run tests locally ?
> 
> For a number of weird reasons testing "on device" is really hard with my 
> setup. I usually end up uploading it to Apple and then just download it from 
> there as "internal testing" to my iPad. Which makes the turnaround time 
> frustratingly long.
I am without mac until next friday, but that might actually help me.

I only have my ipad and ssh here.

Maybe my test question was worded wrongly. The linux build runs our test suite, 
how can I do that locally (on a remote mac) ?

Rgds
Jan I.

> 
> /D
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: developer video call anyone?

[Jan Iversen]

UPS, just show how my head is spinning, of course Thursday !

As you know my hope is to get to know (and they get to know me) some of the 
core developers.

Sorry for the mistake.
Rgds
Jan I.


Enviado desde mi iPad

> El 3 jul 2018, a las 18:17, Dirk Hohndel  escribió:
> 
> 
>> On Jul 3, 2018, at 8:51 AM, Jan Iversen  wrote:
>> 
>> See you all tomorrow (btw I am a bit disappointed about who participated, 
>> had hoped for more.
> 
> Day after tomorrow, right? Thursday.
> 
> Frankly, I had no idea how many people would be interested. We've been an 
> active community 
> for seven years without a single call / video call. Let's see how this works 
> out and decide if it's
> worth it. I certainly hope that many will decide to call in, but it is of 
> course entirely optional.
> 
> /D
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: iOS app no longer switching to device language

[Jan Iversen]

Hi Dirk

I have narrowed it down to be between 4.7.8.286 (works) and 4.7.8.357 (which do 
not work). As far as I can see my movement of packaging/ios/translations is 
within that range, so maybe you have a script that expect 
packaging/ios/translations.

I have built the “middle” version, but cannot load it (I am on a ssh to my 
server from my ipad), as the ipad does not allow me to download the binary 
package using ssh (any suggestions??)

A side question, how do build/run tests locally ?

Rgds
Jan I

Enviado desde mi iPad

> El 2 jul 2018, a las 23:22, Dirk Hohndel  escribió:
> 
> 
>> On Jul 2, 2018, at 2:17 PM, Jan Iversen  wrote:
>> 
>> I normally test with Spanish and English
>> 
>> Just changed language on my iPhone and beta 4.7.8.387 does not change 
>> language but my master version 4.7.8.286 does change. I will isolate it a 
>> bit closer tomorrow.
> 
> Thanks. I appreciate that. The results so far seem to indicate that the issue 
> may be in my build process, though :-(
> 
> /D
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: developer video call anyone?

[Jan Iversen]

Enviado desde mi iPad

> El 3 jul 2018, a las 16:20, Lubomir I. Ivanov  escribió:
> 
>> On 3 July 2018 at 17:12, Jan Iversen  wrote:
>> 
>> gdocs link:
>> https://docs.google.com/document/d/1v745D3TznRG7rHOKInLR-nEmCQ6wMehehlWPtV40_HY/edit?usp=sharing
>> 
>> 
>> 
>> For some reason I can no longer edit the document (surely my fault), so here
>> is my mobile priority list:
>> 
> 
> everyone should be able to edit.
> i've added the items.
> 
Thanks a lot, I did add my name so I was able to edit before, but not it 
“demands” I download the google app, which for other reasons not is possible.

I am sure it is something I have done, but we are right now hiking at 1.100 
meters with equipment on a trailer to start a altitude dive training, so maybe 
my brain is shorted :-)

See you all tomorrow (btw I am a bit disappointed about who participated, had 
hoped for more.

> Dirk, can we get a fixed Zoom link or would you announce it before the 
> meeting?
+1

Rgds
Jan I.

> 
> lubomir
> --
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: developer video call anyone?

[Jan Iversen]

Enviado desde mi iPad

> El 28 jun 2018, a las 18:04, Lubomir I. Ivanov  escribió:
> 
>> On 27 June 2018 at 19:21, Dirk Hohndel  wrote:
>> 
>> So a couple of people have suggested this, most recently Jan. And since I 
>> just had yet another incident of "words written don't always do a good job 
>> of conveying intention" (sorry Berthold) I figured I should just go ahead 
>> and propose this.
>> 
>> How about we try to do a video call for Subsurface developers. No idea how 
>> frequently, maybe once a month? Assuming anyone shows up and assuming that 
>> this is perceived useful, that is :-)
>> 
>> I can create a zoom meeting (zoom seems to work on all OSs reasonably well - 
>> yes, it's proprietary, but... yeah, it actually tends to work). Since almost 
>> everyone is in Europe, let's aim for early-ish my time, later yours.
>> 
>> How about Thursday July 5 - 10am Pacific, 7pm Central Europe, 8pm in Finland 
>> and Bulgaria?
>> 
>> Who'd be interested in general, and who would actually be able to join at 
>> that date / time?
>> 
> 
> gdocs link:
> https://docs.google.com/document/d/1v745D3TznRG7rHOKInLR-nEmCQ6wMehehlWPtV40_HY/edit?usp=sharing


For some reason I can no longer edit the document (surely my fault), so here is 
my mobile priority list:

1: Finalize qPref, this includes:
Get current PRs merged
Remove all references to prefs-macro outside qPref (only used in a single file)
Remove all use of QSetting (if possible) outside qPref (append to qPref)
2: Add dynamic loaded page with all preference variables (tool for developers)
3: make settings Depend on screen size (more estate more options)
add new setting (small/medium/large == phone/tablet/desktop)
add all settings from desktop
replace theme by color selection wheel
4: Update divelist (all menu content depend on size)
replace long press with swipe and action menu
add same menus as in desktop (size small phone only offers delete)
add header row with add/remove cols (like desktop)
flexible grouping/sorting on any col.
5: share more ui/qml code with desktop

This is an ambitious plan, but we need good stuff for a version 3.0 

> 
> please, add your name and potential topics you want us to talk about.
> 
> lubomir
> --
> ___
> subsurface mailing list
> subsurface@subsurface-divelog.org
> http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: iOS app no longer switching to device language

[Jan Iversen]

You do remember that packaging/ios/translations moved to something like 
packaging/iOS/build-qt5.10 if you ude otter scripts for release building that 
Might be the problem

Reds
Jan I

Enviado desde mi iPhone

> El 2 jul 2018, a las 23:22, Dirk Hohndel  escribió:
> 
> Delivered-To: jancasacon...@gmail.com
> Received: by 2002:a9d:708e:0:0:0:0:0 with SMTP id l14-v6csp359528otj; Mon, 2
> Jul 2018 14:22:22 -0700 (PDT)
> X-Google-Smtp-Source: 
> AAOMgpd/egXRxJYZC96m5HkqrgZQPI6hCPrIOZYgzayQT3Dj2MN6FSXHM3VBFTHwykPrLZbdPXVV
> X-Received: by 2002:a62:9fd1:: with SMTP id
> v78-v6mr26872687pfk.233.1530566542708; Mon, 02 Jul 2018 14:22:22 -0700 (PDT)
> ARC-Seal: i=1; a=rsa-sha256; t=1530566542; cv=none; d=google.com;
> s=arc-20160816;
> b=ve+jjRGGJxjqKo1Kni7lDwLqWScwvyVuiYZ2LzYnIdUrh4OIjqGH4/EA0nKEPSxj9p
> BopjfSUnK27taXP59DzD3tUMA8L08RGDqvGOroczM/cbeMeF2gmzD3qhbQ4TmrSHCl+t
> rlsOrW+f0nfdsmlKFYKbdBr/S+HInLK3xvXVMA2ThCMdSCLu3fVJOJmruEJ2dNVaY9eX
> Hg+GZ5IiZ6op4+ceYkghOvpJvi8xXrvuFmC9SuGa8sSOOxXGLJHbWFYW+Cwup/pybr4u
> 8JrD6KTdtm7k+WgwocXPC0FjtSGCZqTDUkYf35oex2emxFuehKC5m9/4Nvlv6pNFmBnq 2e5g==
> ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com;
> s=arc-20160816; h=to:references:message-id:content-transfer-encoding:cc:date
> :in-reply-to:from:subject:mime-version:delivered-to
> :arc-authentication-results; bh=0HKbFepFg2AUdsrz9CiSmi+ELYfeIiMllMZREzgUAIQ=;
> b=GkPKdDSS0WwpO1z3hGeoe/aNZF7SB9IAbLmVGAoGRP/G2t37xJELUqqyr6pve3ATFM
> URNXxyDYvlzqUzAwvXJJcK7GxuabnsCh0OYu4+oka1IxGinM8YGHZLb70vi+0zFawtrM
> x3iQa91xmtwwM1CqMapcSC0vgsDFXNQIQLKzj+U+Gv3X2eSXFXIjMiQ/vrcSBd+3KxRQ
> Aj4EIZJKg5+KXddhOYt2etOeBKX7XGOU6VaU2rHF9vm+E7ovJHx+XCmtxswYrCRmdiT4
> 74y8dIPwybXWZbWtmjk6W5KsS0eUIhpubj0MHCaQab+Xgdqqg7eVAP5S7QPSasbBGiM1 zZ+g==
> ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain
> of apmail-jani-ow...@apache.org designates 140.211.11.3 as permitted sender)
> smtp.mailfrom=apmail-jani-ow...@apache.org
> Return-Path: 
> Received: from mail.apache.org (hermes.apache.org. [140.211.11.3]) by
> mx.google.com with SMTP id r7-v6si6027769pgl.1.2018.07.02.14.22.22 for
> ; Mon, 02 Jul 2018 14:22:22 -0700 (PDT)
> Received-SPF: pass (google.com: domain of apmail-jani-ow...@apache.org
> designates 140.211.11.3 as permitted sender) client-ip=140.211.11.3;
> Authentication-Results: mx.google.com; spf=pass (google.com: domain of
> apmail-jani-ow...@apache.org designates 140.211.11.3 as permitted sender)
> smtp.mailfrom=apmail-jani-ow...@apache.org
> Received: (qmail 4589 invoked by uid 500); 2 Jul 2018 21:22:22 -
> Delivered-To: apmail-j...@apache.org
> Received: (qmail 4586 invoked by uid 99); 2 Jul 2018 21:22:22 -
> Received: from pnap-us-west-generic-nat.apache.org (HELO
> spamd2-us-west.apache.org) (209.188.14.142) by apache.org (qpsmtpd/0.29) with
> ESMTP; Mon, 02 Jul 2018 21:22:22 +
> Received: from localhost (localhost [127.0.0.1]) by spamd2-us-west.apache.org
> (ASF Mail Server at spamd2-us-west.apache.org) with ESMTP id 19CC81A2B53 for
> ; Mon,  2 Jul 2018 21:22:22 + (UTC)
> X-Virus-Scanned: Debian amavisd-new at spamd2-us-west.apache.org
> X-Spam-Flag: NO
> X-Spam-Score: -0.001
> X-Spam-Level: 
> X-Spam-Status: No, score=-0.001 tagged_above=-999 required=6.31
> tests=[RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=disabled
> Received: from mx1-lw-us.apache.org ([10.40.0.8]) by localhost
> (spamd2-us-west.apache.org [10.40.0.9]) (amavisd-new, port 10024) with ESMTP
> id pTA8HA0QBhck for ; Mon,  2 Jul 2018 21:22:21 + (UTC)
> Received: from mailhost.hohndel.org (mailhost.gr8dns.org [198.145.64.141]) by
> mx1-lw-us.apache.org (ASF Mail Server at mx1-lw-us.apache.org) with ESMTP id
> D78D65F49F for ; Mon,  2 Jul 2018 21:22:20 + (UTC)
> Received: by mailhost.hohndel.org (Postfix, from userid 112) id 55D1923E6F;
> Mon,  2 Jul 2018 14:22:20 -0700 (PDT)
> Received: from [192.168.66.11] (c-73-157-192-92.hsd1.or.comcast.net
> [73.157.192.92]) by mailhost.hohndel.org (Postfix) with ESMTPSA id
> 19B3D23E6C; Mon,  2 Jul 2018 14:22:19 -0700 (PDT)
> Content-Type: text/plain; charset=us-ascii
> Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
> Subject: Re: iOS app no longer switching to device language
> From: Dirk Hohndel 
> In-Reply-To: 
> Date: Mon, 2 Jul 2018 14:22:17 -0700
> Cc: Subsurface Mailing List 
> Content-Transfer-Encoding: quoted-printable
> Message-Id: <1e43b0eb-60f4-486d-a297-e5c60a230...@hohndel.org>
> References: 
> 
> To: Jan Iversen 
> X-Mailer: Apple Mail (2.3124)
> 
> 
>> On Jul 2, 2018, at 2:17 PM, Jan Iversen  wrote:
>> =20
>> I normally test with Spanish and English
>> =20
>> Just changed language on my iPhone and beta 4.7.8.387 does not change =
> language but my master version 4.7.8.286

Re: iOS app no longer switching to device language

[Jan Iversen]

I normally test with Spanish and English

Just changed language on my iPhone and beta 4.7.8.387 does not change language 
but my master version 4.7.8.286 does change. I will isolate it a bit closer 
tomorrow.

Enviado desde mi iPhone

> El 2 jul 2018, a las 23:04, Dirk Hohndel  escribió:
> 
> 
> Now that we actually have a few developers with clue about iOS 
> applications... while no
> one reported this during the lng beta phase, it appears that I somehow 
> managed to
> break support for other languages in Subsurface-mobile for iOS. But given 
> that it's been
> so long since we last pushed a full release, I have no idea where to start 
> looking for ideas
> what / how this may have gotten broken.
> 
> Jan - you certainly made the most changes to our build process for iOS. Any 
> ideas? Do
> do test the app in Spanish / Danish or in English?
> 
> /D
> ___
> subsurface mailing list
> subsurface@subsurface-divelog.org
> http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: iOS app no longer switching to device language

[Jan Iversen]

I am on my iPhone now, and yes here it seems not to change. But on my iPad I 
used to have Spanish on the beta version. Let me check tomorrow when I get near 
my iPad.

Reds
Jan i

Sent from my iPhone

> On 2 Jul 2018, at 23:04, Dirk Hohndel  wrote:
> 
> 
> Now that we actually have a few developers with clue about iOS 
> applications... while no
> one reported this during the lng beta phase, it appears that I somehow 
> managed to
> break support for other languages in Subsurface-mobile for iOS. But given 
> that it's been
> so long since we last pushed a full release, I have no idea where to start 
> looking for ideas
> what / how this may have gotten broken.
> 
> Jan - you certainly made the most changes to our build process for iOS. Any 
> ideas? Do
> do test the app in Spanish / Danish or in English?
> 
> /D
> ___
> subsurface mailing list
> subsurface@subsurface-divelog.org
> http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: Split a dive by time

[Jan Iversen]

Enviado desde mi iPad

> El 1 jul 2018, a las 22:08, tormento  escribió:
> 
> Or simply, where a cursor or a mark is placed...

For the desktop that is a good idea, but remember the mobile version does not 
have a cursor.

I am in favour for a simple “split by x minutes:second” feature. I would not 
change our automatic dive division (but depth) nor would I make a split on 
depth. This is something special that rarely happens, so having the user 
telling at which point in time it happened sounds like a generic way.

Rgds
Jan I
> 
>> Il giorno dom 1 lug 2018 alle ore 22:07 tormento  ha 
>> scritto:
>> I humbly suggest that the split dive option should be by time and by depth 
>> level, with both asked after selecting one of them and not hardcoded as  
>> SURFACE_THRESHOLD.
>> 
>> I have attached the dive. It's one I did in very shallow water, half as a 
>> open diver training assistant, the second during a rescue simulation. The 
>> time I'd like it to be splitted is something like 29:30 from the beginning.
>> 
>>> Il giorno dom 1 lug 2018 alle ore 21:50 Linus Torvalds 
>>>  ha scritto:
>>> On Sun, Jul 1, 2018 at 12:06 AM tormento  wrote:
>>> >
>>> > Sorry but not working for me. Perhaps I put computer not so shallow to 
>>> > recognize as “surface”.
>>> 
>>> As with a lot of subsurface issues, one of the main complications is
>>> having the UI integration.
>>> 
>>> A lot of these things are likely fairly simple to implement, but there
>>> are people like me who really don't do UI, but could do the "split
>>> dive" part fairly easily. And there are probably people who could do
>>> the UI trivially, but then don't feel comfy with the low-level dive
>>> profile data structures.
>>> 
>>> Things like the automatic dive splitting by surface time was "easy" to
>>> do, because it really ended up just needing another menu entry in the
>>> dive menu.
>>> 
>>> I do wonder what your dive computer reports the depth as? We consider
>>> "surface" to be 75 cm (so about 2.5 ft). It's an entirely arbitrary
>>> depth, going back to 2012 and never tweaked.
>>> 
>>> So I wonder what depth your dive computer reported for your surface
>>> time. Maybe we could just tweak that SURFACE_THRESHOLD, and make our
>>> automatic dive splitting JustWork(tm) for you too.
>>> 
>>>Linus
> ___
> subsurface mailing list
> subsurface@subsurface-divelog.org
> http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

branches contra tags for releases.

[Jan Iversen]

Hi

Is there a reason why we use tags instead of branches for a release. I am used 
to having a release branch for 2 reasons:
- work on master is not blocked but continues normally (with cherry pick to the 
release branch)
- it is easy to make a release patch if needed.

so hence my question.
rgds
jan I

Enviado desde mi iPad
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: Subsurface 4.8 & Subsurface-mobile 2.1 have been released

[Jan Iversen]

Gratulations to all who helped make this happen!

I am proud of being part of a team that taken action serious and talk less :-)

Looking forward to prepare some greater changes to the mobile version for an 
upcoming release.

Thanks
jan I

Enviado desde mi iPad

> El 29 jun 2018, a las 21:26, Dirk Hohndel  escribió:
> 
> Hello everyone.
> 
> As promised, I pushed out the two releases this morning. The Android app just 
> this moment got approved, the iOS is as usual still held up in review but 
> should be available "soonishly".
> Everything else is available for download, tags are pushed, sources uploaded, 
> the announcement has been posted on our website and on Facebook (no one is 
> really using Google Plus anymore, so I decided not to bother).
> As always, sharing the post on Facebook helps us get more visibility (FB 
> sends me daily nag emails that for only $30 / $50 / $25 / $xx I can reach N 
> more people... sure, I'll pay for that... NOT).
> 
> I did a rather dreadful partial translation of the announcement into German 
> for our website - I'd appreciate a better translation there. And I prepared 
> for the Dutch and Spanish translations (as we typically have those two 
> languages updated). If you want to create other translations of the 
> announcement, let me know and I'll set it up (I need to create them in 
> WordPress or things don't quite work).
> 
> The log shows that we have three new contributors: Allen Hall, Stephen 
> Goodall, and a very active new contributor - thanks Jan Iversen for all your 
> work. 
> And thanks to the reviewers, maintainers, and especially to the translators 
> who (because of the way we have set up our tooling) don't get credit in these 
> stats.
> 
> $ git shortlog -sn v4.7.8..
>126  Dirk Hohndel
>116  jan Iversen
> 73  Berthold Stoeger
> 21  Willem Ferguson
> 21  Robert C. Helling
> 19  Miika Turkia
> 16  Murillo Bernardes
> 14  Anton Lundin
>  7  Stefan Fuchs
>  6  Lubomir I. Ivanov
>  6  Jeremie Guichard
>  6  Linus Torvalds
>  3  Oliver Schwaneberg
>  3  Michał Sawicz
>  2  Stephen Goodall
>  1  Cristian Ionescu-Idbohrn
>  1  Guillaume GARDET
>  1  Allen Hall
>  1  Gaetan Bisson
> 
> 
> I think we need to update the website - it's starting to look out of date. If 
> anyone would like to help with that, I'd really appreciate it.
> 
> All the best and enjoy the weekend!
> 
> /D
> ___
> subsurface mailing list
> subsurface@subsurface-divelog.org
> http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: developer video call anyone?

[Jan Iversen]

> El 27 jun 2018, a las 22:39, Lubomir I. Ivanov  escribió:
> 
> On 27 June 2018 at 19:21, Dirk Hohndel  wrote:
>> 
>> So a couple of people have suggested this, most recently Jan. And since I 
>> just had yet another incident of "words written don't always do a good job 
>> of conveying intention" (sorry Berthold) I figured I should just go ahead 
>> and propose this.
>> 
>> How about we try to do a video call for Subsurface developers. No idea how 
>> frequently, maybe once a month? Assuming anyone shows up and assuming that 
>> this is perceived useful, that is :-)
>> 
> 
> do we want the first meeting to be within introductions and no
> particular agenda?
I would prefer, a short agenda, and that the introductions included if a person 
works on a particular field
(This would be made to a wiki page afterward, which would make it easier for 
new people like me).

> 
> if we plan on agenda items, a google document where everyone with a
> link can edit works. it can't be lost or maliciously edited as gdocs
> has good undo/history functionality.
> also this way anyone can add potential discussion topics.

Good idea !! I thought of making a list of my iOS (in reality mobile) 
priorities, and see if people in general accept the ideas (or more correctly 
the route).

Rgds
Jan I
> 
> lubomir
> --
> ___
> subsurface mailing list
> subsurface@subsurface-divelog.org
> http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: developer video call anyone?

[Jan Iversen]

Enviado desde mi iPad

> El 27 jun 2018, a las 21:07, Lubomir I. Ivanov  escribió:
> 
>> On 27 June 2018 at 19:21, Dirk Hohndel  wrote:
>> 
>> So a couple of people have suggested this, most recently Jan. And since I 
>> just had yet another incident of "words written don't always do a good job 
>> of conveying intention" (sorry Berthold) I figured I should just go ahead 
>> and propose this.
>> 
>> How about we try to do a video call for Subsurface developers. No idea how 
>> frequently, maybe once a month? Assuming anyone shows up and assuming that 
>> this is perceived useful, that is :-)
>> 
>> I can create a zoom meeting (zoom seems to work on all OSs reasonably well - 
>> yes, it's proprietary, but... yeah, it actually tends to work). Since almost 
>> everyone is in Europe, let's aim for early-ish my time, later yours.
>> 
>> How about Thursday July 5 - 10am Pacific, 7pm Central Europe, 8pm in Finland 
>> and Bulgaria?
added to my calendar, looking forward to it.

rgds
jan i
>> 
> 
> sounds good,
> i will add this to the calendar.
> 
> lubomir
> --
> ___
> subsurface mailing list
> subsurface@subsurface-divelog.org
> http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: new releases

[Jan Iversen]

Dirkh

You added release blocker on issue #1405, I suppose that means it needs to be 
solved :-)

rgds
jan i

Enviado desde mi iPad

> El 24 jun 2018, a las 9:01, Dirk Hohndel  escribió:
> 
> Your call, not an area of the code that I'd be second guessing you.
> 
> If you want it to go in, then I'd prefer as soon as possible so it sees at 
> least a little testing
> 
> 
> /D
> 
>> On June 24, 2018 1:42:27 PM GMT+08:00, "Robert C. Helling" 
>>  wrote:
>> Dirk,
>> 
>>> Am 24.06.2018 um 03:02 schrieb Dirk Hohndel :
>>> 
>>> I'll ask the same question as last week: any more issues we really
>> need to fix before the release? Or are we about good to go?
>> 
>> I have this pull request open on bug fixes in bailout. I was hoping for
>> Willem to comment on it. That (or potentially an improved version if
>> somebody finds anything wrong with it) should definitely go into the
>> next desktop version 
>> 
>> I would rather merge it as is than not doing anything at all about it. 
>> 
>> Best
>> Robert
>> From the phone so I don’t have the PR number ready. 
> 
> -- 
> from my phone.
> ___
> subsurface mailing list
> subsurface@subsurface-divelog.org
> http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: Graphical profile problem in Mobile 2.0.3

[Jan Iversen]

Qt 5.10but I build a bit untraditionally, because I use my mac. Could also 
be a matter of the SDK/NDK versions because I forgot that I am testing an 
upgrade.

rgds
jan i

Enviado desde mi iPad

> El 17 jun 2018, a las 12:50, Dirk Hohndel  escribió:
> 
> The bad news is that a build from latest master doesn't fix the problem. So 
> chances are it's something that is weird here on my system - since you said 
> it works for you.
> Which Qt version do you build against for Android?
> 
> /D
> 
>> On Jun 17, 2018, at 7:46 PM, j...@apache.org wrote:
>> 
>> Ooh forgot you are man of the world, as I used to be.
>> 
>> Thanks for making the testFlight, it is not really important if it is today 
>> or tomorrow.
>> 
>> 
>>> El 17 jun 2018, a las 12:44, Dirk Hohndel  escribió:
>>> 
>>> 
>> 
> 
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: Graphical profile problem in Mobile 2.0.3

[Jan Iversen]

It sure sounds like a bug ! Waiting one minute is looong and that should 
definitively work.

I just wonder why I cannot reproduce it on my iPad (also with the beta 
version). I assume the beta versions for android and iOS are identical, but I 
will try and test the latest master later today.

If you mail me the log (with the new clipboard feature) I can check if there 
are something unexpected.


Rgds
Jan I


> El 17 jun 2018, a las 10:53, Thomas Fänge  escribió:
> 
> HI Jan!
> 
> Well, even waiting more than a minute, it doesn't update again.
> Turning screen off and on again with a dive open doesn't help either. I can 
> only see the graphical profile when opening the dive from the list (and for a 
> second dive if I scroll left), but that's it, I never see any more profiles - 
> have to back up to the list and select a new dive to see it again.
> The behaviour is (at least for me on three different devices) repeatable to 
> 100%, so my 2 cents is that this some kind of error rather than a latency 
> problem.
> 
> If I can help out with some logs or anything else, please let me know.
> 
> Cheers,
> Thomas 
> 
> Den sön 17 juni 2018 10:41Jan Iversen  > skrev:
> Hi
> 
> Strange, to see it, I tested on my iPad and iPhone, here it works like a 
> charm.
> 
> Could this be some kind of latency problem (that is you swipe too fast). I 
> can in theory see a problem if profile widget does not complete drawing 
> before the next swipe even arrives. I will try testing on my android vm.
> 
> rgds
> Jan I.
> 
> 
>> El 17 jun 2018, a las 9:46, Thomas Fänge > > escribió:
>> 
> 
>> Should add that I tested on both Android 6, 8 and 9.
>> It works on 2.0.3 (4.7.8.287) but fails on 4.7.8.338.
>> Tested on both mobile and tablet with same result.
>> 
> 
>> /Thomas
>> 
> 
>> Den sön 17 juni 2018 09:38Thomas Fänge > > skrev:
> 
>> HI!
>> 
>> Updated to latest beta yesterday, and saw a problem while swiping through 
>> the dives.
>> If you open a dive and then swipe left or right, only the first (and second 
>> if you swipe right) dive is shown with a graphical profile. All other dives 
>> after that is shown with an empty box (see attached picture) - even the 
>> first dive if you swipe back to it.
>> 
>> Cheers,
>> Thomas
>> 
> 
>> 
>> 
>> ___
>> subsurface mailing list
>> subsurface@subsurface-divelog.org 
>> http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface 
>> 
> 

___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: Graphical profile problem in Mobile 2.0.3

[Jan Iversen]

Hi

Strange, to see it, I tested on my iPad and iPhone, here it works like a charm.

Could this be some kind of latency problem (that is you swipe too fast). I can 
in theory see a problem if profile widget does not complete drawing before the 
next swipe even arrives. I will try testing on my android vm.

rgds
Jan I.

> El 17 jun 2018, a las 9:46, Thomas Fänge  escribió:
> 
> Should add that I tested on both Android 6, 8 and 9.
> It works on 2.0.3 (4.7.8.287) but fails on 4.7.8.338.
> Tested on both mobile and tablet with same result.
> 
> /Thomas
> 
> Den sön 17 juni 2018 09:38Thomas Fänge  > skrev:
> HI!
> 
> Updated to latest beta yesterday, and saw a problem while swiping through the 
> dives.
> If you open a dive and then swipe left or right, only the first (and second 
> if you swipe right) dive is shown with a graphical profile. All other dives 
> after that is shown with an empty box (see attached picture) - even the first 
> dive if you swipe back to it.
> 
> Cheers,
> Thomas
> 
> 
> 
> ___
> subsurface mailing list
> subsurface@subsurface-divelog.org
> http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: new releases

[Jan Iversen]

> El 16 jun 2018, a las 8:03, Robert Helling  escribió:
> 
> Hi,
> 
>> On 16. Jun 2018, at 08:00, Robert Helling > > wrote:
>> 
>> I had a similar issue a few months ago with some progress dialogue. This was 
>> a Qt bug on Mac (which I filed) and did some work around for that specific 
>> dialogue. 
>> 
>> Let me try to find that. 
> 
> here it is:
> 
> https://github.com/Subsurface-divelog/subsurface/issues/1041 
> 
> https://bugreports.qt.io/browse/QTBUG-65750?attachmentViewMode=list 
> 
> 
> Does this look familiar?
That is exactly what I have on my Mac :-(
(Qt 5.10)

rgds
Jan I
> 
> Robert
> ___
> subsurface mailing list
> subsurface@subsurface-divelog.org
> http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: new releases

[Jan Iversen]

Enviado desde mi iPad

> El 16 jun 2018, a las 1:16, Dirk Hohndel  escribió:
> 
> We have lapsed on our goal to do regular releases.
> 
> Can we use the next two weeks to get both desktop and mobile into releasable 
> shape? Linus and I are doing "in the field testing" this week in Japan - and 
> true to our past track record, we have brought a freak storm to Okinawa...
> 
> So far I found one odd bug in Subsurface-mobile with downloading from the 
> Suunto EON Steel. Even though I had new dives on the DC, Subsurface-mobile 
> told me there were no new dives. I added debug output and tried again, and of 
> course it worked correctly :-/
This also happens on the mobile version (master and test flight), with Suunto 
EON Core. I have seen it a couple of times. Connection with BLE is made 
correctly, firmware version etc. written on screen and then no dives found. If 
you try again without restarting ssrf it  works. I thought it was something 
like a ble tineout. There are no indications in the normal logs.

> The other issue I see on Mac is that some of the dialogs have partially cut 
> off texts. I'm currently trying to figure out how to even debug this. There's 
> no reason I can figure out why those should not automatically size 
> correctly...
I can confirm that. It hits the divedetails window among others. I have not 
searched for it, but I saw about a month ago.

> 
> What other bugs do we know of for either desktop or mobile?
mobile: the ssrf logo in the coral picture, still shows as a black spot.

rgds
jan I
> 
> I just pushed the latest strings to transifex, hopefully two weeks of warning 
> should make it reasonably easy to get the translations dealt with...
> 
> Thanks everyone!
> 
> /D
> ___
> subsurface mailing list
> subsurface@subsurface-divelog.org
> http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: [Libreoffice-qa] Minutes of ESC call: 2018-05-30

[Jan Iversen]

Enviado desde mi iPad

> El 30 may 2018, a las 18:38, Jan Holesovsky  escribió:
> 
> * Present:
>+ Thorsten, Kendy, Heiko, Noel, Olivier, Xisco, Bubli, Stephan, Sophie,
>  Michael W., Drew, Eike, Cloph
+ jani (I was the first, when you asked for names).
Rgds
Jan I.
> 
> * Completed Action Items:
> 
> * Pending Action Items:
> 
> * Release Engineering update (Christian)
>+ 6.0.5 – RC1 – this week.
>+ about to tag  
>+ 6.1.0 beta 1 status …
>+ out for a few days now
>+ beta 2 on June 12th – Cloph plans to do the Beta 2
>+ 6.1 late features
>+ calc threading default / fixing (Miklos)
>   + ongoing – more fixes this week.
>+ writer – red-lining re-factoring (Michael S)
>   + ongoing, to be pushed the next week hopefully
>   + switch to switch those 2
>+ KDE5 work (Bubli/Thorsten)
>   + canceled for 6.1, gets merged into master the next days, with the 
> view
> to ship it in 6.2 then
>+ Help format (Stephan)
>   + still trying to figure out how to make extension help work with 
> the
> new format
>+ Get-involved info-bar & Help/About menu (Michael)
>+ Renewed the Windows certificate for another year (watch out QA).
>+ Remotes
>+ iOS remote pending Apple’s approval.
>+ Android viewer
>+ Online
>+ waiting for -6-1 branch.
> 
> * Documentation (Olivier)
>+ New Help
> + Tested build with sberg : OK
> + has a localized build now
> + Discuss: Need a tinderbox to build offline new Help 
>+ “--with-help=html”
> + Tweaks for GDPR in online pages.
>+ Help Pages
> + fixes 
> + Doc bugs triaging.
>+ Guides
> + Sprint Revision week 
>  + 6 of 16 chapters ready for publication
>  + 10 more needed still, but progressing
>  + Missing team members
> 
> * UX Update (Heiko)
>+ Bugzilla (topicUI) statistics
>247(247) (topicUI) bugs open, 315(315) (needsUXEval)
>+ Updates:
>BZ changes   1 week   1 month3 months   12 months  
> added 1(-2)  7(-7) 33(-5) 103(-5) 
> commented 8(-32)   110(-67)   461(-51)   1890(-64)
>   removed 0(0)   0(0)   2(0)   11(0)  
>  resolved 2(1)   5(-1) 31(1)  180(0)  
>+ top 10 contributors:
>  Tietze, Heiko made 46 changes in 1 month, and 813 changes in 1 year
>  Pedro made 35 changes in 1 month, and 44 changes in 1 year
>  Cor Nouws made 14 changes in 1 month, and 155 changes in 1 year
>  Thomas Lendo made 12 changes in 1 month, and 395 changes in 1 year
>  Dieter Praas made 10 changes in 1 month, and 141 changes in 1 year
>  Xisco Faulí made 8 changes in 1 month, and 330 changes in 1 year
>  Foote, V Stuart made 8 changes in 1 month, and 265 changes in 1 year
>  Henschel, Regina made 7 changes in 1 month, and 107 changes in 1 year
>  Kainz, Andreas made 7 changes in 1 month, and 23 changes in 1 year
>  Buovjaga made 7 changes in 1 month, and 191 changes in 1 year
> 
>  + Late feature coming with flat MIME icons
>+ https://bugs.documentfoundation.org/show_bug.cgi?id=117456
>+ https://gerrit.libreoffice.org/#/c/54990/
>+ Andreas K. working on this
>+ documentation team informed
> 
> * Crash Reporting (Caolan)
>+ 6(-11) import failure, 3(+0) export failures
>   + 2 exports – mst layout asserts.
>   + fast-parser fix integrated.
>+ coverity
>+ ?? 6 (+3, -9)
>+ forcepoint round 7.
>+ ??
>+ oss-fuzz ?? (10 outstanding, 9 minor)
> 
> * Crash Reporting (Xisco)
>+ http://crashreport.libreoffice.org/stats/version/5.4.5.1 
>  + 650 (last 7 days) (+35)
>+ http://crashreport.libreoffice.org/stats/version/5.4.6.2 
>  + 724 (last 7 days) (+63)
>+ http://crashreport.libreoffice.org/stats/version/5.4.7.2
>  + 340 (last 7 days) (+116)
>+ http://crashreport.libreoffice.org/stats/version/6.0.3.2
>  + 1167 (last 7 days) (-165)
>+ http://crashreport.libreoffice.org/stats/version/6.0.4.2
>  + 1228 (last 7 days) (+216)
> 
> * Budget ranking (Thorsten)
>   + on ESC share - “Budget2018” - add your ranking.
> 
> * GSoC schedule (Heiko)
>   + Coding: May 14 - August 6
>   + please tell students to send a weekly status upate.
>   + Evaluation 1: June 11 - 15
>   + Evaluation 2: July 9 - 13
>   + Students Submit Code and Final Evaluations: August 6 - 14
>   + Mentors Submit Final Evaluations: August 14 - 21
>   + Results Announced: August 22
>   + https://wiki.documentfoundation.org/Development/GSoC/2018
> 
> * Hackfests & Events
>   + a hole here – potential one in Switzerland later in the year.
>   + call for papers for the LibreOffice Conference still ongoing! (Sophie)
>  + deadline: mid-July
> 
> * 

Re: Minutes of ESC call: 2018-05-30

[Jan Iversen]

Enviado desde mi iPad

> El 30 may 2018, a las 18:38, Jan Holesovsky  escribió:
> 
> * Present:
>+ Thorsten, Kendy, Heiko, Noel, Olivier, Xisco, Bubli, Stephan, Sophie,
>  Michael W., Drew, Eike, Cloph
+ jani (I was the first, when you asked for names).
Rgds
Jan I.
> 
> * Completed Action Items:
> 
> * Pending Action Items:
> 
> * Release Engineering update (Christian)
>+ 6.0.5 – RC1 – this week.
>+ about to tag  
>+ 6.1.0 beta 1 status …
>+ out for a few days now
>+ beta 2 on June 12th – Cloph plans to do the Beta 2
>+ 6.1 late features
>+ calc threading default / fixing (Miklos)
>   + ongoing – more fixes this week.
>+ writer – red-lining re-factoring (Michael S)
>   + ongoing, to be pushed the next week hopefully
>   + switch to switch those 2
>+ KDE5 work (Bubli/Thorsten)
>   + canceled for 6.1, gets merged into master the next days, with the 
> view
> to ship it in 6.2 then
>+ Help format (Stephan)
>   + still trying to figure out how to make extension help work with 
> the
> new format
>+ Get-involved info-bar & Help/About menu (Michael)
>+ Renewed the Windows certificate for another year (watch out QA).
>+ Remotes
>+ iOS remote pending Apple’s approval.
>+ Android viewer
>+ Online
>+ waiting for -6-1 branch.
> 
> * Documentation (Olivier)
>+ New Help
> + Tested build with sberg : OK
> + has a localized build now
> + Discuss: Need a tinderbox to build offline new Help 
>+ “--with-help=html”
> + Tweaks for GDPR in online pages.
>+ Help Pages
> + fixes 
> + Doc bugs triaging.
>+ Guides
> + Sprint Revision week 
>  + 6 of 16 chapters ready for publication
>  + 10 more needed still, but progressing
>  + Missing team members
> 
> * UX Update (Heiko)
>+ Bugzilla (topicUI) statistics
>247(247) (topicUI) bugs open, 315(315) (needsUXEval)
>+ Updates:
>BZ changes   1 week   1 month3 months   12 months  
> added 1(-2)  7(-7) 33(-5) 103(-5) 
> commented 8(-32)   110(-67)   461(-51)   1890(-64)
>   removed 0(0)   0(0)   2(0)   11(0)  
>  resolved 2(1)   5(-1) 31(1)  180(0)  
>+ top 10 contributors:
>  Tietze, Heiko made 46 changes in 1 month, and 813 changes in 1 year
>  Pedro made 35 changes in 1 month, and 44 changes in 1 year
>  Cor Nouws made 14 changes in 1 month, and 155 changes in 1 year
>  Thomas Lendo made 12 changes in 1 month, and 395 changes in 1 year
>  Dieter Praas made 10 changes in 1 month, and 141 changes in 1 year
>  Xisco Faulí made 8 changes in 1 month, and 330 changes in 1 year
>  Foote, V Stuart made 8 changes in 1 month, and 265 changes in 1 year
>  Henschel, Regina made 7 changes in 1 month, and 107 changes in 1 year
>  Kainz, Andreas made 7 changes in 1 month, and 23 changes in 1 year
>  Buovjaga made 7 changes in 1 month, and 191 changes in 1 year
> 
>  + Late feature coming with flat MIME icons
>+ https://bugs.documentfoundation.org/show_bug.cgi?id=117456
>+ https://gerrit.libreoffice.org/#/c/54990/
>+ Andreas K. working on this
>+ documentation team informed
> 
> * Crash Reporting (Caolan)
>+ 6(-11) import failure, 3(+0) export failures
>   + 2 exports – mst layout asserts.
>   + fast-parser fix integrated.
>+ coverity
>+ ?? 6 (+3, -9)
>+ forcepoint round 7.
>+ ??
>+ oss-fuzz ?? (10 outstanding, 9 minor)
> 
> * Crash Reporting (Xisco)
>+ http://crashreport.libreoffice.org/stats/version/5.4.5.1 
>  + 650 (last 7 days) (+35)
>+ http://crashreport.libreoffice.org/stats/version/5.4.6.2 
>  + 724 (last 7 days) (+63)
>+ http://crashreport.libreoffice.org/stats/version/5.4.7.2
>  + 340 (last 7 days) (+116)
>+ http://crashreport.libreoffice.org/stats/version/6.0.3.2
>  + 1167 (last 7 days) (-165)
>+ http://crashreport.libreoffice.org/stats/version/6.0.4.2
>  + 1228 (last 7 days) (+216)
> 
> * Budget ranking (Thorsten)
>   + on ESC share - “Budget2018” - add your ranking.
> 
> * GSoC schedule (Heiko)
>   + Coding: May 14 - August 6
>   + please tell students to send a weekly status upate.
>   + Evaluation 1: June 11 - 15
>   + Evaluation 2: July 9 - 13
>   + Students Submit Code and Final Evaluations: August 6 - 14
>   + Mentors Submit Final Evaluations: August 14 - 21
>   + Results Announced: August 22
>   + https://wiki.documentfoundation.org/Development/GSoC/2018
> 
> * Hackfests & Events
>   + a hole here – potential one in Switzerland later in the year.
>   + call for papers for the LibreOffice Conference still ongoing! (Sophie)
>  + deadline: mid-July
> 
> * 

Re: No connection app malfunction

[Jan Iversen]

I just tested the same on my iPad (iOS).

1) started testFlight and got data from the cloud.
2) terminated app (removed from memory), stopped wifi
3) started app, shows local data loaded
4) choose “no cloud mode”
5) no crash and data stayed.

So it is not a general issue, but restricted to Android.

rgds
jan i

Enviado desde mi iPad

> El 14 may 2018, a las 22:49, Miodrag Adamovic  escribió:
> 
> One thing I have noticed is that if you open Subsurface without internet 
> connection it will pop to credentials screen(showing "local dive data loaded" 
> tab in the bottom). If I click on "no cloud mode" app crashes. When opened 
> again, dive list is empty. When opened with internet connection, dive list is 
> empty and you have to go to settings and enter credentials again. This is on 
> Note 8 with Android 8.0.0
> 
> Sent from Blue
> ___
> subsurface mailing list
> subsurface@subsurface-divelog.org
> http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: recent build; symbol lookup error in libqtgeoservices_googlemaps.so

[Jan Iversen]

> El 11 may 2018, a las 12:33, Lubomir I. Ivanov  escribió:
> 
> On 11 May 2018 at 11:46, Cristian Ionescu-Idbohrn
>  wrote:
>> Any ideas?
>> 
>> $ ./subsurface/build/subsurface -vvv
>> Subsurface v4.7.8-124-g2c29cc96a34a,
>> built with libdivecomputer v0.7.0-devel-Subsurface-NG
>> (e97a47cca55973199715df0f818b4955e60d3a31)
>> built with Qt Version 5.10.1, runtime from Qt Version 5.10.1
>> built with libgit2 0.26.0
>> "validateGL(): created OpenGLContext."
>> "validateGL(): obtained QOpenGLFunctions."
>> "validateGL(): detected OpenGL version 3.0."
>> Plugins Directory:  QDir( "...E/subsurface/build" ,
>> nameFilters = { "*" },  QDir::SortFlags( Name | IgnoreCase ) ,
>> QDir::Filters( Dirs|Files|Drives|AllEntries ) )
>> ./subsurface/build/subsurface: symbol lookup error:
>> .../install-root/usr/lib/x86_64-linux-gnu/qt5/plugins/geoservices/libqtgeoservices_googlemaps.so:
>> undefined symbol:
>> _ZN11QGeoMapTypeC1ENS_8MapStyleERK7QStringS3_bbi10QByteArray
>> 
>> 
> 
> did you bump Qt versons to 5.10.x
> 
> the constructor for QGeoMapType in the private header changed between
> 5.9.4 and 5.10:
> https://github.com/qt/qtlocation/blob/5.10/src/location/maps/qgeomaptype.cpp#L48
> 
> i guess this needs a patch for the Gmaps plugin.
> i was under the impression that we were already building against Qt 5.10.x…

I used 5.10.1 un MacOS high Sierra and are building master without problems.

rgds
Jan I.

> 
> lubomir
> --
> ___
> subsurface mailing list
> subsurface@subsurface-divelog.org
> http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: [Oltu[OpenIDConnect] Using Apache Oltu OpenID Connect as a maven dependency

[Jan Iversen]

Hi

Oltu is a retired project, meaning that there were no active developers. This 
means that Oltu will not be updated, and there are nobody available to respond 
to your questions.

Sorry
Jan I.
Chair of Attic


> El 6 may 2018, a las 20:30, Hasini Witharana  
> escribió:
> 
> Hi all,
> 
> I want to use org.apache.oltu.openidconnect as a maven dependency. But this
> is not included in https://mvnrepository.com/artifact/org.apache.oltu .
> 
> I tried the instructions, given in https://stackoverflow.com/
> questions/23513141/resolve-oltu-openid-connect-dependency-in-maven . Still
> I get an error with the version.
> 
> How can I achieve $subject?
> 
> Thank you.
> 
> -- 
> *Hasini Witharana*
> Undergraduate | Department of Computer Science and Engineering
> University of Moratuwa
> Linkedin 

Re: getting a svn2git mirror Git repository (read-only for now)

[Jan Iversen]

> El 6 may 2018, a las 12:01, Hervé BOUTEMY  escribió:
> 
> I'd like to prepare a Git mirror of our Attic site svn repo: that would be 
> useful as a general contribution helper for people more used to Git than svn 
> (which happens more and more these times)
> 
> and this would prepare an eventual future switch to Git as read-write 
> canonical repo
> 
> from experience got when doing the same step at comdev for 3 sites [1], 
> getting the svn history may be harder than expected due to the fact that we 
> don't have classical trunk/branches/tags 
> Perhaps we should wait for Domdev's projects site result before starting to 
> do 
> the job at Attic.
> 
> But at least, I think it can be useful to have a little discussion.
> WDYT?
I think it is a good idea, however we do not really need to transfer the 
history, attic is not comparable to a normal project, where I would do anything 
not to loose history. Apart from that, the svn continue to exist, so it is 
never lost, just not transferred.

rgds
Jan I.
> 
> Regards,
> 
> Hervé
> 
> 
> [1] https://issues.apache.org/jira/browse/INFRA-16355

Re: idea for site maintenance simplification

[Jan Iversen]

Sent from my iPad

> On 5 May 2018, at 11:52, Hervé BOUTEMY <herve.bout...@free.fr> wrote:
> 
> Le samedi 5 mai 2018, 07:39:02 CEST Jan Iversen a écrit :
>> Sent from my iPad
>> 
>>> On 5 May 2018, at 06:25, Hervé BOUTEMY <herve.bout...@free.fr> wrote:
>>> 
>>> Hi,
>>> 
>>> I took time to read the whole discussions from april and understand what
>>> was the common objective, and what were solutions envisioned and
>>> discussed and partly done and partly with consensus yet to be found.
>>> 
>>> AFAIK, we have a common objective: simplifying attic site maintenance.
>> 
>> Correct
>> 
>>> The simplification ideas and solutions are:
>>> - retired site update:
>>> banners solution in place with initial site http://oltu.apache.org/
>>> IIUC, there are still some improvements that could eventually be done (for
>>> .eu and .us urls), but it works quite well.
>>> This idea is the most critical, since it was really a pain for each new
>>> project move to Attic
>> 
>> Correct
>> 
>>> - have fewer files to edit:
>>> how many files precisely to edit now?
>> 
>> You have to divide that in 2:
>> - Files to edit when retiring a project (2, but the whole site is added in
>> the commit)
>> - When changing the site
> by "changing the site", you mean changing normal pages (like process.html) or 
> changing more the structure?
yes
> To me, dividing in 2 is useful to distinguish normal business as usual 
> changes, that have to be straightforward, from structural changes that are 
> expected to be heavier.
+1
> 
>> 
>>> evaluation has been that this require changing templating solution (too
>>> hard or no knowledge to add such feature to current Ant/Anakia build),
>>> and format of data
>>> this is where we have 2 competing solutions.. we'll discuss this later
>> 
>> not only, but it is the main difference.
>> 
>>> - avoiding build tools use on editor's computer:
>>> buildbot job added that builds and publish when source is updated.
>>> Manual local build and commit can still be done
>>> AFAIK, this solution works well
>> 
>> correct or use JS as in my solution ( I believe buildbot is better, but
>> added it for completeness)
> oh yes, you're right: in the previous paragraph, there was a third one that 
> was browser JavaScript based: I forgot that this was done first as an intend 
> to 
> have simultaneously fewer files to edit and no local build tool
> 
>>> - web browser only edit:
>>> Idea on this would be to use GitHub online editing: given ASF has GitBox
>>> service in place, and with previous automated build and publish on source
>>> update, this seems feasible.
>> 
>> correct
>> 
>>> This Git/GitBox/GitHub solution could bring us other advantages: branches
>>> management and PR review would ease tests and discussion before deciding
>>> to
>>> merge to trunk/master
>> 
>> in theory correct, but during my time as chair I would have been discussing
>> with myself, so it is overkill as a demand.
> for business as usual changes, no real discussion is expected before merging: 
> you were doing the job and didn't ask for help (which is more the type of 
> interaction that is expected), then everything was running as expected.
> 
> for structural changes, discussions are expected: this is where the Git/
> GitBox/GitHub solution can help.
> Personally, I just didn't track Attic mailing list sufficiently to see that 
> we 
> went from BaU to structural change. Sorry to not having answered before: with 
> this thread, I'm trying to fix my own failure on being an active Attic PMC 
> member (one of 21 PMC member) or even simply an active Attic committer (one 
> of 
> 25 committers: looks like we have a few committers who are not PMC members, I 
> don't know why/how this happened...)
> 
>> Apart from that how would you
>> test a PR that changes site layout?
> there can be multiple answers:
> 1. the most basic: just locally, since site layout changes are not BaU...
> 2. with a multi-branch buildbot job and if we can use build server as staging 
> webserver, this could be automatic: I don't know how the webserver part can 
> be 
> done with buildbot, but I know for example that this is something I do with 
> Jenkins. Sebb being our buildbot expert, we could try together
> 
>>> IMHO, working on GitBox/GitHub solution would ease future work and
>>> discussion on the "have fewer files to edit" ideas.
>>

Re: idea for site maintenance simplification

[Jan Iversen]

Sent from my iPad

> On 5 May 2018, at 06:25, Hervé BOUTEMY  wrote:
> 
> Hi,
> 
> I took time to read the whole discussions from april and understand what was 
> the common objective, and what were solutions envisioned and discussed and 
> partly done and partly with consensus yet to be found.
> 
> AFAIK, we have a common objective: simplifying attic site maintenance.
Correct
> 
> The simplification ideas and solutions are:
> - retired site update:
> banners solution in place with initial site http://oltu.apache.org/
> IIUC, there are still some improvements that could eventually be done (for 
> .eu 
> and .us urls), but it works quite well.
> This idea is the most critical, since it was really a pain for each new 
> project move to Attic
Correct
> 
> - have fewer files to edit:
> how many files precisely to edit now?
You have to divide that in 2:
- Files to edit when retiring a project (2, but the whole site is added in the 
commit)
- When changing the site 
> evaluation has been that this require changing templating solution (too hard 
> or no knowledge to add such feature to current Ant/Anakia build), and format 
> of data
> this is where we have 2 competing solutions.. we'll discuss this later
not only, but it is the main difference.
> 
> - avoiding build tools use on editor's computer:
> buildbot job added that builds and publish when source is updated.
> Manual local build and commit can still be done
> AFAIK, this solution works well
correct or use JS as in my solution ( I believe buildbot is better, but added 
it for completeness)
> 
> - web browser only edit:
> Idea on this would be to use GitHub online editing: given ASF has GitBox 
> service in place, and with previous automated build and publish on source 
> update, this seems feasible.
correct
> 
> This Git/GitBox/GitHub solution could bring us other advantages: branches 
> management and PR review would ease tests and discussion before deciding to 
> merge to trunk/master
in theory correct, but during my time as chair I would have been discussing 
with myself, so it is overkill as a demand. Apart from that how would you test 
a PR that changes site layout?
> 
> 
> IMHO, working on GitBox/GitHub solution would ease future work and discussion 
> on the "have fewer files to edit" ideas.
> And I know that it is feasible without changing many things on the current 
> situation.
> 
> WDYT about prioritizing this Git/GitBox/GitHub solution?
We had a community agreement, that I should ask for it, when somebody went 
ahead without consensus and created attic-test (I suppose as an alternative to 
using branches). I would not not like to end up with 2 git repo’s which means 
we need to reach consensus (again) on how a git implementation should be.

Thanks for a good summary, which is the reason I have taken time to answer you, 
as you surely also have read, this havoc have caused another (more important) 
problem for the Attic, a new chair need to be found and discussions are not 
really progressing.

rgds
jan i
> 
> Regards,
> 
> Hervé

Re: How to build iOS simulator and iOS device ?

[Jan Iversen]

Sent from my iPad

> On 4 May 2018, at 10:06, Dirk Hohndel  wrote:
> 
> 
> 
>> On May 4, 2018 9:08:14 AM GMT+02:00, Miika Turkia  
>> wrote:
>>> On Fri, May 4, 2018 at 10:02 AM,  wrote:
>>> 
>>> 
 but I'm not sure I want to be stuck with maintaining this as part
>> of our
 source repository". If you can make this work, make this EASY TO
>> MAINTAIN
 AS WE ADD NEW SOURCE FILES, CHANGE DEPENDENCIES... I'm willing to
>>> consider
 it - but please understand that I might also look at it and say
>> "yeah,
 no”.
>>> Fair arguments, but a bit unfair against the newer versions of Xcode.
> 
> I am using 9.3
> I think every version I try is worse than the one before.
> 
>> 
>>> My aim is to have a simple IDE, where I can develop/generate and
>> test. How
>>> do the Linux developers, hope not like I do sometimes use vi :-)
> 
> I use QtCreator and am very happy with it for rapid edit/compile/debug 
> integration.
> 
>> I have to admit I have moved on from vi and use vim nowadays. Just a
>> lot
>> more comfortable to use than any IDE I have tried.
> 
> Ah, yes. And then we have a few developers who are truly hard core. At least 
> one is using ue as his IDE :-)
> 
> But let me repeat... I'm willing to consider it, and if this is a trade-off 
> that gets us another active developer for iOS, I'll try to be flexible... but 
> I will also need to value maintainability quite highly.

That is very clear to me, I am playing with a combination of vi, make and 
simulator. I want to help the project not be a burden :-)

Anybody knows how to get QtCreator to start the ios simulator ? 

I called subsurface/scripts/build.sh -build-deps -both
then tried to drag subsurface/build-mobile/Subsurface.app into the simulator, 
but I get a very informative message “cannot be installed right now, try later” 
any hints ?

Ps. will forget Xcode for now, and see if I can debug effectively with 
QtCreator (or Xcode without generating a project).

rgds
jan i
> 
> /D
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: User profile backup

[Jan Iversen]

Sent from my iPad

> On 3 May 2018, at 21:28, Robert Helling  wrote:
> 
> Jani,
> 
>> On 3. May 2018, at 20:54, j...@apache.org wrote:
>> 
>> Found it in /Library/Application Support/Subsurface/cloudstorage
>> 
>> (Did a “find … > /dev/null, and not 2> /dev/null), time to get a strong tea 
>> !!
>> 
>> 
> 
> Subsurface would have told you about it if you asked it:
> 
> src/subsurface/build/Subsurface.app/Contents/MacOS/Subsurface -v

Now why did I not think of that :-(

thanks for that hint
rgds
jan i
> 
> gives me (amongst many other things)
> 
> Plugins Directory:  QDir( "/Users/Helling/src/subsurface/build" , nameFilters 
> = { "*" },  QDir::SortFlags( Name | IgnoreCase ) , QDir::Filters( 
> Dirs|Files|Drives|AllEntries ) )
> cloud URL set as 
> "https://cloud.subsurface-divelog.org//git/hell...@atdotde.de[hell...@atdotde.de];
> loading dive data from 
> ("https://cloud.subsurface-divelog.org//git/hell...@atdotde.de[hell...@atdotde.de];)
> 
> […]
> 
> File locations:
> 
> cloud URL set as 
> "https://cloud.subsurface-divelog.org//git/hell...@atdotde.de[hell...@atdotde.de];
> Local git storage: /Users/Helling/Library/Application 
> Support/Subsurface/cloudstorage/c72433d1ae87cbe0
> Cloud URL: 
> https://cloud.subsurface-divelog.org//git/hell...@atdotde.de[hell...@atdotde.de]
> Image hashes: /Users/Helling/Library/Application Support/Subsurface/hashes
> Local picture directory: /Users/Helling/Library/Application 
> Support/Subsurface/picturedata/
> 
> Best
> Robert
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: Discussion to select chair candidates followed by a vote starting may 13 2018.

[Jan Iversen]

> On 2 May 2018, at 11:49, sebb <seb...@gmail.com> wrote:
> 
> On 2 May 2018 at 10:33, Jan Iversen <jancasacon...@gmail.com> wrote:
>> 
>> 
>>> On 2 May 2018, at 11:09, sebb <seb...@gmail.com> wrote:
>>> 
>>> Top-posting.
>>> 
>>> Surely any discussion which relates to personnel should take place on
>>> the private@ list?
>> 
>> Surely not, a discussion/vote for a new chair is something that involves the 
>> whole community and not only the PMC.
> 
> AFAIK discussion on new chairs are held on private@
> Whilst the decision may affect the community, AFAIK a chair must be a
> member of the PMC (or an ASF member)

There are no rules saying that such a discussion has to be private@, and in all 
the projects where I have been involved (some of them as chair) the discussions 
and votes were public. I am aware that only votes from PMC members count, but 
hearing opinions from everybody cannot do any harm. 

I you recall, when I offered to be chair, I was not even committer, but that 
was seen as a formality and I share that view.

Look at the board reports, we present:
## PMC changes:
- Jan Iversen was added to the PMC on Wed Mar 15 2017
## Committer base changes:
- Last committer addition was Jan Iversen at Thu Mar 16 
 2017

That just goes to show, being practical sometimes are the better way.

> 
>> It is correct questions relating to specific persons are kept in private, 
>> typical examples are discussions about inviting a committer or more rarely a 
>> discussion about the behaviour of a committer. Neither of these are the case 
>> here, if you read private@ I made my intentions clear a while ago, and are 
>> now putting my intentions into effect.
> 
> Agreed.
> 
>> If you refer to my description of the reasons, I have kept strictly to 
>> public fact, and not expressed my personal opinion. If you feel I 
>> overstepped the line somewhere in my mail and revealed not already public 
>> information, please be specific.
> 
> I am not saying that you have.
> 
>> You cannot deny me the right to give reasons why I am leaving this project. 
>> Actually your email just confirms my decision.
> 
> That is not what I am saying at all.
> Sorry that you have got that impression.
> 
> However I think it would be wrong to discuss a new chair on a public list.
> That's all I am saying.

You may of course think as you wish, but being the one who is retiring, I 
believe it was my decision where to post the information. If you want to make 
statements/discussions in private@ it is not a problem.

I am sure you have a reason for keeping this on private@, maybe you should 
explain that on private@. As for me, I have nothing to hide, and prefer to 
involve the whole community and have a public record.

rgds
Jan I


> 
>> rgds
>> Jan I.
>> 
>> 
>>> 
>>> On 1 May 2018 at 21:46, Jan Iversen <j...@apache.org> wrote:
>>>> Hi
>>>> 
>>>> I am truly sorry having to write this email. I am embarrassed of not being 
>>>> able to keep my promise and stay as a long-term chair, but sometimes you 
>>>> have to ask yourself is it worth the time spent and instead use time where 
>>>> it is makes a difference.
>>>> 
>>>> Considering we have a very silent community and the current site 
>>>> maintenance was unacceptable to me, I spent a couple of days to make my 
>>>> life easier and asked for opinions from the community before changing the 
>>>> production site, after that our list drowned in emails from 2 pmc members 
>>>> pursuing other solutions.
>>>> 
>>>> This is not the first time we have a situation like this, a while ago we 
>>>> had long discussion with -1 flowing around, between the same 2 PMC members 
>>>> about rewriting rules etc, where finally (I believe partly due to my 
>>>> intervention) consensus was reached.
>>>> 
>>>> I volunteered to be chair and was clear it meant I had not only to file 
>>>> board reports but also do the bulk part of retiring projects. I did not 
>>>> volunteer to spend endless hours trying to get consensus or to get simple 
>>>> changes agreed on.
>>>> 
>>>> I proposed a very simple solution, but have accepted that the other 2 
>>>> solutions each have advantages, so I might have continued had I believed 
>>>> in the possibility of consensus and an, for me, easy to maintain solution. 
>>>> There are no signs of convergence and a vote on technical solutions are 
>>>> bad, apart from th

Re: Discussion to select chair candidates followed by a vote starting may 13 2018.

[Jan Iversen]

> On 2 May 2018, at 11:09, sebb <seb...@gmail.com> wrote:
> 
> Top-posting.
> 
> Surely any discussion which relates to personnel should take place on
> the private@ list?

Surely not, a discussion/vote for a new chair is something that involves the 
whole community and not only the PMC.

It is correct questions relating to specific persons are kept in private, 
typical examples are discussions about inviting a committer or more rarely a 
discussion about the behaviour of a committer. Neither of these are the case 
here, if you read private@ I made my intentions clear a while ago, and are now 
putting my intentions into effect.

If you refer to my description of the reasons, I have kept strictly to public 
fact, and not expressed my personal opinion. If you feel I overstepped the line 
somewhere in my mail and revealed not already public information, please be 
specific.

You cannot deny me the right to give reasons why I am leaving this project. 
Actually your email just confirms my decision.

rgds
Jan I.


> 
> On 1 May 2018 at 21:46, Jan Iversen <j...@apache.org> wrote:
>> Hi
>> 
>> I am truly sorry having to write this email. I am embarrassed of not being 
>> able to keep my promise and stay as a long-term chair, but sometimes you 
>> have to ask yourself is it worth the time spent and instead use time where 
>> it is makes a difference.
>> 
>> Considering we have a very silent community and the current site maintenance 
>> was unacceptable to me, I spent a couple of days to make my life easier and 
>> asked for opinions from the community before changing the production site, 
>> after that our list drowned in emails from 2 pmc members pursuing other 
>> solutions.
>> 
>> This is not the first time we have a situation like this, a while ago we had 
>> long discussion with -1 flowing around, between the same 2 PMC members about 
>> rewriting rules etc, where finally (I believe partly due to my intervention) 
>> consensus was reached.
>> 
>> I volunteered to be chair and was clear it meant I had not only to file 
>> board reports but also do the bulk part of retiring projects. I did not 
>> volunteer to spend endless hours trying to get consensus or to get simple 
>> changes agreed on.
>> 
>> I proposed a very simple solution, but have accepted that the other 2 
>> solutions each have advantages, so I might have continued had I believed in 
>> the possibility of consensus and an, for me, easy to maintain solution. 
>> There are no signs of convergence and a vote on technical solutions are bad, 
>> apart from the fact that I am convinced both solutions would receive a -1. 
>> Changes are high, that the current deadlock will end with no change at all.
>> 
>> I humbly accept my failure to help bring consensus and progress to the 
>> attic, so I hereby announce my retirement as chair/pmc/committer.
>> 
>> I am hereby starting a discussion on who should be the next chair. The 
>> discussion will run until 13 may 2018, where I will start the formal vote. 
>> The result of the vote will be added to the agenda for the board June 
>> meeting. In case we have no positive result of the vote, the board will be 
>> asked to appoint a new chair.
>> 
>> The 2 PMC members have each promised to support a future site, so it is 
>> natural for me to  propose Henkp and Sebb as chair candidates, both have 
>> used significant time to implement technical elegant solutions.
>> 
>> Ball is rolling, let the community decide.
>> 
>> rgds
>> Jan I
>> 
>> Sent from my iPad

Re: Discussion to select chair candidates followed by a vote starting may 13 2018.

[Jan Iversen]

Sent from my iPad

> On 2 May 2018, at 07:43, Henk P. Penning <penn...@uu.nl> wrote:
> 
>> On Tue, 1 May 2018, Jan Iversen wrote:
>> 
>> Date: Tue, 1 May 2018 22:46:41 +0200
>> From: Jan Iversen <j...@apache.org>
>> To: general@attic.apache.org
>> Subject: Discussion to select chair candidates followed by a vote starting 
>> may
>> 13 2018.
> 
> Hi Jan,
> 
>  I thought the plan was to reach consensus, and otherwise vote.
yes it was, but I still have the (to me) ugly -1 discussion on your rewrite 
rules in mind.

Having said that, I am seriously tired of trying to get us to discuss before 
implementing and accept this is not a matter of making the technical most 
elegant solution but making something the chair (historically) or somebody else 
can and will maintain.
> 
>  Let me try to reach consensus this way :
> 
>Hi Sebb,
> 
>  Can we agree to just let Jan pick a winner ?
>  and for us to forever hold our peace (regarding the choice)?
I am sorry but I believe it would not be the apache way for me to pick a winner 
(even though it is tempting, I think it is known that I am afraid of the 
template language in the jekyll-site)

My hope was to get you two to agree on perfecting 1 solution addressing each 
others concerns.
> 
>  This is a bike-shed problem ;
>  any simple solution is ok.
> 
>  [ Forgive my ignorance if this is against etiquette.
>How does a PMC resolve bike-shed problems ?
>  ]
just like you just did, talking to each other. This is actually a point where 
the apache way have caused projects to splinter, due to people being stubborn 
instead of flexible.

rgds
jan i
> 
>  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 \_/
> 
>> Hi
>> 
>> I am truly sorry having to write this email. I am embarrassed of not being 
>> able to keep my promise and stay as a long-term chair, but sometimes you 
>> have to ask yourself is it worth the time spent and instead use time where 
>> it is makes a difference.
>> 
>> Considering we have a very silent community and the current site maintenance 
>> was unacceptable to me, I spent a couple of days to make my life easier and 
>> asked for opinions from the community before changing the production site, 
>> after that our list drowned in emails from 2 pmc members pursuing other 
>> solutions.
>> 
>> This is not the first time we have a situation like this, a while ago we had 
>> long discussion with -1 flowing around, between the same 2 PMC members about 
>> rewriting rules etc, where finally (I believe partly due to my intervention) 
>> consensus was reached.
>> 
>> I volunteered to be chair and was clear it meant I had not only to file 
>> board reports but also do the bulk part of retiring projects. I did not 
>> volunteer to spend endless hours trying to get consensus or to get simple 
>> changes agreed on.
>> 
>> I proposed a very simple solution, but have accepted that the other 2 
>> solutions each have advantages, so I might have continued had I believed in 
>> the possibility of consensus and an, for me, easy to maintain solution. 
>> There are no signs of convergence and a vote on technical solutions are bad, 
>> apart from the fact that I am convinced both solutions would receive a -1. 
>> Changes are high, that the current deadlock will end with no change at all.
>> 
>> I humbly accept my failure to help bring consensus and progress to the 
>> attic, so I hereby announce my retirement as chair/pmc/committer.
>> 
>> I am hereby starting a discussion on who should be the next chair. The 
>> discussion will run until 13 may 2018, where I will start the formal vote. 
>> The result of the vote will be added to the agenda for the board June 
>> meeting. In case we have no positive result of the vote, the board will be 
>> asked to appoint a new chair.
>> 
>> The 2 PMC members have each promised to support a future site, so it is 
>> natural for me to  propose Henkp and Sebb as chair candidates, both have 
>> used significant time to implement technical elegant solutions.
>> 
>> Ball is rolling, let the community decide.
>> 
>> rgds
>> Jan I
>> 
>> Sent from my iPad

Discussion to select chair candidates followed by a vote starting may 13 2018.

[Jan Iversen]

Hi

I am truly sorry having to write this email. I am embarrassed of not being able 
to keep my promise and stay as a long-term chair, but sometimes you have to ask 
yourself is it worth the time spent and instead use time where it is makes a 
difference.

Considering we have a very silent community and the current site maintenance 
was unacceptable to me, I spent a couple of days to make my life easier and 
asked for opinions from the community before changing the production site, 
after that our list drowned in emails from 2 pmc members pursuing other 
solutions.

This is not the first time we have a situation like this, a while ago we had 
long discussion with -1 flowing around, between the same 2 PMC members about 
rewriting rules etc, where finally (I believe partly due to my intervention) 
consensus was reached.

I volunteered to be chair and was clear it meant I had not only to file board 
reports but also do the bulk part of retiring projects. I did not volunteer to 
spend endless hours trying to get consensus or to get simple changes agreed on. 

I proposed a very simple solution, but have accepted that the other 2 solutions 
each have advantages, so I might have continued had I believed in the 
possibility of consensus and an, for me, easy to maintain solution. There are 
no signs of convergence and a vote on technical solutions are bad, apart from 
the fact that I am convinced both solutions would receive a -1. Changes are 
high, that the current deadlock will end with no change at all.

I humbly accept my failure to help bring consensus and progress to the attic, 
so I hereby announce my retirement as chair/pmc/committer.  

I am hereby starting a discussion on who should be the next chair. The 
discussion will run until 13 may 2018, where I will start the formal vote. The 
result of the vote will be added to the agenda for the board June meeting. In 
case we have no positive result of the vote, the board will be asked to appoint 
a new chair.

The 2 PMC members have each promised to support a future site, so it is natural 
for me to  propose Henkp and Sebb as chair candidates, both have used 
significant time to implement technical elegant solutions.

Ball is rolling, let the community decide.

rgds
Jan I

Sent from my iPad

Re: attic-test.git created

[Jan Iversen]

Sent from my iPad

> On 30 Apr 2018, at 22:28, Hervé BOUTEMY <herve.bout...@free.fr> wrote:
> 
> Le lundi 30 avril 2018, 21:03:24 CEST Jan Iversen a écrit :
>> Sent from my iPad
>> 
>>> On 30 Apr 2018, at 20:43, Hervé BOUTEMY <herve.bout...@free.fr> wrote:
>>> 
>>> I don't get what's the issue with creating a test Git repo, that is
>>> independent from anything else, and that was discussed on the ML
>> 
>> There are no issue as such, it is just that lately we have seen a lot of
>> things happening very uncoordinated. In this case it happened crossing
>> another (slightly older, but with positive comments) to move the production
>> to git.
>> 
>> I would have preferred a more organized way, e.g. making sure a test site
>> (or build bot) will have someone to maintain it, before just doing it.
>> However this is just my opinion, which, even though I did the maintenance,
>> seems to count very little.
>> 
>> Please lets stop this discussion, done is done, and I (as
>> chair/pmc/committer) will have to accept the consequences.
> there are no consequences to creating a test git repo

I think you mean there are no technical consequences, which are totally right, 
but there are other types, like e.g. the effect on the community or personally 
for people doing the maintenance. This action was for me the newest drop in a 
long chain of rain, but please I am NOT thinking or suggesting you did anything 
wrong, I am just tired.

rgds
jan I
> 
>> 
>> rgds
>> jan I.
>> 
>>> I did the exact same at GitHub just because it was outside Apache then was
>>> even more clear that it was a side test to have  chance to get common
>>> tests
>>> instead of long discussions where it's clear that a part of the discussion
>>> is that we don't have the same initial culture on the technical parts
>>> 
>>> regards,
>>> 
>>> Hervé
>>> 
>>> Le lundi 30 avril 2018, 19:39:16 CEST Jan Iversen a écrit :
>>>> Hi
>>>> 
>>>> We just received an email that attic-test.git is created, on private,
>>>> which
>>>> I cannot relay here due to apache policy (which I agree with).
>>>> 
>>>> I can however relay my response, what apart from a “thank you” was a call
>>>> to all:
>>>> 
>>>> “I must however state that the word “consensus” seems to mean nothing in
>>>> our little community. I remember we have discussed transferring the site
>>>> to git, something I would have done tomorrow based on the positive
>>>> comments... but attic-test, where did that come from.”
>>>> 
>>>> I am concerned about people going in different directions, without trying
>>>> to get consensus, what the community wants, that way we will never reach
>>>> a state where we can get a new site online.
>>>> 
>>>> PMC members know who made the request in self-service but not who
>>>> initiated
>>>> it.
>>>> 
>>>> A concerned committer/PMC/Chair
>>>> jan I
>>>> 
>>>> 
>>>> Sent from my iPad
>>>> 
>>>> 
>>>> Sent from my iPad
> 
> 

Re: attic-test.git created

[Jan Iversen]

Sent from my iPad

> On 30 Apr 2018, at 20:43, Hervé BOUTEMY <herve.bout...@free.fr> wrote:
> 
> I don't get what's the issue with creating a test Git repo, that is 
> independent from anything else, and that was discussed on the ML
There are no issue as such, it is just that lately we have seen a lot of things 
happening very uncoordinated. In this case it happened crossing another 
(slightly older, but with positive comments) to move the production to git. 

I would have preferred a more organized way, e.g. making sure a test site (or 
build bot) will have someone to maintain it, before just doing it. However this 
is just my opinion, which, even though I did the maintenance, seems to count 
very little.

Please lets stop this discussion, done is done, and I (as chair/pmc/committer) 
will have to accept the consequences.

rgds
jan I.

> 
> I did the exact same at GitHub just because it was outside Apache then was 
> even more clear that it was a side test to have  chance to get common tests 
> instead of long discussions where it's clear that a part of the discussion is 
> that we don't have the same initial culture on the technical parts
> 
> regards,
> 
> Hervé
> 
> Le lundi 30 avril 2018, 19:39:16 CEST Jan Iversen a écrit :
>> Hi
>> 
>> We just received an email that attic-test.git is created, on private, which
>> I cannot relay here due to apache policy (which I agree with).
>> 
>> I can however relay my response, what apart from a “thank you” was a call to
>> all:
>> 
>> “I must however state that the word “consensus” seems to mean nothing in our
>> little community. I remember we have discussed transferring the site to
>> git, something I would have done tomorrow based on the positive comments...
>> but attic-test, where did that come from.”
>> 
>> I am concerned about people going in different directions, without trying to
>> get consensus, what the community wants, that way we will never reach a
>> state where we can get a new site online.
>> 
>> PMC members know who made the request in self-service but not who initiated
>> it.
>> 
>> A concerned committer/PMC/Chair
>> jan I
>> 
>> 
>> Sent from my iPad
>> 
>> 
>> Sent from my iPad
> 
> 

Re: attic-test.git created

[Jan Iversen]

Sent from my iPad

>> On 30 Apr 2018, at 20:00, sebb <seb...@gmail.com> wrote:
>> 
>> On 30 April 2018 at 18:39, Jan Iversen <j...@apache.org> wrote:
>> Hi
>> 
>> We just received an email that attic-test.git is created, on private, which 
>> I cannot relay here due to apache policy (which I agree with).
>> 
>> I can however relay my response, what apart from a “thank you” was a call to 
>> all:
>> 
>> “I must however state that the word “consensus” seems to mean nothing in our 
>> little community. I remember we have discussed transferring the site to git, 
>> something I would have done tomorrow based on the positive comments... but 
>> attic-test, where did that come from.”
>> 
>> I am concerned about people going in different directions, without trying to 
>> get consensus, what the community wants, that way we will never reach a 
>> state where we can get a new site online.
>> 
>> PMC members know who made the request in self-service but not who initiated 
>> it.
> 
> This was proposed and discussed on this list 3 days ago:
> 
> https://lists.apache.org/thread.html/954ae76be44936b2352282a3d04ea7d72ee9d8780bcedf0259770aed@%3Cgeneral.attic.apache.org%3E

where do you see the consensus in that thread ? at the very best you can claim 
I am neutral.

And you politely forget I proposed to move attic to git tomorrow:
https://lists.apache.org/thread.html/c204426a53accc9af3a2d35ac9c0a386a094e0500e4e94dc23b7b6e5@%3Cgeneral.attic.apache.org%3E

which you agreed to.

But lets not prolong this discussion since it does not really matter done is 
done. This was the last straw in a big stack of hay, and I have made up my mind 
on what is important to me.

rgds
jan I

> 
> S.

attic-test.git created

[Jan Iversen]

Hi

We just received an email that attic-test.git is created, on private, which I 
cannot relay here due to apache policy (which I agree with). 

I can however relay my response, what apart from a “thank you” was a call to 
all:

“I must however state that the word “consensus” seems to mean nothing in our 
little community. I remember we have discussed transferring the site to git, 
something I would have done tomorrow based on the positive comments... but 
attic-test, where did that come from.”

I am concerned about people going in different directions, without trying to 
get consensus, what the community wants, that way we will never reach a state 
where we can get a new site online.

PMC members know who made the request in self-service but not who initiated it.

A concerned committer/PMC/Chair
jan I


Sent from my iPad


Sent from my iPad

Re: discussion/vote new site (again, but last time from me)

[Jan Iversen]

Sent from my iPad

> On 30 Apr 2018, at 03:10, sebb <seb...@gmail.com> wrote:
> 
>> On 29 April 2018 at 18:53, Jan Iversen <j...@apache.org> wrote:
>> Hi.
>> 
>> Based on a suggestion from Henk, I hereby once again try to start a 
>> discussion/vote on the new site.
>> 
>> We need to select either lua-site or jekyll-site. I strongly believe there 
>> are no reasons to polish the sites more before selecting, it is apparent how 
>> both sites will work.
> 
> I think the following are necessary characteristics:
> - single source of data for each project in an easy to edit format.
> (Not necessarily a single aggregated file)
> - standard data format (e.g. JSON or YAML)
> - separation of presentation and data
> - well-defined template language
> - no server-side processing (for the website; the banner is different)

??? as far as I can see both solutions have the above features, so how can we 
use that to choose between the 2 solutions ?

rgds
jan i
> 
>> I hope sincerely that Henk and Sebb can come to a consensus, so we can avoid 
>> a formal vote (remember a -1 will prohibit a solution from being 
>> implemented) which are likely to secure that we do not change the site at 
>> all.
> 
>> I have my personal preferred solution, but if Sebb/Henk can come to a 
>> consensus, I will support the consensus.
>> 
>> I am not suggesting a time limit, but I will follow the discussion, and add 
>> it to the next board report.
>> 
>> I hope more of the community will add a voice to this discussion.
>> 
>> rgds
>> jan I
>> 
>> Sent from my iPad

discussion/vote new site (again, but last time from me)

[Jan Iversen]

Hi.

Based on a suggestion from Henk, I hereby once again try to start a 
discussion/vote on the new site.

We need to select either lua-site or jekyll-site. I strongly believe there are 
no reasons to polish the sites more before selecting, it is apparent how both 
sites will work.

I hope sincerely that Henk and Sebb can come to a consensus, so we can avoid a 
formal vote (remember a -1 will prohibit a solution from being implemented) 
which are likely to secure that we do not change the site at all.

I have my personal preferred solution, but if Sebb/Henk can come to a 
consensus, I will support the consensus.

I am not suggesting a time limit, but I will follow the discussion, and add it 
to the next board report.

I hope more of the community will add a voice to this discussion.

rgds
jan I

Sent from my iPad

Re: svn commit: r1830424 - /attic/site/xdocs/process.xml

[Jan Iversen]

> On 29 Apr 2018, at 08:23, Henk P. Penning <penn...@uu.nl> wrote:
> 
>> On Sat, 28 Apr 2018, Jan Iversen wrote:
>> 
>> Date: Sat, 28 Apr 2018 19:44:45 +0200
>> From: Jan Iversen <j...@apache.org>
>> To: general@attic.apache.org
>> Subject: Re: svn commit: r1830424 - /attic/site/xdocs/process.xml
> 
>> I want to have a clear process, as it works today. In general I am not
>> in favor of just changing the process documentation, without having a
>> community consensus.
>> 
>> The process doc is on the live site, and should therefore be correct,
>> and things that may come in the future belong in either of the 2
>> solutions.
> 
> Hi Jan,
> 
>  May I ask you (as chair) to set an agenda?
>  to focus everybody's enthousiasm :-)

Wearing my chair hat, I need to give a polite note. A chair is just a member of 
the community like any other PMC, with no special powers (something I highly 
second). So everybody can start the agenda you suggest, however since I made 
the ball run, I will initiate a couple of mails.
> 
>  Perhaps something like this :
> 
>1. pick a winner
I have tried several times to start a discussion/vote, but until now I have 
been told to wait, because things are not complete. I will try one last time.

>2. format : is there consensus for yaml now ?
>   Is so, switch ; otherwise maybe later.
It seems I am the only one against, and I will not block something you and Sebb 
agree on.

>3. cleanup ; todo by all ; any order
>   -- fix the (proces) doc, other details, beautify
to me it is important we agree to these changes before they are made (as just 
happened)
>   -- fix the httpd rules [flagged/ -> flags/]
Seem like something for you and/or Sebb to do.
>   -- do the build stuff
Same.
>4. switch to git
This is just self service (have not tried yet).

As both you and Sebb have promised to maintain the site, future maintenance 
seems secured securing I am mostly of the hook (apart from the board report).

rgds
jan I
> 
>> 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: r1830424 - /attic/site/xdocs/process.xml

[Jan Iversen]

Sent from my iPad

> On 28 Apr 2018, at 14:56, sebb <seb...@gmail.com> wrote:
> 
>> On 28 April 2018 at 13:45, Jan Iversen <j...@apache.org> wrote:
>> 
>> 
>> Sent from my iPad
>> 
>>>> On 28 Apr 2018, at 14:28, sebb <seb...@gmail.com> wrote:
>>>> 
>>>> On 28 April 2018 at 13:06, Jan Iversen <j...@apache.org> wrote:
>>>> 
>>>> 
>>>> Sent from my iPad
>>>> 
>>>>> On 28 Apr 2018, at 13:07, Hervé BOUTEMY <herve.bout...@free.fr> wrote:
>>>>> 
>>>>> oh, I was just trying to document, not change anything:
>>>>> - the svnwcsub part is what works for years but was not well known outside
>>>>> infra team
>>>>> - the buildbot job *for the current build.sh* (in/repos/asf/attic/site/) 
>>>>> which
>>>>> is just a way to not require to do the build locally
>>>>> 
>>>>> this does not include anything regarding future changes that are in
>>>>> discussion/tests:
>>>>> - Git migration
>>>>> - build switch from Ant/Anakia to 3 other solutions
>>>>> 
>>>>> do you see something that is not simple documentation in my commit?
>>>>> (I don't want to add more diversity in ideas for future changes, just
>>>>> document)
>>>> will the buildbot is new, and adding it to our current process is a bit 
>>>> premature, especially since we might end up not needing it.
>>>> 
>>>> No need to reverse the commit, I simply wanted to point out facts, because 
>>>> during the last period things seem to have their own life, and are then 
>>>> seen as facts. If I were to retire a project tomorrow, I would use the old 
>>>> method, without a buildbot.
>>> 
>>> No, you cannot ignore the buildbot because it happens when you commit.
>>> 
>>> However provided that you commit all the changes at once, you should
>>> not notice a difference.
>> 
>> then let me just say, the process (online right now) says:
>> 
>> in xdocs/projects/ copy one of the files to the new project name (eg. 
>> devicemap.xml)
>> Add the new file as a link in the xdocs/stylesheets/project.xml navigation
>> Run 'ant' from the root (ie: the attic/site/ directory you checked out)
>> Review the generated files in docs/** in your browser
>> SVN commit all changes. Remember to add both the new xdocs/ project file and 
>> the new generated docs/ project file N.B. the buildbot will detect any 
>> changes to the source and build/commit the outout. So it's important to 
>> checkin all the changes at once. Or just checkin the source changes and let 
>> buildbot do the rest.
>> The new pages should go live quickly
>> so according to that I have to run ant (old process) and commit both xdocs 
>> and docs, and then buildbot will do something.this is not really 
>> understandable as it in reality describes 2 competing procedures.
> 
> There are two alternative procedures:
> - build everything locally and check it all in in one commit
> - check in the xdocs changes and let buildbot do the work
> 
> I can disable the automatic buildbot if you insist.
> But I thought we had already agreed to use it.

I just want the procedure to be very clear. the “run ant” step is not optional 
as an example. The build job is there, so I assume it can be used.

rgds
jan i
> 
>> rgds
>> jan i
>>> 
>>>> rgds
>>>> jan i
>>>>> 
>>>>> Regards,
>>>>> 
>>>>> Hervé
>>>>> 
>>>>> [1] http://svn.apache.org/viewvc/attic/site/
>>>>> 
>>>>> Le samedi 28 avril 2018, 12:54:40 CEST Jan Iversen a écrit :
>>>>>> Isn’t it a bit premature to change the process ? Seen from pow we are
>>>>>> experimenting with at least 3 proposals of which 1 does not need a
>>>>>> buildbot.
>>>>>> 
>>>>>> This is of course just my opinion.
>>>>>> 
>>>>>> rgds
>>>>>> jan I
>>>>>> 
>>>>>> Sent from my iPad
>>>>>> 
>>>>>>> On 28 Apr 2018, at 12:33, hbout...@apache.org wrote:
>>>>>>> 
>>>>>>> Author: hboutemy
>>>>>>> Date: Sat Apr 28 10:33:07 2018
>>>>>>> New Revision: 1830424
>>>>>>> 
>>>>>>> URL: h

Re: svn commit: r1830424 - /attic/site/xdocs/process.xml

[Jan Iversen]

Sent from my iPad

> On 28 Apr 2018, at 14:28, sebb <seb...@gmail.com> wrote:
> 
>> On 28 April 2018 at 13:06, Jan Iversen <j...@apache.org> wrote:
>> 
>> 
>> Sent from my iPad
>> 
>>> On 28 Apr 2018, at 13:07, Hervé BOUTEMY <herve.bout...@free.fr> wrote:
>>> 
>>> oh, I was just trying to document, not change anything:
>>> - the svnwcsub part is what works for years but was not well known outside
>>> infra team
>>> - the buildbot job *for the current build.sh* (in/repos/asf/attic/site/) 
>>> which
>>> is just a way to not require to do the build locally
>>> 
>>> this does not include anything regarding future changes that are in
>>> discussion/tests:
>>> - Git migration
>>> - build switch from Ant/Anakia to 3 other solutions
>>> 
>>> do you see something that is not simple documentation in my commit?
>>> (I don't want to add more diversity in ideas for future changes, just
>>> document)
>> will the buildbot is new, and adding it to our current process is a bit 
>> premature, especially since we might end up not needing it.
>> 
>> No need to reverse the commit, I simply wanted to point out facts, because 
>> during the last period things seem to have their own life, and are then seen 
>> as facts. If I were to retire a project tomorrow, I would use the old 
>> method, without a buildbot.
> 
> No, you cannot ignore the buildbot because it happens when you commit.
> 
> However provided that you commit all the changes at once, you should
> not notice a difference.

then let me just say, the process (online right now) says:

in xdocs/projects/ copy one of the files to the new project name (eg. 
devicemap.xml)
Add the new file as a link in the xdocs/stylesheets/project.xml navigation
Run 'ant' from the root (ie: the attic/site/ directory you checked out)
Review the generated files in docs/** in your browser
SVN commit all changes. Remember to add both the new xdocs/ project file and 
the new generated docs/ project file N.B. the buildbot will detect any changes 
to the source and build/commit the outout. So it's important to checkin all the 
changes at once. Or just checkin the source changes and let buildbot do the 
rest.
The new pages should go live quickly
so according to that I have to run ant (old process) and commit both xdocs and 
docs, and then buildbot will do something.this is not really understandable 
as it in reality describes 2 competing procedures. This is a good example of 
why I prefer not to change the procedure until we have decided on a new one 
(incl. the text in process.html)

rgds
jan i
> 
>> rgds
>> jan i
>>> 
>>> Regards,
>>> 
>>> Hervé
>>> 
>>> [1] http://svn.apache.org/viewvc/attic/site/
>>> 
>>> Le samedi 28 avril 2018, 12:54:40 CEST Jan Iversen a écrit :
>>>> Isn’t it a bit premature to change the process ? Seen from pow we are
>>>> experimenting with at least 3 proposals of which 1 does not need a
>>>> buildbot.
>>>> 
>>>> This is of course just my opinion.
>>>> 
>>>> rgds
>>>> jan I
>>>> 
>>>> Sent from my iPad
>>>> 
>>>>> On 28 Apr 2018, at 12:33, hbout...@apache.org wrote:
>>>>> 
>>>>> Author: hboutemy
>>>>> Date: Sat Apr 28 10:33:07 2018
>>>>> New Revision: 1830424
>>>>> 
>>>>> URL: http://svn.apache.org/viewvc?rev=1830424=rev
>>>>> Log:
>>>>> added links to Buildbot job and svnwcsub configuration
>>>>> 
>>>>> Modified:
>>>>>  attic/site/xdocs/process.xml
>>>>> 
>>>>> Modified: attic/site/xdocs/process.xml
>>>>> URL:
>>>>> http://svn.apache.org/viewvc/attic/site/xdocs/process.xml?rev=1830424=
>>>>> 1830423=1830424=diff
>>>>> =
>>>>> = --- attic/site/xdocs/process.xml (original)
>>>>> +++ attic/site/xdocs/process.xml Sat Apr 28 10:33:07 2018
>>>>> @@ -76,8 +76,9 @@
>>>>> 
>>>>> The following are usefull svn/https locations:
>>>>>   
>>>>> 
>>>>> - svn site >>>> href="http://svn.apache.org/repos/asf/attic;>http://svn.apache.org/repos/
>>>>> asf/attic + svn site >>>> href="http://svn.apache.org/viewvc/attic;>http://svn.apache.org/repos/asf
>>>>> /attic: sources in xdocs, generated html in
>>>>> docs>
>>>>>site >>>>href="http://attic.apache.org;>http://attic.apache.org
>>>>> 
>>>>> + internals: >>>> href="https://ci.apache.org/builders/attic-site;>Buildbot job to
>>>>> build from source and commit generated html, >>>> href="https://github.com/apache/infrastructure-puppet/blob/deployment/mod
>>>>> ules/svnwcsub/files/svnwcsub.conf#L36">svnwcsub configuration to
>>>>> update generated html from svn to webserver>
>>>>>jira >>>>href="https://issues.apache.org/jira/browse/ATTIC;>https://issues.ap
>>>>>ache.org/jira/browse/ATTIC committees.xml >>>>href="https://svn.apache.org/repos/asf/comdev/projects.apache.org/da
>>>>>ta/committees.xml">https://svn.apache.org/repos/asf/comdev/projects.a
>>>>>pache.org/data/committees.xml>
>>>>>   
>>> 
>>> 

Re: svn commit: r1830437 - /attic/site/xdocs/flagged/

[Jan Iversen]

Please do not change the current procedure, until we have agreed on a new one. 
This change is not followed if you read process.html

rgds
jan i

Sent from my iPad

> On 28 Apr 2018, at 13:42, hbout...@apache.org wrote:
> 
> Author: hboutemy
> Date: Sat Apr 28 11:42:38 2018
> New Revision: 1830437
> 
> URL: http://svn.apache.org/viewvc?rev=1830437=rev
> Log:
> put flagged directory in xdocs sources: will be copied by build.sh to 
> generated content in docs
> 
> Added:
>attic/site/xdocs/flagged/
>  - copied from r1830427, attic/site/docs/flagged/
> 

Re: Move attic to git,

[Jan Iversen]

Sent from my iPad

> On 28 Apr 2018, at 12:52, Hervé BOUTEMY <herve.bout...@free.fr> wrote:
> 
> ok for me
> 
> IIUC, the Buildbot configuration that Sebb started can work from Git source 
> as 
> well as from svn: that's great
> 
> one thing that we should do IMHO would be to better separate source from 
> generated output: only source should go to Git, and generated html should be 
> elsewhere
> this means that docs/flagged content, which is currently added directly in 
> docs 
> directory should simply be copied to xdocs and edited from there: the 
> build.sh 
> copies the content to docs, then the result will be the same. This will just 
> give cleaner separation between source and generated spaces
> 
+1  could be a second repo or a submodule.

rds
jan i
> Regards,
> 
> Hervé
> 
> Le jeudi 26 avril 2018, 08:28:58 CEST Jan Iversen a écrit :
>> Hi
>> 
>> Any objections against moving attic to git ?
>> 
>> using github enables online file editing/committing, and thus removes the
>> need for terminal access.
>> 
>> I have not found similar possibilities with svn.
>> 
>> I will let this be open until 2 may, and then continue of course unless we
>> have an open discussion.
>> 
>> rgds
>> jan i
>> Sent from my iPad
> 
> 

Re: svn commit: r1830424 - /attic/site/xdocs/process.xml

[Jan Iversen]

Isn’t it a bit premature to change the process ? Seen from pow we are 
experimenting with at least 3 proposals of which 1 does not need a buildbot.

This is of course just my opinion.

rgds
jan I

Sent from my iPad

> On 28 Apr 2018, at 12:33, hbout...@apache.org wrote:
> 
> Author: hboutemy
> Date: Sat Apr 28 10:33:07 2018
> New Revision: 1830424
> 
> URL: http://svn.apache.org/viewvc?rev=1830424=rev
> Log:
> added links to Buildbot job and svnwcsub configuration
> 
> Modified:
>attic/site/xdocs/process.xml
> 
> Modified: attic/site/xdocs/process.xml
> URL: 
> http://svn.apache.org/viewvc/attic/site/xdocs/process.xml?rev=1830424=1830423=1830424=diff
> ==
> --- attic/site/xdocs/process.xml (original)
> +++ attic/site/xdocs/process.xml Sat Apr 28 10:33:07 2018
> @@ -76,8 +76,9 @@
> 
>   The following are usefull svn/https locations:
> 
> - svn site  href="http://svn.apache.org/repos/asf/attic;>http://svn.apache.org/repos/asf/attic
> + svn site  href="http://svn.apache.org/viewvc/attic;>http://svn.apache.org/repos/asf/attic:
>  sources in xdocs, generated html in docs
>  site  href="http://attic.apache.org;>http://attic.apache.org
> + internals:  href="https://ci.apache.org/builders/attic-site;>Buildbot job to build 
> from source and commit generated html,  href="https://github.com/apache/infrastructure-puppet/blob/deployment/modules/svnwcsub/files/svnwcsub.conf#L36;>svnwcsub
>  configuration to update generated html from svn to webserver
>  jira  href="https://issues.apache.org/jira/browse/ATTIC;>https://issues.apache.org/jira/browse/ATTIC
>  committees.xml  href="https://svn.apache.org/repos/asf/comdev/projects.apache.org/data/committees.xml;>https://svn.apache.org/repos/asf/comdev/projects.apache.org/data/committees.xml
> 
> 
> 

Re: Request GitBox access for Attic?

[Jan Iversen]

Sent from my iPad

> On 28 Apr 2018, at 00:09, sebb <seb...@gmail.com> wrote:
> 
>> On 27 April 2018 at 17:57, Jan Iversen <j...@apache.org> wrote:
>> 
>> 
>> Sent from my iPad
>> 
>>> On 27 Apr 2018, at 17:17, sebb <seb...@gmail.com> wrote:
>>> 
>>> I think it would be useful to have an Attic GitBox test instance so we
>>> can try out things like Buildbot scripts and online editing.
>>> 
>>> It might also be a good way to evaluate the pros and cons of the
>>> various redesigns.
>>> Sort of like a Wiki page.
>> 
>> I am not sure what a gitbox test instance consist of, so I tend to be 
>> neutral, but considering our site have not changed for a very long time I 
>> have to ask is it really needed ? and will someone be responsible for 
>> whatever needs to be maintained over time ?
> 
> I thought you wanted to move to Git?
> If so, then it will have to be moved to an ASF GitBox as git-wip is
> being withdrawn.
yes I do want to move to git, I just did not think of gitbox as the git-server.
> 
> Having a test instance will allow us to try out Buildbot etc. before
> any possible move.
I see that, but it would also require something like attic-test/a.o if you 
really want to test.

rgds
jan i
> 
> In any case, the whole point was to have a test instance that can be
> thrown away if we no longer need it.
> 
>> In short if you all agree it is a something worth doing, then I will not 
>> stand in the way.
>> 
>> rgds
>> jan I
>> 
>> 

Re: new sites and swarm of commits.

[Jan Iversen]

Sent from my iPad

> On 28 Apr 2018, at 00:15, sebb <seb...@gmail.com> wrote:
> 
>> On 27 April 2018 at 18:01, Jan Iversen <j...@apache.org> wrote:
>> 
>> 
>> Sent from my iPad
>> 
>>>> On 27 Apr 2018, at 16:30, Henk P. Penning <penn...@uu.nl> wrote:
>>>> 
>>>> On Fri, 27 Apr 2018, Jan Iversen wrote:
>>>> 
>>>> Date: Fri, 27 Apr 2018 15:04:50 +0200
>>>> From: Jan Iversen <j...@apache.org>
>>>> To: general@attic.apache.org
>>>> Subject: Re: new sites and swarm of commits.
>>> 
>>> Hi Jan,
>>> 
>>>>>  ---
>>>>>  name: Oltu
>>>>>  project: oltu
>>>>>  retired: April 2018
>>>>>  mailnames:
>>>>>- dev
>>>>>- user
>>>>>- commits
>>>>>  tracker:
>>>>>- JIRA
>>>>>- OLTU
>>>>>  scm: svn
>>>>>  wiki: https://cwiki.apache.org/confluence/display/oltu/
>>>>>  description: |-
>>>>>Apache Oltu was an OAuth protocol implementation in Java. It also
>>>>>covers others OAuth family related implementations such as JWT, JWS
>>>>>and OpenID Connect
>>>>>  ---
>>>>> 
>>>>> What is complicated about that ?
>>>> for one it is, yaml, and I still have not seen any online validator of
>>>> that. json offers online validation so som faulty commits are avoided
>>>> (not all I know).
>>> 
>>> Why check ? If there's a yaml error the generator shows exactly
>>> where the error occurs ; I think we can catch that.
>>> If/when an error occurs, nothing should be committed, of course.
>> 
>> because the generator runs after the yaml file is committed, not before.
> 
> Of course, otherwise the buildbot has nothing to work on.
> 
> But the generated code is only committed after the generator runs.
> 
> Once a buildbot job has detected a failure it skips any remaining
> steps, so it can be set to ignore the commit.
> 
>>> 
>>>> secondly I believe having fields like JIRA and svn are wrong un very
>>>> unflexible, having the url is a lot more generic. how will you retire
>>>> e.g. AOO that runs its own bugzilla instance.
>>> 
>>> I agree ; just an url is fine ; but 'as is' is easy too.
>>> 
>>>> and I have to learn yaml.
>>> 
>>> Copy/paste/edit of the example above should suffice almost always.
>>> 
>>>>> Just ignore the commits. We'll judge the stuff when dev is done.
>>>>> I think we're mostly done.
>>> 
>>>> both of you keep saying thatI still believe that having a
>>>> volunteer who will actually maintain it is now more important than
>>>> seeing the final bits.
>>> 
>>> Ok ; I'll volunteer to maintain the site.
>>> I would love to see the stuff "at work".
>> Super one less problem. The rest of the retiring process is nearly automated 
>> so that will not be a big extra job.
> 
> I am happy to maintain the Jekyll site if that is chosen, or even the Perl 
> site.
Super, so now we have 2 volunteers, seems I am off the hook. I will start a 
discussion/vote later. 

rgds
jan i
> 
>> rgds
>> jan I
>>> 
>>>> 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: new sites and swarm of commits.

[Jan Iversen]

Sent from my iPad

> On 27 Apr 2018, at 16:30, Henk P. Penning <penn...@uu.nl> wrote:
> 
>> On Fri, 27 Apr 2018, Jan Iversen wrote:
>> 
>> Date: Fri, 27 Apr 2018 15:04:50 +0200
>> From: Jan Iversen <j...@apache.org>
>> To: general@attic.apache.org
>> Subject: Re: new sites and swarm of commits.
> 
> Hi Jan,
> 
>>>   ---
>>>   name: Oltu
>>>   project: oltu
>>>   retired: April 2018
>>>   mailnames:
>>> - dev
>>> - user
>>> - commits
>>>   tracker:
>>> - JIRA
>>> - OLTU
>>>   scm: svn
>>>   wiki: https://cwiki.apache.org/confluence/display/oltu/
>>>   description: |-
>>> Apache Oltu was an OAuth protocol implementation in Java. It also
>>> covers others OAuth family related implementations such as JWT, JWS
>>> and OpenID Connect
>>>   ---
>>> 
>>> What is complicated about that ?
>> for one it is, yaml, and I still have not seen any online validator of
>> that. json offers online validation so som faulty commits are avoided
>> (not all I know).
> 
>  Why check ? If there's a yaml error the generator shows exactly
>  where the error occurs ; I think we can catch that.
>  If/when an error occurs, nothing should be committed, of course.

because the generator runs after the yaml file is committed, not before.
> 
>> secondly I believe having fields like JIRA and svn are wrong un very
>> unflexible, having the url is a lot more generic. how will you retire
>> e.g. AOO that runs its own bugzilla instance.
> 
>  I agree ; just an url is fine ; but 'as is' is easy too.
> 
>> and I have to learn yaml.
> 
>  Copy/paste/edit of the example above should suffice almost always.
> 
>>> Just ignore the commits. We'll judge the stuff when dev is done.
>>> I think we're mostly done.
> 
>> both of you keep saying thatI still believe that having a
>> volunteer who will actually maintain it is now more important than
>> seeing the final bits.
> 
>  Ok ; I'll volunteer to maintain the site.
>  I would love to see the stuff "at work".
Super one less problem. The rest of the retiring process is nearly automated so 
that will not be a big extra job.

rgds
jan I
> 
>> 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: Request GitBox access for Attic?

[Jan Iversen]

Sent from my iPad

> On 27 Apr 2018, at 17:17, sebb  wrote:
> 
> I think it would be useful to have an Attic GitBox test instance so we
> can try out things like Buildbot scripts and online editing.
> 
> It might also be a good way to evaluate the pros and cons of the
> various redesigns.
> Sort of like a Wiki page.

I am not sure what a gitbox test instance consist of, so I tend to be neutral, 
but considering our site have not changed for a very long time I have to ask is 
it really needed ? and will someone be responsible for whatever needs to be 
maintained over time ?

In short if you all agree it is a something worth doing, then I will not stand 
in the way.

rgds
jan I

Re: new sites and swarm of commits.

[Jan Iversen]

Sent from my iPad

> On 27 Apr 2018, at 14:46, Henk P. Penning <penn...@uu.nl> wrote:
> 
>> On Fri, 27 Apr 2018, Jan Iversen wrote:
>> 
>> Date: Fri, 27 Apr 2018 13:39:16 +0200
>> From: Jan Iversen <jancasacon...@gmail.com>
>> To: general@attic.apache.org
>> Subject: new sites and swarm of commits.
> 
> Hi Jan,
> 
>> It is amazing how many commits Henk and Sebb can produce, I have lost
>> track long ago about the status of things
> 
>  Please, just ignore the commits.
sort of hard to do, since they at least sometimes changes important things in 
the existing site.
> 
>>   with one exception I see
>> both proposals having growing complexity (now e.g. both use yaml) most
>> of the complexity seems to arise in order to be to be able to handle
>> situations in the future (by using the past as s valid example)
>> something I strongly believe is a false assumption.
> 
>  Eh, no. To generate the old (even pre-attic) stuff,
>  some optional attributes had to be added.
>  The last project to retire (oltu) is typical
>  for future projects ; this is the config entry :
> 
>---
>name: Oltu
>project: oltu
>retired: April 2018
>mailnames:
>  - dev
>  - user
>  - commits
>tracker:
>  - JIRA
>  - OLTU
>scm: svn
>wiki: https://cwiki.apache.org/confluence/display/oltu/
>description: |-
>  Apache Oltu was an OAuth protocol implementation in Java. It also
>  covers others OAuth family related implementations such as JWT, JWS
>  and OpenID Connect
>---
> 
>  What is complicated about that ?
for one it is, yaml, and I still have not seen any online validator of that. 
json offers online validation so som faulty commits are avoided (not all I 
know).

secondly I believe having fields like JIRA and svn are wrong un very 
unflexible, having the url is a lot more generic. how will you retire e.g. AOO 
that runs its own bugzilla instance.

>  To update the site, all you have to do is 'edit' and 'commit' ;
>  that is the goal.
> 
and I have to learn yaml.

>  My stuff is now 300 lines of simple Perl ; as it was before.
>  Sebb uses more tools, but about the same ones as before.
>  Processing appears to be split between the (ruby) generator,
>  and the jekyll template ; preference is a matter of taste.
> 
>  Sebb is setting up the build stuff ; great ; we'll (something
>  like) that anyway after the git switch, if I'm not mistaken.
> 
>  Just ignore the commits. We'll judge the stuff when dev is done.
>  I think we're mostly done.
both of you keep saying thatI still believe that having a volunteer who 
will actually maintain it is now more important than seeing the final bits.

rgds
jan i
> 
> Sebb,
> 
>  ... are you almost done :-) ?
>  ... using yaml ?
> 
>>   The next board report will
>> contain a description of the ongoing activity, but hopefully with a
>> positive conclusion.
> 
>  I'm sure of it.
> 
>> 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 \_/

new sites and swarm of commits.

[Jan Iversen]

Hi

It is amazing how many commits Henk and Sebb can produce, I have lost track 
long ago about the status of things, with one exception I see both proposals 
having growing complexity (now e.g. both use yaml) most of the complexity seems 
to arise in order to be to be able to handle  situations in the future (by 
using the past as s valid example) something I strongly believe is a false 
assumption.

Furthermore I think in the idea of making a superior technical solution, at 
least one key human factor has been neglected.

Let me put it bluntly, are either of you prepared to take over attic 
maintenance should we go for your solution. Any solution that does not solve 
the human maintenance question is not really a solution.

I, being the current maintainer, have long stated my wishes for a new site, and 
currently the 2 proposals seems to move further away from my wishes of 
simplicity. Please do not expect me to volunteer for maintaining technical 
elegant solutions, that I do not feel comfortable with. I will of course 
respect if others volunteer to help out.

I see no progress in choosing the right solution, something that worries me 
deeply, we as a community should be able to solve this between us, and not make 
it a board issue. The next board report will contain a description of the 
ongoing activity, but hopefully with a positive conclusion.

have a nice weekend.
rgds
jan i

Sent from my iPad

Re: svn commit: r1830185 - /attic/site-lua/docs/OUT

[Jan Iversen]

and I forgot I still need to find a good yaml validator online, so I do not 
commit obvious mistakes.

rgds
jan i

Sent from my iPad

> On 26 Apr 2018, at 14:52, Henk P. Penning <penn...@uu.nl> wrote:
> 
>> On Thu, 26 Apr 2018, Jan Iversen wrote:
>> 
>> Date: Thu, 26 Apr 2018 13:32:31 +0200
>> From: Jan Iversen <j...@apache.org>
>> To: general@attic.apache.org
>> Subject: Re: svn commit: r1830185 - /attic/site-lua/docs/OUT
> 
>> Why is that? Apart from a couple of old sites data are simple one liners.
> 
>  For example ACE ; I think this :
> 
>---
>name: ACE
>project: ace
>retired: December 2017
>mailnames:
>  - dev
>  - commits
>  - users
>jira: ACE
>scm: svn
>wiki: https://cwiki.apache.org/confluence/display/ace/
>description: |-
>  Apache ACE was a software distribution framework that allows you to
>  centrally manage and distribute software components, configuration
>  data and other artifacts to target systems. It is built using OSGi and
>  can be deployed in different topologies. The target systems are
>  usually also OSGi based, but don't have to be.
>---
> 
>  ... is better than :
> 
>{
>  "name":"ACE",
>  "project": "ace",
>  "retired": "December 2017",
>  "scm": "svn",
>  "jira":"ACE",
>  "wiki":"https://cwiki.apache.org/confluence/display/ace/;,
>  "mailnames":   ["dev", "commits", "users"],
>  "description": "Apache ACE was a software distribution framework that 
> allows you to centrally manage and distribute software components, 
> configuration data and other artifacts to target systems. It is built using 
> OSGi and can be deployed in different topologies. The target systems are 
> usually also OSGi based, but don't have to be. "
>},
> 
>  I hate lines much longer than 80 chars.
> 
>> 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: svn commit: r1830185 - /attic/site-lua/docs/OUT

[Jan Iversen]

Sent from my iPad

> On 26 Apr 2018, at 14:52, Henk P. Penning <penn...@uu.nl> wrote:
> 
>> On Thu, 26 Apr 2018, Jan Iversen wrote:
>> 
>> Date: Thu, 26 Apr 2018 13:32:31 +0200
>> From: Jan Iversen <j...@apache.org>
>> To: general@attic.apache.org
>> Subject: Re: svn commit: r1830185 - /attic/site-lua/docs/OUT
> 
>> Why is that? Apart from a couple of old sites data are simple one liners.
> 
>  For example ACE ; I think this :
> 
>---
>name: ACE
>project: ace
>retired: December 2017
>mailnames:
>  - dev
>  - commits
>  - users
>jira: ACE
>scm: svn
>wiki: https://cwiki.apache.org/confluence/display/ace/
>description: |-
>  Apache ACE was a software distribution framework that allows you to
>  centrally manage and distribute software components, configuration
>  data and other artifacts to target systems. It is built using OSGi and
>  can be deployed in different topologies. The target systems are
>  usually also OSGi based, but don't have to be.
>---
> 
>  ... is better than :
> 
>{
>  "name":"ACE",
>  "project": "ace",
>  "retired": "December 2017",
>  "scm": "svn",
>  "jira":"ACE",
>  "wiki":"https://cwiki.apache.org/confluence/display/ace/;,
>  "mailnames":   ["dev", "commits", "users"],
>  "description": "Apache ACE was a software distribution framework that 
> allows you to centrally manage and distribute software components, 
> configuration data and other artifacts to target systems. It is built using 
> OSGi and can be deployed in different topologies. The target systems are 
> usually also OSGi based, but don't have to be. "
>},
> 
>  I hate lines much longer than 80 chars.
and that is exactly one of the old sites we do not touch anymore.

look at the never sites.

rgds
jan i
> 
>> 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: svn commit: r1830185 - /attic/site-lua/docs/OUT

[Jan Iversen]

Sent from my iPhone

> On 26 Apr 2018, at 13:25, sebb  wrote:
> 
>> On 26 April 2018 at 12:01, Henk P. Penning  wrote:
>>> On Thu, 26 Apr 2018, he...@apache.org wrote:
>>> 
>>> Date: Thu, 26 Apr 2018 12:37:14 +0200
>>> From: he...@apache.org
>>> To: general@attic.apache.org
>>> Subject: svn commit: r1830185 - /attic/site-lua/docs/OUT
>> 
>> 
>>  I looked a YAML ... ; perhaps it is a better format ...
> 
> IMO it is easier to read and maintain so I am fine with that.

Why is that? Apart from a couple of old sites data are simple one liners.

My preference continues to be json.

Reds
Jan I
> 
>>  Fixed :
>> 
>>  -- fields in a prefered order
>>  -- 'description' and 'postlude' folden
> 
> I have recently tried using an array for postlude.
> That has the advantage that the output is still folded.
> I would like to keep that feature if possible.
> I will try converting the copy under site-jekyll to YAML and see if
> there are any issues
> 
>>  What do you think ?
>> 
>> Sebb,
>> 
>>  can you please fix the projects.json ?
>>  Avoid the booleans by changing the values of
>>  'nodist' and 'keys' to 1 (instead of 'true').
>> 
>> 
> 
> Why avoid booleans?

Move attic to git,

[Jan Iversen]

Hi

Any objections against moving attic to git ?

using github enables online file editing/committing, and thus removes the need 
for terminal access.

I have not found similar possibilities with svn.

I will let this be open until 2 may, and then continue of course unless we have 
an open discussion.

rgds
jan i
Sent from my iPad

Re: svn commit: r1829959 - /attic/site-jekyll/src/_data/projects.json

[Jan Iversen]

> On 24 Apr 2018, at 15:38, Henk P. Penning <penn...@uu.nl> wrote:
> 
> On Tue, 24 Apr 2018, Jan Iversen wrote:
> 
>> Date: Tue, 24 Apr 2018 11:58:10 +0200
>> From: Jan Iversen <j...@apache.org>
>> To: general@attic.apache.org
>> Subject: Re: svn commit: r1829959 - 
>> /attic/site-jekyll/src/_data/projects.json
> 
>> I still argue, we just need something simple, a build script and a
>> couple of templates (which are easy to read).
> 
>  I just committed 'mk-stuff' ; 200 lines of perl-code ;
>  for now, the texts for {index,resolution,process}.html
>  are in mk-stuff too ; I couldn't decide where to put them.
> 
>  Prog 'mk-stuff' generates {index,resolution,process}.html
>  and projects/*.
> 
>  At work : http://mirror-vm80.apache.org/index.html
> 
>  Not all (per project) attributes are shown correctly,
>  but you get the idea.
And I like the idea !

A few comments:
- How about doing “mv _data/* .” And “mv _layout/* .”, that makes things even 
simpler
- Can project.html not be without the strange loops etc ?
  Btw seems you are not using that.

- We should also remove some of the fields in projects.json
- You have the templates directly in mk_stuff, it would be more readable if 
stored as a file, and e.g. replacing ATTIC_X

Have a nice afternoon.
rgds
Jan I.
 
> 
>> 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: r1829959 - /attic/site-jekyll/src/_data/projects.json

[Jan Iversen]

Sent from my iPad

> On 24 Apr 2018, at 11:49, sebb  wrote:
> 
>> On 24 April 2018 at 05:52,   wrote:
>> Author: henkp
>> Date: Tue Apr 24 04:52:50 2018
>> New Revision: 1829959
>> 
>> URL: http://svn.apache.org/viewvc?rev=1829959=rev
>> Log:
>> rm tab (illegal)
> 
> The text was updated to make sure it agreed with the existing Attic site.
why are you aiming at 100% match with the existing site ? it hardly makes 
sense, especially in cases where the exiting site have errors.

Could we please take a break in the stream of commits, and instead use the time 
to decide, what we as a community wants. Making site-jekyll 100% like the 
existing site (just new maintenance), does not really help the decision of what 
we want.

I still argue, we just need something simple, a build script and a couple of 
templates (which are easy to read).

rgds
jan i
> 
>> Modified:
>>attic/site-jekyll/src/_data/projects.json
>> 
>> Modified: attic/site-jekyll/src/_data/projects.json
>> URL: 
>> http://svn.apache.org/viewvc/attic/site-jekyll/src/_data/projects.json?rev=1829959=1829958=1829959=diff
>> ==
>> --- attic/site-jekyll/src/_data/projects.json (original)
>> +++ attic/site-jekyll/src/_data/projects.json Tue Apr 24 04:52:50 2018
>> @@ -18,7 +18,7 @@
>>"jira":"ACE",
>>"wiki":"https://cwiki.apache.org/confluence/display/ace/;,
>>"mailnames":   ["dev", "commits", "users"],
>> -   "description": "Apache ACE was a software distribution framework 
>> that allows you to centrally manage and distribute software components, 
>> configuration data and other artifacts to target systems. It is built using 
>> OSGi and can be deployed in different topologies. The target systems are 
>> usually also OSGi based, but don't have to be. "
>> +   "description": "Apache ACE was a software distribution framework that 
>> allows you to centrally manage and distribute software components, 
>> configuration data and other artifacts to target systems. It is built using 
>> OSGi and can be deployed in different topologies. The target systems are 
>> usually also OSGi based, but don't have to be. "
>> },
>> {
>>"name":"Avalon",
>> 
>> 

Re: svn commit: r1829899 - in /attic/site-jekyll/src: _data/projects.json _layouts/project.html

[Jan Iversen]

> On 23 Apr 2018, at 18:20, sebb <seb...@gmail.com> wrote:
> 
> On 23 April 2018 at 17:16, Jan Iversen <jancasacon...@gmail.com> wrote:
>> Hi
>> 
>> You are continuing along the same line as with “issues",  “scm” makes a lot 
>> of assumption how/where the code is stored.
>> 
>> My preference is really just to have the url, that is generic. Why are you 
>> against that ?
> 
> Personal preference.

Then lets hope a project like AOO never retires, because that would break your 
current naming (they have their own BZ instance) among other specialities.

I am just venting, what I see as a potential problem, that can be easily 
avoided.

Rgds
Jan I.


> 
>> rgds
>> Jan I.
>> 
>> 
>>> On 23 Apr 2018, at 18:14, s...@apache.org wrote:
>>> 
>>> Author: sebb
>>> Date: Mon Apr 23 16:14:15 2018
>>> New Revision: 1829899
>>> 
>>> URL: http://svn.apache.org/viewvc?rev=1829899=rev
>>> Log:
>>> Handle SCM
>>> 
>>> Modified:
>>>   attic/site-jekyll/src/_data/projects.json
>>>   attic/site-jekyll/src/_layouts/project.html
>>> 
>>> Modified: attic/site-jekyll/src/_data/projects.json
>>> URL: 
>>> http://svn.apache.org/viewvc/attic/site-jekyll/src/_data/projects.json?rev=1829899=1829898=1829899=diff
>>> ==
>>> --- attic/site-jekyll/src/_data/projects.json (original)
>>> +++ attic/site-jekyll/src/_data/projects.json Mon Apr 23 16:14:15 2018
>>> @@ -3,7 +3,7 @@
>>>   "name":"Abdera",
>>>   "project": "abdera",
>>>   "retired": "March 2017",
>>> -   "source code": "http://svn.apache.org/repos/asf/abdera/;,
>>> +   "scm": "svn",
>>>   "jira":"ABDERA",
>>>   "wiki":"https://cwiki.apache.org/confluence/display/ABDERA;,
>>>   "mailnames":   ["dev", "commits", "user"],
>>> @@ -13,7 +13,7 @@
>>>   "name":"ACE",
>>>   "project": "ace",
>>>   "retired": "December 2017",
>>> -   "source code": "http://svn.apache.org/repos/asf/ace;,
>>> +   "scm": "svn",
>>>   "jira":"ACE",
>>>   "wiki":"https://cwiki.apache.org/confluence/display/ACE;,
>>>   "mailnames":   ["dev", "commits", "users"],
>>> @@ -23,7 +23,7 @@
>>>   "name":"Avalon",
>>>   "project": "avalon",
>>>   "retired": "June 2004",
>>> -   "source code": "http://svn.apache.org/repos/asf/avalon;,
>>> +   "scm": "svn",
>>>   "jira":"AVALON",
>>>   "wiki":"http://wiki.apache.org/avalon/;,
>>>   "mailnames":   ["dev"],
>>> @@ -33,7 +33,6 @@
>>>   "name":"AxKit",
>>>   "website": "http://axkit.org;,
>>>   "retired": "August 2009",
>>> -   "source code": "",
>>>   "wiki":"",
>>>   "board":   "",
>>>   "mailnames":   [],
>>> @@ -45,7 +44,7 @@
>>>   "project": "axis",
>>>   "subproject":  "axis2/c/sandesha",
>>>   "retired": "September 2014",
>>> -   "source code": "http://svn.apache.org/repos/asf/axis/axis2/c/sandesha;,
>>> +   "scm": "svn",
>>>   "jira":"SANDESHA2C",
>>>   "wiki":"",
>>>   "board":   "",
>>> @@ -57,7 +56,7 @@
>>>   "project": "axis",
>>>   "subproject":  "axis2/c/savan",
>>>   "retired": "September 2014",
>>> -   "source code": "http://svn.apache.org/repos/asf/axis/axis2/c/savan;,
>>> +   "scm": "svn",
>>>   "jira":"AXIS2C",
>>>   "wiki":"",
>

Re: svn commit: r1829899 - in /attic/site-jekyll/src: _data/projects.json _layouts/project.html

[Jan Iversen]

Hi

You are continuing along the same line as with “issues",  “scm” makes a lot of 
assumption how/where the code is stored.

My preference is really just to have the url, that is generic. Why are you 
against that ?

rgds
Jan I.
 

> On 23 Apr 2018, at 18:14, s...@apache.org wrote:
> 
> Author: sebb
> Date: Mon Apr 23 16:14:15 2018
> New Revision: 1829899
> 
> URL: http://svn.apache.org/viewvc?rev=1829899=rev
> Log:
> Handle SCM
> 
> Modified:
>attic/site-jekyll/src/_data/projects.json
>attic/site-jekyll/src/_layouts/project.html
> 
> Modified: attic/site-jekyll/src/_data/projects.json
> URL: 
> http://svn.apache.org/viewvc/attic/site-jekyll/src/_data/projects.json?rev=1829899=1829898=1829899=diff
> ==
> --- attic/site-jekyll/src/_data/projects.json (original)
> +++ attic/site-jekyll/src/_data/projects.json Mon Apr 23 16:14:15 2018
> @@ -3,7 +3,7 @@
>"name":"Abdera",
>"project": "abdera",
>"retired": "March 2017",
> -   "source code": "http://svn.apache.org/repos/asf/abdera/;,
> +   "scm": "svn",
>"jira":"ABDERA",
>"wiki":"https://cwiki.apache.org/confluence/display/ABDERA;,
>"mailnames":   ["dev", "commits", "user"],
> @@ -13,7 +13,7 @@
>"name":"ACE",
>"project": "ace",
>"retired": "December 2017",
> -   "source code": "http://svn.apache.org/repos/asf/ace;,
> +   "scm": "svn",
>"jira":"ACE",
>"wiki":"https://cwiki.apache.org/confluence/display/ACE;,
>"mailnames":   ["dev", "commits", "users"],
> @@ -23,7 +23,7 @@
>"name":"Avalon",
>"project": "avalon",
>"retired": "June 2004",
> -   "source code": "http://svn.apache.org/repos/asf/avalon;,
> +   "scm": "svn",
>"jira":"AVALON",
>"wiki":"http://wiki.apache.org/avalon/;,
>"mailnames":   ["dev"],
> @@ -33,7 +33,6 @@
>"name":"AxKit",
>"website": "http://axkit.org;,
>"retired": "August 2009",
> -   "source code": "",
>"wiki":"",
>"board":   "",
>"mailnames":   [],
> @@ -45,7 +44,7 @@
>"project": "axis",
>"subproject":  "axis2/c/sandesha",
>"retired": "September 2014",
> -   "source code": "http://svn.apache.org/repos/asf/axis/axis2/c/sandesha;,
> +   "scm": "svn",
>"jira":"SANDESHA2C",
>"wiki":"",
>"board":   "",
> @@ -57,7 +56,7 @@
>"project": "axis",
>"subproject":  "axis2/c/savan",
>"retired": "September 2014",
> -   "source code": "http://svn.apache.org/repos/asf/axis/axis2/c/savan;,
> +   "scm": "svn",
>"jira":"AXIS2C",
>"wiki":"",
>"board":   "",
> @@ -69,7 +68,6 @@
>"project": "axis",
>"subproject":  "axis2/java/savan",
>"retired": "September 2014",
> -   "source code": "",
>"jira":"SAVAN",
>"wiki":"",
>"board":   "",
> @@ -80,7 +78,7 @@
>"name":"Beehive",
>"project": "beehive",
>"retired": "January 2010",
> -   "source code": "http://svn.apache.org/repos/asf/beehive;,
> +   "scm": "svn",
>"jira":"BEEHIVE",
>"wiki":"https://wiki.apache.org/beehive;,
>"mailnames":   ["dev", "commits", "user"],
> @@ -90,7 +88,7 @@
>"name":"Click",
>"project": "click",
>"retired": "May 2014",
> -   "source code": "http://svn.apache.org/repos/asf/click;,
> +   "scm": "svn",
>"jira":"CLK",
>"wiki":"https://cwiki.apache.org/confluence/display/click/;,
>"mailnames":   ["dev", "commits", "user"],
> @@ -101,7 +99,6 @@
>"project": "xml",
>"subproject":  "crimson",
>"retired": "August 2010",
> -   "source code": "",
>"wiki":"",
>"board":   "crimson",
>"mailnames":[],
> @@ -111,7 +108,7 @@
>"name":"Continuum",
>"project": "continuum",
>"retired": "May 2016",
> -   "source code": "http://svn.apache.org/repos/asf/continuum;,
> +   "scm": "svn",
>"jira":"CONTINUUM",
>"wiki":"https://cwiki.apache.org//confluence/display/CONTINUUM;,
>"mailnames":   ["dev", "users",  "commits", "issues", "notifications"],
> @@ -121,7 +118,7 @@
>"name":"Deltacloud",
>"project": "deltacloud",
>"retired": "July 2015",
> -   "source code": "http://svn.apache.org/repos/asf/deltacloud;,
> +   "scm": "git-wip",
>"jira":"DTACLOUD",
>"wiki":"",
>"mailnames":   ["dev", "commits", "user"],
> @@ -131,7 +128,7 @@
>"name":"DeviceMap",
>"project": "devicemap",
>"retired": "December 2016",
> -   "source code": "http://svn.apache.org/repos/asf/devicemap;,
> +   "scm": "svn",
>"jira":"DMAP",
>"wiki":"https://wiki.apache.org/devicemap;,
>"mailnames":   ["dev", "commits"],

Re: svn commit: r1829897 - in /attic/site-jekyll/src: _data/projects.json _layouts/project.html _plugins/generate_projects.rb

[Jan Iversen]

Having 2 fields “jira” and “bugzilla” is not simpler than having a simple url 
in “issues”.

And someday we might see a project being retired that uses its own bugzilla 
(there are at least one project with very little activity, that uses its own 
version).

The same argument goes for the fields “wiki” and “source code”.

I strongly believe it is better to have generic names like “issues” that using 
a specific name like “jira” or “bugzilla”.

rgds
Jan I.


> On 23 Apr 2018, at 17:46, s...@apache.org wrote:
> 
> Author: sebb
> Date: Mon Apr 23 15:46:22 2018
> New Revision: 1829897
> 
> URL: http://svn.apache.org/viewvc?rev=1829897=rev
> Log:
> Simplify issue tracker data
> 
> Modified:
>attic/site-jekyll/src/_data/projects.json
>attic/site-jekyll/src/_layouts/project.html
>attic/site-jekyll/src/_plugins/generate_projects.rb
> 
> Modified: attic/site-jekyll/src/_data/projects.json
> URL: 
> http://svn.apache.org/viewvc/attic/site-jekyll/src/_data/projects.json?rev=1829897=1829896=1829897=diff
> ==
> --- attic/site-jekyll/src/_data/projects.json (original)
> +++ attic/site-jekyll/src/_data/projects.json Mon Apr 23 15:46:22 2018
> @@ -4,7 +4,7 @@
>"project": "abdera",
>"retired": "March 2017",
>"source code": "http://svn.apache.org/repos/asf/abdera/;,
> -   "issues":  "https://issues.apache.org/jira/projects/ABDERA;,
> +   "jira":"ABDERA",
>"wiki":"https://cwiki.apache.org/confluence/display/ABDERA;,
>"mailnames":   ["dev", "commits", "user"],
>"description": "Apache Abdera was a project to build a 
> functionally-complete, high-performance implementation of the IETF Atom 
> Syndication Format (RFC 4287) and Atom Publishing Protocol (RFC 5023) 
> specifications."
> @@ -14,7 +14,7 @@
>"project": "ace",
>"retired": "December 2017",
>"source code": "http://svn.apache.org/repos/asf/ace;,
> -   "issues":  "https://issues.apache.org/jira/projects/ACE;,
> +   "jira":"ACE",
>"wiki":"https://cwiki.apache.org/confluence/display/ACE;,
>"mailnames":   ["dev", "commits", "users"],
>"description": "Apache ACE was a software distribution framework that 
> allows you to centrally manage and distribute software components, 
> configuration data and other artifacts to target systems. It is built using 
> OSGi and can be deployed in different topologies. The target systems are 
> usually also OSGi based, but don't have to be."
> @@ -24,7 +24,7 @@
>"project": "avalon",
>"retired": "June 2004",
>"source code": "http://svn.apache.org/repos/asf/avalon;,
> -   "issues":  "https://issues.apache.org/jira/browse/avalon/;,
> +   "jira":"AVALON",
>"wiki":"http://wiki.apache.org/avalon/;,
>"mailnames":   ["dev"],
>"description": "Apache Avalon was closed long before the creation of the 
> Apache Attic. It's mentioned here for completeness."
> @@ -34,7 +34,6 @@
>"website": "http://axkit.org;,
>"retired": "August 2009",
>"source code": "",
> -   "issues":  "",
>"wiki":"",
>"board":   "",
>"mailnames":   [],
> @@ -47,7 +46,7 @@
>"subproject":  "axis2/c/sandesha",
>"retired": "September 2014",
>"source code": "http://svn.apache.org/repos/asf/axis/axis2/c/sandesha;,
> -   "issues":  "https://issues.apache.org/jira/projects/SANDESHA2C;,
> +   "jira":"SANDESHA2C",
>"wiki":"",
>"board":   "",
>"mailnames":   [],
> @@ -59,7 +58,7 @@
>"subproject":  "axis2/c/savan",
>"retired": "September 2014",
>"source code": "http://svn.apache.org/repos/asf/axis/axis2/c/savan;,
> -   "issues":  "https://issues.apache.org/jira/browse/AXIS2C;,
> +   "jira":"AXIS2C",
>"wiki":"",
>"board":   "",
>"mailnames":   [],
> @@ -71,7 +70,7 @@
>"subproject":  "axis2/java/savan",
>"retired": "September 2014",
>"source code": "",
> -   "issues":  "https://issues.apache.org/jira/projects/SAVAN;,
> +   "jira":"SAVAN",
>"wiki":"",
>"board":   "",
>"mailnames":   [],
> @@ -82,7 +81,7 @@
>"project": "beehive",
>"retired": "January 2010",
>"source code": "http://svn.apache.org/repos/asf/beehive;,
> -   "issues":  "https://issues.apache.org/jira/projects/BEEHIVE;,
> +   "jira":"BEEHIVE",
>"wiki":"https://wiki.apache.org/beehive;,
>"mailnames":   ["dev", "commits", "user"],
>"description": "Apache Beehive was a simple object model built on J2EE and 
> Struts that used annotations to reduce the amount of required code."
> @@ -92,7 +91,7 @@
>"project": "click",
>"retired": "May 2014",
>"source code": "http://svn.apache.org/repos/asf/click;,
> -   "issues":  "https://issues.apache.org/jira/browse/CLK/;,
> +   "jira":"CLK",
>"wiki":

Re: svn commit: r1829888 - in /attic/site-jekyll/src: _data/projects.json _layouts/project.html _plugins/generate_projects.rb

[Jan Iversen]

Please when you add fields, add them to all objects. That way it is possible to 
simply copy an object. 

Alternatively the json should have a template object with all possible fields.

Problem is we forget what fields are available if there are no easy 
reminder.copy from another object or a template object and then delete (or 
set to none), what you do not need is easy.

rgds
jan i

Sent from my iPad

> On 23 Apr 2018, at 15:51, s...@apache.org wrote:
> 
> Author: sebb
> Date: Mon Apr 23 13:51:31 2018
> New Revision: 1829888
> 
> URL: http://svn.apache.org/viewvc?rev=1829888=rev
> Log:
> Split the website field into project[/subproject] if possible
> 
> Modified:
>attic/site-jekyll/src/_data/projects.json
>attic/site-jekyll/src/_layouts/project.html
>attic/site-jekyll/src/_plugins/generate_projects.rb
> 
> Modified: attic/site-jekyll/src/_data/projects.json
> URL: 
> http://svn.apache.org/viewvc/attic/site-jekyll/src/_data/projects.json?rev=1829888=1829887=1829888=diff
> ==
> --- attic/site-jekyll/src/_data/projects.json (original)
> +++ attic/site-jekyll/src/_data/projects.json Mon Apr 23 13:51:31 2018
> @@ -1,7 +1,7 @@
> [
> {
>"name":"Abdera",
> -   "website": "http://abdera.apache.org/;,
> +   "project": "abdera",
>"retired": "March 2017",
>"source code": "http://svn.apache.org/repos/asf/abdera/;,
>"issues":  "https://issues.apache.org/jira/projects/ABDERA;,
> @@ -14,7 +14,7 @@
> },
> {
>"name":"ACE",
> -   "website": "http://ace.apache.org/;,
> +   "project": "ace",
>"retired": "December 2017",
>"source code": "http://svn.apache.org/repos/asf/ace;,
>"issues":  "https://issues.apache.org/jira/projects/ACE;,
> @@ -27,7 +27,7 @@
> },
> {
>"name":"Avalon",
> -   "website": "http://avalon.apache.org/;,
> +   "project": "avalon",
>"retired": "June 2004",
>"source code": "http://svn.apache.org/repos/asf/avalon;,
>"issues":  "https://issues.apache.org/jira/browse/avalon/;,
> @@ -49,7 +49,8 @@
> {
>"id":  "axis-sandesha-c",
>"name":"Axis Sandesha2/C",
> -   "website": "http://axis.apache.org/axis2/c/sandesha;,
> +   "project": "axis",
> +   "subproject":  "axis2/c/sandesha",
>"retired": "September 2014",
>"source code": "http://svn.apache.org/repos/asf/axis/axis2/c/sandesha;,
>"issues":  "https://issues.apache.org/jira/projects/SANDESHA2C;,
> @@ -60,7 +61,8 @@
> },
> {
>"name":"Axis Savan/C",
> -   "website": "http://axis.apache.org/axis2/c/savan;,
> +   "project": "axis",
> +   "subproject":  "axis2/c/savan",
>"retired": "September 2014",
>"source code": "http://svn.apache.org/repos/asf/axis/axis2/c/savan;,
>"issues":  "https://issues.apache.org/jira/browse/AXIS2C;,
> @@ -71,7 +73,8 @@
> },
> {
>"name":"Axis Savan/Java",
> -   "website": "http://axis.apache.org/axis2/java/savan;,
> +   "project": "axis",
> +   "subproject":  "axis2/java/savan",
>"retired": "September 2014",
>"source code": "",
>"issues":  "https://issues.apache.org/jira/projects/SAVAN;,
> @@ -82,7 +85,7 @@
> },
> {
>"name":"Beehive",
> -   "website": "http://beehive.apache.org/;,
> +   "project": "beehive",
>"retired": "January 2010",
>"source code": "http://svn.apache.org/repos/asf/beehive;,
>"issues":  "https://issues.apache.org/jira/projects/BEEHIVE;,
> @@ -95,7 +98,7 @@
> },
> {
>"name":"Click",
> -   "website": "http://click.apache.org/;,
> +   "project": "click",
>"retired": "May 2014",
>"source code": "http://svn.apache.org/repos/asf/click;,
>"issues":  "https://issues.apache.org/jira/projects/CLK;,
> @@ -108,7 +111,8 @@
> },
> {
>"name":"Crimson",
> -   "website": "http://xml.apache.org/crimson;,
> +   "project": "xml",
> +   "subproject":  "crimson",
>"retired": "August 2010",
>"source code": "",
>"issues":  "",
> @@ -119,7 +123,7 @@
> },
> {
>"name":"Continuum",
> -   "website": "http://continuum.apache.org/;,
> +   "project": "continuum",
>"retired": "May 2016",
>"source code": "http://svn.apache.org/repos/asf/continuum;,
>"issues":  "https://issues.apache.org/jira/projects/CONTINUUM;,
> @@ -134,7 +138,7 @@
> },
> {
>"name":"Deltacloud",
> -   "website": "http://deltacloud.apache.org/;,
> +   "project": "deltacloud",
>"retired": "July 2015",
>"source code": "http://svn.apache.org/repos/asf/deltacloud;,
>"issues":  "https://issues.apache.org/jira/projects/DTACLOUD;,
> @@ -147,7 +151,7 @@
> },
> {
>"name":"DeviceMap",
> -   "website": "http://devicemap.apache.org/;,
> +   "project": "devicemap",
>"retired": "December 2016",
>"source code": 

Re: Index.lua script (was: svn commit: r1829853 - in /attic/site: docs/projects/oltu.html xdocs/projects/oltu.xml)

[Jan Iversen]

> On 23 Apr 2018, at 13:15, sebb AT ASF  wrote:
> 
> On 23 April 2018 at 12:07, Henk P. Penning  wrote:
> 
>> Hi Sebb,
>> 
>>  I created an 'index.lua' script for attic.a.o ;
>> 
>>  -- only some 130 lines
>>  -- it creates the index and projects/ pages for attic.a.o
>>  -- I added one or two 'dist' attributes to attic.json
>>  -- still rough ; but ready :-)
>> 
>>  At work : http://mirror-vm80.apache.org/index.lua
>>  Source  : http://mirror-vm80.apache.org/index.txt
>> 
>>  I can do the 'flagged' stuff ; easy.
> 
> AFAICT that has to run on the server, right?
> 
> That seems a waste of server resources given that the content changes
> but rarely.
> 
> Does Infra agree to converting the static Attic site into a dynamic one?
Why do we need a dynamic site (something I was told by Infra is not permitted), 
as I see it the Lua script,
Could run, triggered by a svn commit ?

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 \_/
>> 
>> -- Forwarded message --
>> Date: Mon, 23 Apr 2018 12:21:59 +0200
>> From: s...@apache.org
>> To: general@attic.apache.org
>> Subject: svn commit: r1829853 - in /attic/site: docs/projects/oltu.html
>>xdocs/projects/oltu.xml
> 
> Please don't hijack unrelated threads.

Re: New maintenance.

[Jan Iversen]

Sent from my iPad

> On 23 Apr 2018, at 00:46, sebb  wrote:
> 
>> 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.
and that is exactly where our opinion split, see my earlier mail. I am vey much 
against the idea of multiple files.
> 
>>> - 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' ?
ok with me.
> 
>>> 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.
agreed

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.

[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.

[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: 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 <penn...@uu.nl> wrote:
> 
> On Sun, 22 Apr 2018, Jan Iversen wrote:
> 
>> Date: Sun, 22 Apr 2018 14:34:29 +0200
>> From: Jan Iversen <jancasacon...@gmail.com>
>> 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/

[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

Re: Discussion on proposed solutions for simplified maintenance.

[Jan Iversen]

> On 22 Apr 2018, at 11:33, sebb <seb...@gmail.com> wrote:
> 
> On 22 April 2018 at 09:54, Jan Iversen <jancasacon...@gmail.com 
> <mailto:jancasacon...@gmail.com>> wrote:
>> 
>> 
>>> On 22 Apr 2018, at 10:17, sebb <seb...@gmail.com> wrote:
>>> 
>>> On 21 April 2018 at 12:57,  <j...@apache.org> 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 
<http://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: Second proposal for new site maintenance.

[Jan Iversen]

> On 22 Apr 2018, at 11:27, sebb <seb...@gmail.com> wrote:
> 
> On 22 April 2018 at 09:51, Jan Iversen <jancasacon...@gmail.com 
> <mailto:jancasacon...@gmail.com>> wrote:
>> 
>> 
>>> On 22 Apr 2018, at 09:43, sebb <seb...@gmail.com> wrote:
>>> 
>>> On 20 April 2018 at 12:11,  <j...@apache.org> 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: 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: Site generation ideas - JSON and Jekyll

[Jan Iversen]

Sent from my iPad

> On 19 Apr 2018, at 22:22, sebb <seb...@gmail.com> wrote:
> 
>> On 19 April 2018 at 21:08, Jan Iversen <j...@apache.org> wrote:
>> 
>> 
>> Sent from my iPad
>> 
>>>> On 19 Apr 2018, at 22:02, sebb <seb...@gmail.com> wrote:
>>>> 
>>>> On 19 April 2018 at 19:41, Jan Iversen <j...@apache.org> wrote:
>>>> 
>>>> 
>>>> Sent from my iPad
>>>> 
>>>>>> On 19 Apr 2018, at 17:10, sebb <seb...@gmail.com> wrote:
>>>>>> 
>>>>>> On 19 April 2018 at 13:27, sebb <seb...@gmail.com> wrote:
>>>>>> I have done some further investigation of using JSON and Jekyll.
>>>>>> 
>>>>>> I think JSON is not the best format for maintenance.
>>>>>> This is because it is messy including chunks of text (e.g. for
>>>>>> additional info on the project).
>>>>>> Also it does not allow any comments.
>>>>>> The format is rather strict, with lots of quotes needed, and brackets
>>>>>> and braces.
>>>>>> 
>>>>>> I think we should use YAML for the raw data, and (if necessary)
>>>>>> extract a subset into a JSON file for external consumption.
>>>> Personally I think it is a mistake. json is rather simple, and are 
>>>> supported everywhere. Yaml on the other hand is less supported (e.g. 
>>>> looked for an online validator without success). Safari and xcode formats 
>>>> json nicely whereas yaml is viewed as raw text.
>>> 
>>> The problem is that JSON gets very messy for anything but a short text 
>>> string.
>>> This is not particularly obvious with the current contents, because
>>> the longest text string is the description.
>>> But even now, some of the lines are very long.
>> I do not understand what “messy” means, json allows multiple lines text (see 
>> in my attic.js) using a ` instead of a “, that way yaml and json are equal 
>> “messy”.
> 
> The attic.js file is not JSON format; it is Javascript source. JS is
> much more flexible.
> 
>> I have another project where json is used to store translations (loaded with 
>> php), and that is sometimes 3/4 of a page, easy readable due to the 
>> multiline feature.
> 
> Again, I assume the JSON is embedded using PHP syntax.

well in both cases you assume wrong, if you save the json part of the js file 
it validates as valid json. In the other project we use a pure json file. json 
was extended some years ago with the multiline facility.

rgds
jan i
> 
>> but please see this as just a factual correction, if you prefer yaml I am 
>> the last to go against it.
>> 
> 
> Have a look at some of the .md files and see.
> I think they are much simpler.
> 
>> rgds
>> jan i
>>> 
>>>> Why do we need comments in the file, it has not been needed until now, so 
>>>> let us not introduce “hidden” data.
>>> 
>>> Allowing comments is just an additional benefit; it's not the reason
>>> for choosing YAML.
>>> 
>>> Sometimes it's useful to be able to add a TODO to a part of a data file.
>>> Or explain why a particular value is present.
>>> But again; not the reason for changing.
>>> 
>>>> but of course it is a matter of taste (just like js was).
>>>> 
>>>> extracting a json file from the yaml file seems to be overdoing it.
>>> 
>>> Again, only if necessary.
>>> 
>>>>>> 
>>>>>> As to Jekyll:
>>>>>> 
>>>>>> Jekyll can equally use a YAML data file, so it is not a problem
>>>>>> changing to YAML.
>>>>>> 
>>>>>> At present the attic-test PoC includes a single JSON data file which
>>>>>> is processed in a plugin script that generates the individual page
>>>>>> data.
>>>>>> 
>>>>>> This works well (and it looks like BuildBot supports the use of Jekyll
>>>>>> plugin scripts - other sites such as GitHub may not)
>>>>>> 
>>>>>> But I think it would be better to have a separate YAML file per project.
>>>>>> 
>>>>>> Jekyll can process these as part of a collection.
>>>>>> This avoids the need to use a plugin to generate the pages.
>>>>>> I think it also makes it a bit more obvious what is going on (each
>>>&g

Re: Site generation ideas - JSON and Jekyll

[Jan Iversen]

Sent from my iPad

> On 19 Apr 2018, at 22:02, sebb <seb...@gmail.com> wrote:
> 
>> On 19 April 2018 at 19:41, Jan Iversen <j...@apache.org> wrote:
>> 
>> 
>> Sent from my iPad
>> 
>>>> On 19 Apr 2018, at 17:10, sebb <seb...@gmail.com> wrote:
>>>> 
>>>> On 19 April 2018 at 13:27, sebb <seb...@gmail.com> wrote:
>>>> I have done some further investigation of using JSON and Jekyll.
>>>> 
>>>> I think JSON is not the best format for maintenance.
>>>> This is because it is messy including chunks of text (e.g. for
>>>> additional info on the project).
>>>> Also it does not allow any comments.
>>>> The format is rather strict, with lots of quotes needed, and brackets
>>>> and braces.
>>>> 
>>>> I think we should use YAML for the raw data, and (if necessary)
>>>> extract a subset into a JSON file for external consumption.
>> Personally I think it is a mistake. json is rather simple, and are supported 
>> everywhere. Yaml on the other hand is less supported (e.g. looked for an 
>> online validator without success). Safari and xcode formats json nicely 
>> whereas yaml is viewed as raw text.
> 
> The problem is that JSON gets very messy for anything but a short text string.
> This is not particularly obvious with the current contents, because
> the longest text string is the description.
> But even now, some of the lines are very long.
I do not understand what “messy” means, json allows multiple lines text (see in 
my attic.js) using a ` instead of a “, that way yaml and json are equal “messy”.

I have another project where json is used to store translations (loaded with 
php), and that is sometimes 3/4 of a page, easy readable due to the multiline 
feature.

but please see this as just a factual correction, if you prefer yaml I am the 
last to go against it.

rgds
jan i
> 
>> Why do we need comments in the file, it has not been needed until now, so 
>> let us not introduce “hidden” data.
> 
> Allowing comments is just an additional benefit; it's not the reason
> for choosing YAML.
> 
> Sometimes it's useful to be able to add a TODO to a part of a data file.
> Or explain why a particular value is present.
> But again; not the reason for changing.
> 
>> but of course it is a matter of taste (just like js was).
>> 
>> extracting a json file from the yaml file seems to be overdoing it.
> 
> Again, only if necessary.
> 
>>>> 
>>>> As to Jekyll:
>>>> 
>>>> Jekyll can equally use a YAML data file, so it is not a problem
>>>> changing to YAML.
>>>> 
>>>> At present the attic-test PoC includes a single JSON data file which
>>>> is processed in a plugin script that generates the individual page
>>>> data.
>>>> 
>>>> This works well (and it looks like BuildBot supports the use of Jekyll
>>>> plugin scripts - other sites such as GitHub may not)
>>>> 
>>>> But I think it would be better to have a separate YAML file per project.
>>>> 
>>>> Jekyll can process these as part of a collection.
>>>> This avoids the need to use a plugin to generate the pages.
>>>> I think it also makes it a bit more obvious what is going on (each
>>>> output file has an input file)
>>>> 
>>>> And the YAML body can contain arbitrary markup to be added to the
>>>> generated page.
>>>> This would make it easier to preserve the extra information present in
>>>> some of the existing xml files
>>>> 
>>>> A question:
>>>> On a tablet, would it be harder to maintain one file per project
>>>> rather than a single large file?
>> significantly ! that was one of the major reasons for my js solution.
>> 
> 
> I don't understand.
> Why is a single file easier?
> Surely each new retirement just needs to have a new file? Does it
> matter that there is no other data in it?
> 
> I tried adding more data from the XML files to see if I could
> reproduce all the information on the current pages.
> It's really difficult to ensure that all the quoting is done
> correctly; a single misplaced quote affects the entire file.
> Eclipse started having problems, but even in a plain text editor it
> was awkward to handle.
> 
>> but let us focus on the solution wanted by the community and what a single 
>> person needs.
>> 
>> rgds
>> jan i
>>>> 
>>>> i.e. instead of updating projects.json one would need to create/update
>>>> a projects/project.md file.
>>> 
>>> I have updated the attic-test tree with a YAML-based version:
>>> 
>>> https://svn.apache.org/repos/asf/attic/site-test/yaml
>>> 
>>> The yaml.sh script in the parent directory will create the output in docs3/.
>>> This should currently be identical to the output in docs2/ - apart
>>> from the date in feed.xml
>>> 
>>> If this looks like it will be suitable for use when working from
>>> tablets, I can tidy it up and start migrating some of the additional
>>> text from the xdocs/projects files
>>> 
>>> If not, please advise what needs to be done to make it possible to
>>> update the site from a tablet.

Re: Site generation ideas - JSON and Jekyll

[Jan Iversen]

Sent from my iPad

> On 19 Apr 2018, at 17:10, sebb  wrote:
> 
>> On 19 April 2018 at 13:27, sebb  wrote:
>> I have done some further investigation of using JSON and Jekyll.
>> 
>> I think JSON is not the best format for maintenance.
>> This is because it is messy including chunks of text (e.g. for
>> additional info on the project).
>> Also it does not allow any comments.
>> The format is rather strict, with lots of quotes needed, and brackets
>> and braces.
>> 
>> I think we should use YAML for the raw data, and (if necessary)
>> extract a subset into a JSON file for external consumption.
>> 
>> As to Jekyll:
>> 
>> Jekyll can equally use a YAML data file, so it is not a problem
>> changing to YAML.
>> 
>> At present the attic-test PoC includes a single JSON data file which
>> is processed in a plugin script that generates the individual page
>> data.
>> 
>> This works well (and it looks like BuildBot supports the use of Jekyll
>> plugin scripts - other sites such as GitHub may not)
>> 
>> But I think it would be better to have a separate YAML file per project.
>> 
>> Jekyll can process these as part of a collection.
>> This avoids the need to use a plugin to generate the pages.
>> I think it also makes it a bit more obvious what is going on (each
>> output file has an input file)
>> 
>> And the YAML body can contain arbitrary markup to be added to the
>> generated page.
>> This would make it easier to preserve the extra information present in
>> some of the existing xml files
>> 
>> A question:
>> On a tablet, would it be harder to maintain one file per project
>> rather than a single large file?
>> 
>> i.e. instead of updating projects.json one would need to create/update
>> a projects/project.md file.
> 
> I have updated the attic-test tree with a YAML-based version:
> 
> https://svn.apache.org/repos/asf/attic/site-test/yaml
is this a correct link, seems To miss yaml files and still contains a 
projects.json ?
rgds
jan i
> 
> The yaml.sh script in the parent directory will create the output in docs3/.
> This should currently be identical to the output in docs2/ - apart
> from the date in feed.xml
> 
> If this looks like it will be suitable for use when working from
> tablets, I can tidy it up and start migrating some of the additional
> text from the xdocs/projects files
> 
> If not, please advise what needs to be done to make it possible to
> update the site from a tablet.

Re: Site generation ideas - JSON and Jekyll

[Jan Iversen]

Sent from my iPad

> On 19 Apr 2018, at 17:10, sebb  wrote:
> 
>> On 19 April 2018 at 13:27, sebb  wrote:
>> I have done some further investigation of using JSON and Jekyll.
>> 
>> I think JSON is not the best format for maintenance.
>> This is because it is messy including chunks of text (e.g. for
>> additional info on the project).
>> Also it does not allow any comments.
>> The format is rather strict, with lots of quotes needed, and brackets
>> and braces.
>> 
>> I think we should use YAML for the raw data, and (if necessary)
>> extract a subset into a JSON file for external consumption.
Personally I think it is a mistake. json is rather simple, and are supported 
everywhere. Yaml on the other hand is less supported (e.g. looked for an online 
validator without success). Safari and xcode formats json nicely whereas yaml 
is viewed as raw text.

Why do we need comments in the file, it has not been needed until now, so let 
us not introduce “hidden” data.

but of course it is a matter of taste (just like js was).

extracting a json file from the yaml file seems to be overdoing it.
>> 
>> As to Jekyll:
>> 
>> Jekyll can equally use a YAML data file, so it is not a problem
>> changing to YAML.
>> 
>> At present the attic-test PoC includes a single JSON data file which
>> is processed in a plugin script that generates the individual page
>> data.
>> 
>> This works well (and it looks like BuildBot supports the use of Jekyll
>> plugin scripts - other sites such as GitHub may not)
>> 
>> But I think it would be better to have a separate YAML file per project.
>> 
>> Jekyll can process these as part of a collection.
>> This avoids the need to use a plugin to generate the pages.
>> I think it also makes it a bit more obvious what is going on (each
>> output file has an input file)
>> 
>> And the YAML body can contain arbitrary markup to be added to the
>> generated page.
>> This would make it easier to preserve the extra information present in
>> some of the existing xml files
>> 
>> A question:
>> On a tablet, would it be harder to maintain one file per project
>> rather than a single large file?
significantly ! that was one of the major reasons for my js solution.

but let us focus on the solution wanted by the community and what a single 
person needs.

rgds
jan i
>> 
>> i.e. instead of updating projects.json one would need to create/update
>> a projects/project.md file.
> 
> I have updated the attic-test tree with a YAML-based version:
> 
> https://svn.apache.org/repos/asf/attic/site-test/yaml
> 
> The yaml.sh script in the parent directory will create the output in docs3/.
> This should currently be identical to the output in docs2/ - apart
> from the date in feed.xml
> 
> If this looks like it will be suitable for use when working from
> tablets, I can tidy it up and start migrating some of the additional
> text from the xdocs/projects files
> 
> If not, please advise what needs to be done to make it possible to
> update the site from a tablet.

Re: Sample Jekyll implementation

[Jan Iversen]

> On 18 Apr 2018, at 03:04, sebb  wrote:
> 
> The SVN tree under:
> 
> https://svn.apache.org/repos/asf/attic/site-test
> 
> has a sample implementation of the site generation using Jekyll
> 
> This uses projects.json to create the list of projects for the RH side
> of pages as well as generating the individual pages.
> 
> It needs some tweaking and documenting.
> 
> For simplicity the page templates were left as HTML with minimal tweaks.
> In the longer term they should be converted to markdown for easier 
> maintenance.
> 
> The intention is that it will only be necessary to update
> projects.json (and create the flagged file) when retiring a project.
Surely the script could easily create the flagged file/directory, which would 
be one step less to do.
> 
> The output is currently directed to docs2/ to make it easy to compare
> the files with the originals which are in docs/.
> 
> AFAICT all the project-specific parts of the website are now derived
> from the JSON file.
What is the max delay between making a change and seeing the result ? (This one 
is critical since you are in front of a device, and basically wants to see the 
result without wait.

Maybe using a hook in svnpub would achieve that (having the build job to run in 
a high frequency raster, sounds very inefficient, considering that we typically 
only have 2-3 changes pr. year).

rgds
Jan I.

Re: New website proposal

[Jan Iversen]

Sent from my iPad

> On 17 Apr 2018, at 14:22, sebb <seb...@gmail.com> wrote:
> 
>> On 17 April 2018 at 13:04, Jan Iversen <jancasacon...@gmail.com> wrote:
>> 
>> 
>>> On 17 Apr 2018, at 13:55, sebb <seb...@gmail.com> wrote:
>>> 
>>> On 17 April 2018 at 11:59, Jan Iversen <j...@apache.org 
>>> <mailto:j...@apache.org>> wrote:
>>>> 
>>>> 
>>>> Sent from my iPad
>>>> 
>>>>>> On 17 Apr 2018, at 12:53, sebb <seb...@gmail.com> wrote:
>>>>>> 
>>>>>> On 15 April 2018 at 10:42, Jan Iversen <j...@apache.org> wrote:
>>>>>> 
>>>>>> 
>>>>>> Sent from my iPad
>>>>>> 
>>>>>>>> On 15 Apr 2018, at 11:37, sebb <seb...@gmail.com> wrote:
>>>>>>>> 
>>>>>>>> On 15 April 2018 at 10:03,  <j...@apache.org> wrote:
>>>>>>>> Hi
>>>>>>>> 
>>>>>>>> Please have a look at
>>>>>>>> http://attic.apache.org/test.html <http://attic.apache.org/test.html>
>>>>>>>> 
>>>>>>>> This is a “new” homepage. The only real new thing is that I got rid of 
>>>>>>>> “ant” and sidebar/project pages are generated in Javascript. This 
>>>>>>>> makes maintenance for me a lot easier.
>>>>>>> 
>>>>>>> It looks fine.
>>>>>>> However if Javascript is disabled, the sidebar is missing, but there
>>>>>>> is no indication that this might be so.
>>>>>>> 
>>>>>>>> As a side effect, we got a json list (in scripts/attic.js) of all 
>>>>>>>> projects, that might be useful for other purposes.
>>>>>>>> 
>>>>>>>> Please feel free to correct/amend especially the project list.
>>>>>>> 
>>>>>>>> If nobody objects I will put it in production later and cleanup the 
>>>>>>>> site.
>>>>>>> 
>>>>>>> I would rather see the JSON file used to generate a static site.
>>>>>> I agree on that, but with the limitations, the only solution would be a 
>>>>>> build job, that somehow triggers on svn commit. I have no experience 
>>>>>> with that but patches are welcome.
>>>>> 
>>>>> I have created INFRA-16384
>>>>> 
>>>>> The test.html page and script mostly work well, however AFAICT there
>>>>> is as yet no support for the existing URLs, e.g.
>>>>> http://attic.apache.org/projects/abdera.html. These must continue to
>>>>> be supported.
>>>>> 
>>>> why is that a demand, they have no function as such.
>>> 
>>> Because they are referenced elsewhere.
>>> For example oltu.apache.org <http://oltu.apache.org/> links to 
>>> https://attic.apache.org/projects/oltu.html 
>>> <https://attic.apache.org/projects/oltu.html>
>>> And the existing index page publishes links to the summary pages.
>>> 
>>> URLs should not be abandoned without good reason
>> Well easier maintenance is an excellent reason seen from my POW (as I am the 
>> one who have done all the retirements since I joined the project).
> 
> There are other ways to simplify maintenance without breaking URLs.
I did not find an easier way, but you are welcome to make another suggestion.
> 
>> And a simple .htaccess with a redirect to a common page can solve the link 
>> problem. Something which is a good idea, once we have activated the new 
>> setup.
> 
> However that would generate more URLs that have to be maintained if
> the site generation changes again.

how come? the .htaccess would have a wildcard redirecting to projects.html, 
with the original url as parameter that way it would be a oneliner extension of 
the existing script.and more importantly not something extra to do for each 
retirement.

rgds
jan i
> 
>>> .
>>> 
>>>>> I'm not sure that is easy to do with client-side Javascript.
>>>>> 
>>>>> [There is no code currently to customise the text "... choose to fork ACE 
>>>>> ...".]
>>>> Easy done, I simply overlooked it.
>>>>> 
>>>>> The JSON file needs to be extended to cater for customised project
>>>>> pages, such as
>>>>> http://attic.apache.org/projects/abdera.html 
>>>>> <http://attic.apache.org/projects/abdera.html>
>>>>> which has details of related projects. That should be easy enough.
>>>> I politely disagree to this, that page e.g. contains a link to dist which 
>>>> are cleaned.
>>> 
>>> No idea what you mean by the reference to dist and cleaning.
>>> 
>>> The page contains references to other projects which I think need to be 
>>> kept.
>> That is no problem, add the text you want kept to the json object in field 
>> “description”.
>> 
>>> 
>>>> I strongly believe it is a lot better that all project pages follow the 
>>>> same template, project individual information are contained on the old 
>>>> .apache.org <http://apache.org/> page.
>>>> 
>>>> And btw all newer project pages follow the template I made.
>>> 
>>> Some examples?
>> Oltu just to mention the very newest. In fact it is only very old ones who 
>> have an extra description and as mentioned above, if you have those simply 
>> add the text to json.
>> rgds
>> Jan I.
>>> 
>>>> rgds
>>>> jan i
>>>> 
>>>>> 
>>>>> Ideally the output from the new process should be compared with the
>>>>> existing output before switching over.
>>>>> 
>>>>>> rgds
>>>>>> jan i
>>>>>> 
>>>>>>> 
>>>>>>>> rgds
>>>>>>>> Jan I
>> 

Re: svn commit: r1829195 - /attic/site/docs/projects.json

[Jan Iversen]

> On 17 Apr 2018, at 14:00, sebb <seb...@gmail.com> wrote:
> 
> On 17 April 2018 at 12:03, Jan Iversen <j...@apache.org 
> <mailto:j...@apache.org>> wrote:
>> 
>> 
>> Sent from my iPad
>> 
>>> On 17 Apr 2018, at 12:57, sebb <seb...@gmail.com> wrote:
>>> 
>>>> On 15 April 2018 at 09:38,  <j...@apache.org> wrote:
>>>> Author: jani
>>>> Date: Sun Apr 15 08:38:21 2018
>>>> New Revision: 1829195
>>>> 
>>>> URL: http://svn.apache.org/viewvc?rev=1829195=rev
>>>> Log:
>>>> projects.json is moved in scripts/attic.js
>>>> this is due to a wish from Infra to have a static website
>>>> and no operations on the server side
>>> 
>>> Surely reading from projects.json would be allowed?
>>> 
>>> The site would still be static.
>> correct but projects.json will not be mantained with the current proposal, 
>> the data are kept in attic.js. On that basis I found it better to remove the 
>> file (so nobody expects it to be updated).
> 
> In which case the log message is somewhat misleading.
What is misleading about "projects.json is moved in scripts/attic.js” I believe 
it is a very factual accurate description.

Please do not forget projects.json only existed for 1-2 days during my 
experiments.

> 
> In any case, the data could still be kept in projects.json and the
> projects.js could read it.
> That would still solve the issue of only having a single source of the
> data, and it would allow the data to be used by other projects (which
> was another reason for having it in the first place).

No when using Javascript, we cannot reference another file easily. If you look 
at attic.js, that is the single source, and easy to read.

You are welcome to make a patch, that makes a http request inside the 
javascript to retrieve the file.

Please remember I made this change to make it easier to retire a project, NOT 
to provide additional services. If someone wants additional services, then 
patches are welcome.

> 
>> if and when a build will replace the javascript it would be nice to base it 
>> on projects.json, however so far I have not heard anybody volunteer to make 
>> that happen.
> 
> As noted above, that is a separate issue.
Seems linked to the existence of projects.json.

rgds
Jan I.
> 
>> rgds
>> jan I
>>> 
>>>> 
>>>> Removed:
>>>>   attic/site/docs/projects.json