Re: [cross-project-issues-dev] [ide-dev] Phasing in Error Reporting for Mars (was: Start collecting requests for Error Reporting v2)

[Marcel Bruch]

— Adding epp-dev to this discussion b/c the proposals below affect EPP packages 
— 

The amount of traffic is something no one can estimate yet. I think everyone 
feels a little bit uncomfortable with this situation. So here is a proposal I’d 
like to discuss publicly (although only a small subset of people may feel need 
to discuss this).


Markus (Knauer),
in case we’d need to disable error reporting because of too much traffic: is it 
possible for you to simply rebuild the packages with an additional preference? 
This preference would preconfigure the system to “don’t send error reports".

How quickly could we do that - in worst case?


Denis,
since JEE is the largest error reports provider, I can imagine to disable the 
error reporter for this package in the beginning. Disabling would mean that the 
user would have to go to the preferences page and enable it explicitly by 
changing a value in some combo box. 


Three options I’d feel comfortable with: 

1. The milquetoast option: Disable error reporting for JEE in the first days 
(via preferences as outlined above). If no outages occur, we can rebuild the 
JEE package and reenable it. We could also do the same for the Java package. 
With that we could slowly phase-in and see whether we can handle the traffic.

2. The daredevil option: Deactivate it in new EPP downloads as soon as we see 
that there is too much traffic. But then the sending clients are already out 
there...

3. I forgot option three. But I had one before I went to breakfast… Ah, here it 
is: The BOFH option: Use the firewall to block every, say, second access to the 
HTTP HEAD requests to the remote problems database. With that, create a 
controlled phasing in by selectively disabling half of the clients (randomly). 
Instead of blocking every second request, we may disable it for some hours of 
the days. Since this will disable the error reporter until restart we may 
temporarily disable the clients completely on the server-side w/o changing any 
EPP package.

What do you think?


> It appears to me that you didn't just write code; you've engineered a 
> solution.

Credits for this go to all people involved in various discussions over the past 
milestones and their feature requests. See bug 457115 [1] as one great example 
- but there are many more.



Denis, BTW:
can we get more bandwidth for dev.eclipse.org/recommenders? :-)


Marcel


[1] https://bugs.eclipse.org/bugs/show_bug.cgi?id=457115

> On 12 Jun 2015, at 20:26, Denis Roy  wrote:
> 
> It appears to me that you didn't just write code; you've engineered a 
> solution.
> 
> No need for crossed fingers.  I think we're in good shape.  Beer will be on 
> me at EclipseCon.
> 
> Have a nice weekend.
> 
> Denis
> 
> 
> 
> On 12/06/15 02:21 PM, Marcel Bruch wrote:
>> Denis,
>> 
>> there are four (4) + one (1) mechanisms in place that will / can limit the 
>> traffic to dev.eclipse.org/recommenders:
>> 
>> Level 1: A local, persistent, per-workspace history that remembers what was 
>> send before. If an error is logged that has the same fingerprint as an 
>> already sent report, it is skipped. This should prevent clients to send the 
>> same error over and over again.
>> 
>> Level 2: A “known errors database” that get’s downloaded from eclipse.org on 
>> IDE startup. If an error is logged in the IDE which was marked as “ignored” 
>> in the known-errors database, it won’t be send. No network traffic will 
>> happen. The server-side generates this database on demand and set’s every 
>> problem to ignore that was reported by more than 50 users.
>> 
>> Level 3: The “emergency” power OFF switch [1]. On startup, we check whether 
>> a certain system status URL is reachable. If that   fails, the system 
>> deactivates the reporter until next restart of Eclipse.
>> 
>> Level 4: If Eclipse is started with 
>> ‑Dorg.eclipse.epp.logging.aeri.ui.skipReports=true, no errors will be sent. 
>> EPP packages may add this into the eclipse.ini in worst case.
>> 
>> Level 5: I’m not sure what exactly would happen if the firewall blocks 
>> access the service. But I assume we catch every exception and log it 
>> gracefully as a warning. So this looks like Level 5 to me.
>> 
>> However, the traffic may still be large - especially in the first days. In 
>> that case I’m happy to pull the plug via Option 3 or Level 4 by rebuilding 
>> the EPP packages. Or 5 if you don’t see any other option. Or we start with 
>> just one EPP (e.g. Committers and or Java) package for the release and add 
>> more until we are sure it works. I think we have all options in your hands 
>> to control it on various levels.
>> 
>> 
>> Regarding Reporting to Bugzilla: Yes, the traffic goes to 
>> dev.eclipse.org/recommenders/* If this server is shut down, nothing can ever 
>> go to Bugzilla. 
>> 
>> I hope I'll keep my account for a while… still crossing fingers, though.
>> 
>> Best,
>> Marcel
>> 
>> 
>> [1] 
>> https://git.eclipse.org/c/epp/org.eclipse.epp.logging.git/tree/bundles/

Re: [cross-project-issues-dev] [ide-dev] Start collecting requests for Error Reporting v2

[Marcel Bruch]

I see your point. Having a cross-workspaces history was something we discussed 
lately but I had not enough time to think it through and implement it. The 
request was closed as won fix because there are several alternatives:

If 50 users reported the same error, it will be added to the remote error 
database as “ignorable log message” automatically.
On the server-ui, If you mark the problem as log message in the error 
reporter’s web ui, it will be added to the remote errors database as “ignorable 
log message” as well.
On the client-ui, If you check the “this is a log message” checkbox in the 
details dialog, we can use that info to add this problem to the “ignorable log 
message” list as well.
The latter hasn’t been implemented yet but since this is a server-side change, 
it can be implemented quickly. You may not want to wait for 50 other users, but 
you may be okay with option 2 or 3?


If you (or anyone else) thinks a cross-workspaces history is required, please 
reopen [1] and add yourself to cc. If a reasonable amount of committers think 
this is required, we can rethink the wontfix for SR1.


Thanks,
Marcel

https://bugs.eclipse.org/bugs/show_bug.cgi?id=468929 




> On 12 Jun 2015, at 20:54, Torkild Ulvøy Resheim  wrote:
> 
> Hi Marcel,
> 
> This is looking good. But I’m a bit concerned about “Level 1” - If you have a 
> dozen workspaces, I don’t think I’m the only one, you will still produce 
> excessive error reports. Also I do keep hitting the same error again and 
> again, but choose to not send (because I know the reason). However I’m pretty 
> sure I have reported it in the past. Anyway, the code I’m running is on Mylyn 
> snapshot builds, which I guess only a few is executing. Could that be the 
> reason why it’s not ignored?
> 
> Best regards,
> Torkild
>> 12. jun. 2015 kl. 20.21 skrev Marcel Bruch :
>> 
>> Denis,
>> 
>> there are four (4) + one (1) mechanisms in place that will / can limit the 
>> traffic to dev.eclipse.org/recommenders:
>> 
>> Level 1: A local, persistent, per-workspace history that remembers what was 
>> send before. If an error is logged that has the same fingerprint as an 
>> already sent report, it is skipped. This should prevent clients to send the 
>> same error over and over again.
>> 
>> Level 2: A “known errors database” that get’s downloaded from eclipse.org on 
>> IDE startup. If an error is logged in the IDE which was marked as “ignored” 
>> in the known-errors database, it won’t be send. No network traffic will 
>> happen. The server-side generates this database on demand and set’s every 
>> problem to ignore that was reported by more than 50 users.
>> 
>> Level 3: The “emergency” power OFF switch [1]. On startup, we check whether 
>> a certain system status URL is reachable. If that fails, the system 
>> deactivates the reporter until next restart of Eclipse.
>> 
>> Level 4: If Eclipse is started with 
>> ‑Dorg.eclipse.epp.logging.aeri.ui.skipReports=true, no errors will be sent. 
>> EPP packages may add this into the eclipse.ini in worst case.
>> 
>> Level 5: I’m not sure what exactly would happen if the firewall blocks 
>> access the service. But I assume we catch every exception and log it 
>> gracefully as a warning. So this looks like Level 5 to me.
>> 
>> However, the traffic may still be large - especially in the first days. In 
>> that case I’m happy to pull the plug via Option 3 or Level 4 by rebuilding 
>> the EPP packages. Or 5 if you don’t see any other option. Or we start with 
>> just one EPP (e.g. Committers and or Java) package for the release and add 
>> more until we are sure it works. I think we have all options in your hands 
>> to control it on various levels.
>> 
>> 
>> Regarding Reporting to Bugzilla: Yes, the traffic goes to 
>> dev.eclipse.org/recommenders/* If this server is shut down, nothing can ever 
>> go to Bugzilla.
>> 
>> I hope I'll keep my account for a while… still crossing fingers, though.
>> 
>> Best,
>> Marcel
>> 
>> 
>> [1] 
>> https://git.eclipse.org/c/epp/org.eclipse.epp.logging.git/tree/bundles/org.eclipse.epp.logging.aeri.ui/src/org/eclipse/epp/internal/logging/aeri/ui/log/CheckServerAvailabilityJob.java#n51
>> 
>> 
>>> On 12 Jun 2015, at 19:57, Denis Roy  wrote:
>>> 
>>> 
> 
> On 06/12/2015 01:15 AM, Marcel Bruch wrote:
>> We are now looking forward to the first two weeks of the Mars release
>> and cross fingers that we don’t get flooded.
> 
> Marcel,
> 
> Do we have an OFF switch somewhere so that we can turn these things off 
> if we see we're going to get flooded?
 
 Have we...?
 Do you...?
>>> 
>>> 
>>> I have a big "OFF" switch called a firewall, but I'm not sure how that will 
>>> manifest itself in Eclipse if the error reporter cannot connect to its home 
>>> site.
>>> 
>>> Also, just so I understand, the 1000's of daily reports  (which could 
>>> become 100,000's of daily reports on June 25) are all repo

[cross-project-issues-dev] Mars Final Daze

[David M Williams]

Every release, we provide a document about the details leading up to the 
final, official release. It is long and wordy a) because I wrote it :) and 
b) the long version is intended primarily for those new to this whole 
thing, and there are details in there that are intended to be educational, 
as wall as map out the plan for the final days. 

https://wiki.eclipse.org/Mars/Final_Daze

For the rest of you, those that are already very familiar with the 
process, the basics are below as reminders. 
For everyone, be sure to ask, if there are any questions. 

= = = = = 
For most committers (or, specifically, release engineers, or project 
leads) the following are the main steps. 
1.  Clean up old builds on downloads and move previous releases to 
archives site. 
2.  Provide data for Infocenter docs, for help.eclipse.org (bug 469456
). 
3.  Put your final bits in their final resting places, with their 
final names, early -- during quiet week -- but do not advertise them or 
make "visible" to the world. Be sure to change, correct, or add metadata 
-- such as download.php mirror URLs -- so they are correct for final 
location and names. 
4.  On official release day, Wednesday, June 24, check cross-project 
list approximately 10 AM (Eastern) to make sure there is no "Wait! Stop 
ship!" message. Once you see a "Go" message, you're free to advertise your 
release and make visible to the world. (And, while your thinking of it, 
just as well update Foundation's metadata to change "planned" to 
"completed", etc. 
5.  Keep an eye open for a few hours to make sure no reports of "bad 
things are happening", but otherwise Blog, Tweet, Celebrate! 

= = = = = 

Thanks all! 
___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe from 
this list, visit
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev

Re: [cross-project-issues-dev] [ide-dev] Start collecting requests for Error Reporting v2

[Torkild Ulvøy Resheim]

Hi Marcel,

This is looking good. But I’m a bit concerned about “Level 1” - If you have a 
dozen workspaces, I don’t think I’m the only one, you will still produce 
excessive error reports. Also I do keep hitting the same error again and again, 
but choose to not send (because I know the reason). However I’m pretty sure I 
have reported it in the past. Anyway, the code I’m running is on Mylyn snapshot 
builds, which I guess only a few is executing. Could that be the reason why 
it’s not ignored?

Best regards,
Torkild
> 12. jun. 2015 kl. 20.21 skrev Marcel Bruch :
> 
> Denis,
> 
> there are four (4) + one (1) mechanisms in place that will / can limit the 
> traffic to dev.eclipse.org/recommenders:
> 
> Level 1: A local, persistent, per-workspace history that remembers what was 
> send before. If an error is logged that has the same fingerprint as an 
> already sent report, it is skipped. This should prevent clients to send the 
> same error over and over again.
> 
> Level 2: A “known errors database” that get’s downloaded from eclipse.org on 
> IDE startup. If an error is logged in the IDE which was marked as “ignored” 
> in the known-errors database, it won’t be send. No network traffic will 
> happen. The server-side generates this database on demand and set’s every 
> problem to ignore that was reported by more than 50 users.
> 
> Level 3: The “emergency” power OFF switch [1]. On startup, we check whether a 
> certain system status URL is reachable. If that fails, the system deactivates 
> the reporter until next restart of Eclipse.
> 
> Level 4: If Eclipse is started with 
> ‑Dorg.eclipse.epp.logging.aeri.ui.skipReports=true, no errors will be sent. 
> EPP packages may add this into the eclipse.ini in worst case.
> 
> Level 5: I’m not sure what exactly would happen if the firewall blocks access 
> the service. But I assume we catch every exception and log it gracefully as a 
> warning. So this looks like Level 5 to me.
> 
> However, the traffic may still be large - especially in the first days. In 
> that case I’m happy to pull the plug via Option 3 or Level 4 by rebuilding 
> the EPP packages. Or 5 if you don’t see any other option. Or we start with 
> just one EPP (e.g. Committers and or Java) package for the release and add 
> more until we are sure it works. I think we have all options in your hands to 
> control it on various levels.
> 
> 
> Regarding Reporting to Bugzilla: Yes, the traffic goes to 
> dev.eclipse.org/recommenders/* If this server is shut down, nothing can ever 
> go to Bugzilla.
> 
> I hope I'll keep my account for a while… still crossing fingers, though.
> 
> Best,
> Marcel
> 
> 
> [1] 
> https://git.eclipse.org/c/epp/org.eclipse.epp.logging.git/tree/bundles/org.eclipse.epp.logging.aeri.ui/src/org/eclipse/epp/internal/logging/aeri/ui/log/CheckServerAvailabilityJob.java#n51
> 
> 
>> On 12 Jun 2015, at 19:57, Denis Roy  wrote:
>> 
>> 
 
 On 06/12/2015 01:15 AM, Marcel Bruch wrote:
> We are now looking forward to the first two weeks of the Mars release
> and cross fingers that we don’t get flooded.
 
 Marcel,
 
 Do we have an OFF switch somewhere so that we can turn these things off if 
 we see we're going to get flooded?
>>> 
>>> Have we...?
>>> Do you...?
>> 
>> 
>> I have a big "OFF" switch called a firewall, but I'm not sure how that will 
>> manifest itself in Eclipse if the error reporter cannot connect to its home 
>> site.
>> 
>> Also, just so I understand, the 1000's of daily reports  (which could become 
>> 100,000's of daily reports on June 25) are all reports against the 
>> recommenders server, right?  Not Bugzilla bugs, right? The latter could see 
>> the OFF switch extended to your user account :)
>> 
>> I will be at ECE to collect on any wrongdoings you do to your fellow 
>> committers.
>> 
>> In all seriousness, let me know if there's anything I can do to make sure 
>> we're prepared for what is about to come.
>> 
>> 
>> Denis
>> ___
>> cross-project-issues-dev mailing list
>> cross-project-issues-dev@eclipse.org
>> To change your delivery options, retrieve your password, or unsubscribe from 
>> this list, visit
>> https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
> 
> --
> Codetrails GmbH
> The knowledge transfer company
> 
> Robert-Bosch-Str. 7, 64293 Darmstadt
> Phone: +49-6151-276-7092
> Mobile: +49-179-131-7721
> http://www.codetrails.com/
> 
> Managing Director: Dr. Marcel Bruch
> Handelsregister: Darmstadt HRB 91940
> 
> ___
> cross-project-issues-dev mailing list
> cross-project-issues-dev@eclipse.org
> To change your delivery options, retrieve your password, or unsubscribe from 
> this list, visit
> https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev

--
Torkild Ulvøy Resheim
Consultant / Eclipse Committer / Senior Software Developer
Itema AS - http://itema.no




signature.asc
Description: Message signed 

Re: [cross-project-issues-dev] [ide-dev] Start collecting requests for Error Reporting v2

[Denis Roy]

It appears to me that you didn't just write code; you've engineered a 
solution.


No need for crossed fingers.  I think we're in good shape.  Beer will be 
on me at EclipseCon.


Have a nice weekend.

Denis



On 12/06/15 02:21 PM, Marcel Bruch wrote:

Denis,

there are four (4) + one (1) mechanisms in place that will / can limit 
the traffic to dev.eclipse.org/recommenders 
:


Level 1: A local, persistent, per-workspace history that remembers 
what was send before. If an error is logged that has the same 
fingerprint as an already sent report, it is skipped. This should 
prevent clients to send the same error over and over again.


Level 2: A “known errors database” that get’s downloaded 
from eclipse.org on IDE startup. If an error is logged in the IDE 
which was marked as “ignored” in the known-errors database, it won’t 
be send. No network traffic will happen. The server-side generates 
this database on demand and set’s every problem to ignore that was 
reported by more than 50 users.


Level 3: The “emergency” power OFF switch [1]. On startup, we check 
whether a certain system status URL is reachable. If that fails, the 
system deactivates the reporter until next restart of Eclipse.


Level 4: If Eclipse is started 
with ‑Dorg.eclipse.epp.logging.aeri.ui.skipReports=true, no errors 
will be sent. EPP packages may add this into the eclipse.ini in worst 
case.


Level 5: I’m not sure what exactly would happen if the firewall blocks 
access the service. But I assume we catch every exception and log it 
gracefully as a warning. So this looks like Level 5 to me.


However, the traffic may still be large - especially in the first 
days. In that case I’m happy to pull the plug via Option 3 or Level 4 
by rebuilding the EPP packages. Or 5 if you don’t see any other 
option. Or we start with just one EPP (e.g. Committers and or Java) 
package for the release and add more until we are sure it works. I 
think we have all options in your hands to control it on various levels.



Regarding Reporting to Bugzilla: Yes, the traffic goes to 
dev.eclipse.org/recommenders/* 
 If this server is shut down, 
nothing can ever go to Bugzilla.


I hope I'll keep my account for a while… still crossing fingers, though.

Best,
Marcel


[1] 
https://git.eclipse.org/c/epp/org.eclipse.epp.logging.git/tree/bundles/org.eclipse.epp.logging.aeri.ui/src/org/eclipse/epp/internal/logging/aeri/ui/log/CheckServerAvailabilityJob.java#n51



On 12 Jun 2015, at 19:57, Denis Roy  wrote:




On 06/12/2015 01:15 AM, Marcel Bruch wrote:

We are now looking forward to the first two weeks of the Mars release
and cross fingers that we don’t get flooded.


Marcel,

Do we have an OFF switch somewhere so that we can turn these things 
off if we see we're going to get flooded?


Have we...?
Do you...?



I have a big "OFF" switch called a firewall, but I'm not sure how 
that will manifest itself in Eclipse if the error reporter cannot 
connect to its home site.


Also, just so I understand, the 1000's of daily reports  (which could 
become 100,000's of daily reports on June 25) are all reports against 
the recommenders server, right?  Not Bugzilla bugs, right? The latter 
could see the OFF switch extended to your user account :)


I will be at ECE to collect on any wrongdoings you do to your fellow 
committers.


In all seriousness, let me know if there's anything I can do to make 
sure we're prepared for what is about to come.



Denis


___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe from 
this list, visit
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev

Re: [cross-project-issues-dev] [ide-dev] Start collecting requests for Error Reporting v2

[Marcel Bruch]

Denis,

there are four (4) + one (1) mechanisms in place that will / can limit the 
traffic to dev.eclipse.org/recommenders:

Level 1: A local, persistent, per-workspace history that remembers what was 
send before. If an error is logged that has the same fingerprint as an already 
sent report, it is skipped. This should prevent clients to send the same error 
over and over again.

Level 2: A “known errors database” that get’s downloaded from eclipse.org on 
IDE startup. If an error is logged in the IDE which was marked as “ignored” in 
the known-errors database, it won’t be send. No network traffic will happen. 
The server-side generates this database on demand and set’s every problem to 
ignore that was reported by more than 50 users.

Level 3: The “emergency” power OFF switch [1]. On startup, we check whether a 
certain system status URL is reachable. If that fails, the system deactivates 
the reporter until next restart of Eclipse.

Level 4: If Eclipse is started with 
‑Dorg.eclipse.epp.logging.aeri.ui.skipReports=true, no errors will be sent. EPP 
packages may add this into the eclipse.ini in worst case.

Level 5: I’m not sure what exactly would happen if the firewall blocks access 
the service. But I assume we catch every exception and log it gracefully as a 
warning. So this looks like Level 5 to me.

However, the traffic may still be large - especially in the first days. In that 
case I’m happy to pull the plug via Option 3 or Level 4 by rebuilding the EPP 
packages. Or 5 if you don’t see any other option. Or we start with just one EPP 
(e.g. Committers and or Java) package for the release and add more until we are 
sure it works. I think we have all options in your hands to control it on 
various levels.


Regarding Reporting to Bugzilla: Yes, the traffic goes to 
dev.eclipse.org/recommenders/*  If this 
server is shut down, nothing can ever go to Bugzilla. 

I hope I'll keep my account for a while… still crossing fingers, though.

Best,
Marcel


[1] 
https://git.eclipse.org/c/epp/org.eclipse.epp.logging.git/tree/bundles/org.eclipse.epp.logging.aeri.ui/src/org/eclipse/epp/internal/logging/aeri/ui/log/CheckServerAvailabilityJob.java#n51


> On 12 Jun 2015, at 19:57, Denis Roy  wrote:
> 
> 
>>> 
>>> On 06/12/2015 01:15 AM, Marcel Bruch wrote:
 We are now looking forward to the first two weeks of the Mars release
 and cross fingers that we don’t get flooded.
>>> 
>>> Marcel,
>>> 
>>> Do we have an OFF switch somewhere so that we can turn these things off if 
>>> we see we're going to get flooded?
>> 
>> Have we...?
>> Do you...?
> 
> 
> I have a big "OFF" switch called a firewall, but I'm not sure how that will 
> manifest itself in Eclipse if the error reporter cannot connect to its home 
> site.
> 
> Also, just so I understand, the 1000's of daily reports  (which could become 
> 100,000's of daily reports on June 25) are all reports against the 
> recommenders server, right?  Not Bugzilla bugs, right? The latter could see 
> the OFF switch extended to your user account :)
> 
> I will be at ECE to collect on any wrongdoings you do to your fellow 
> committers.
> 
> In all seriousness, let me know if there's anything I can do to make sure 
> we're prepared for what is about to come.
> 
> 
> Denis
> ___
> cross-project-issues-dev mailing list
> cross-project-issues-dev@eclipse.org
> To change your delivery options, retrieve your password, or unsubscribe from 
> this list, visit
> https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev

-- 
Codetrails GmbH
The knowledge transfer company

Robert-Bosch-Str. 7, 64293 Darmstadt
Phone: +49-6151-276-7092
Mobile: +49-179-131-7721
http://www.codetrails.com/

Managing Director: Dr. Marcel Bruch
Handelsregister: Darmstadt HRB 91940

___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe from 
this list, visit
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev

Re: [cross-project-issues-dev] [ide-dev] Start collecting requests for Error Reporting v2

[Denis Roy]

On 06/12/2015 01:15 AM, Marcel Bruch wrote:

We are now looking forward to the first two weeks of the Mars release
and cross fingers that we don’t get flooded.


Marcel,

Do we have an OFF switch somewhere so that we can turn these things 
off if we see we're going to get flooded?


Have we...?
Do you...?



I have a big "OFF" switch called a firewall, but I'm not sure how that 
will manifest itself in Eclipse if the error reporter cannot connect to 
its home site.


Also, just so I understand, the 1000's of daily reports  (which could 
become 100,000's of daily reports on June 25) are all reports against 
the recommenders server, right?  Not Bugzilla bugs, right? The latter 
could see the OFF switch extended to your user account :)


I will be at ECE to collect on any wrongdoings you do to your fellow 
committers.


In all seriousness, let me know if there's anything I can do to make 
sure we're prepared for what is about to come.



Denis
___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe from 
this list, visit
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev

Re: [cross-project-issues-dev] [ide-dev] Start collecting requests for Error Reporting v2

[Marcel Bruch]

> On 12 Jun 2015, at 15:03, Denis Roy  wrote:
> 
> 
> On 06/12/2015 01:15 AM, Marcel Bruch wrote:
>> We are now looking forward to the first two weeks of the Mars release
>> and cross fingers that we don’t get flooded.
> 
> Marcel,
> 
> Do we have an OFF switch somewhere so that we can turn these things off if we 
> see we're going to get flooded?

Have we...? 
Do you...?
















I have 
https://git.eclipse.org/c/epp/org.eclipse.epp.logging.git/tree/bundles/org.eclipse.epp.logging.aeri.ui/src/org/eclipse/epp/internal/logging/aeri/ui/log/CheckServerAvailabilityJob.java#n51
 



> I don't have much faith in your crossed fingers, and if we _do_ get flooded, 
> it's going to cost you a fortune in beer at EclipseCon.

If a head request to 
https://dev.eclipse.org/recommenders/community/confess/problems.zip 
 fails, 
the system deactivates the reporter for 24 hours. In theory. But who knows … 
I’m still crossing fingers… 

Marcel

> 
> D.
> ___
> cross-project-issues-dev mailing list
> cross-project-issues-dev@eclipse.org
> To change your delivery options, retrieve your password, or unsubscribe from 
> this list, visit
> https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev

-- 
Codetrails GmbH
The knowledge transfer company

Robert-Bosch-Str. 7, 64293 Darmstadt
Phone: +49-6151-276-7092
Mobile: +49-179-131-7721
http://www.codetrails.com/

Managing Director: Dr. Marcel Bruch
Handelsregister: Darmstadt HRB 91940

___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe from 
this list, visit
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev

Re: [cross-project-issues-dev] [ide-dev] Start collecting requests for Error Reporting v2

[Marcel Bruch]

> cost you a fortune in beer at EclipseCon


Two questions: 

1. Which one (EclipseCon) will you attend? 
2. How long does your short-term memory last?




> On 12 Jun 2015, at 15:03, Denis Roy  wrote:
> 
> 
> On 06/12/2015 01:15 AM, Marcel Bruch wrote:
>> We are now looking forward to the first two weeks of the Mars release
>> and cross fingers that we don’t get flooded.
> 
> Marcel,
> 
> Do we have an OFF switch somewhere so that we can turn these things off if we 
> see we're going to get flooded?
> 
> I don't have much faith in your crossed fingers, and if we _do_ get flooded, 
> it's going to cost you a fortune in beer at EclipseCon.
> 
> D.
> ___
> cross-project-issues-dev mailing list
> cross-project-issues-dev@eclipse.org
> To change your delivery options, retrieve your password, or unsubscribe from 
> this list, visit
> https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev

-- 
Codetrails GmbH
The knowledge transfer company

Robert-Bosch-Str. 7, 64293 Darmstadt
Phone: +49-6151-276-7092
Mobile: +49-179-131-7721
http://www.codetrails.com/

Managing Director: Dr. Marcel Bruch
Handelsregister: Darmstadt HRB 91940

___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe from 
this list, visit
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev

Re: [cross-project-issues-dev] [ide-dev] Start collecting requests for Error Reporting v2

[Jay Jay Billings]

If it is a matter of beer...

>it's going to cost you a fortune in beer >at EclipseCon.

I vote for no off switch! ;)

Jay
___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe from 
this list, visit
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev

Re: [cross-project-issues-dev] [ide-dev] Start collecting requests for Error Reporting v2

[Denis Roy]

On 06/12/2015 01:15 AM, Marcel Bruch wrote:

We are now looking forward to the first two weeks of the Mars release
and cross fingers that we don’t get flooded.


Marcel,

Do we have an OFF switch somewhere so that we can turn these things off 
if we see we're going to get flooded?


I don't have much faith in your crossed fingers, and if we _do_ get 
flooded, it's going to cost you a fortune in beer at EclipseCon.


D.
___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe from 
this list, visit
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev