Re: [cross-project-issues-dev] ACTION REQUIRED from RAP / REDDEER / WEBTOOLS - respin of Eclipse Platform RC2a and the status on removing slf4j 2.0.0 alpha
I believe the issue with Jetty is resolved and we are looking to make another release for you folks shortly. -- jesse mcconnell jesse.mcconn...@gmail.com On Wed, Jun 9, 2021 at 3:15 PM Ondrej Dockal wrote: > Unfortunately, I am still not able to pass aggregator validation, this > time it is jetty complaining about missing org.slf4j [2.0.0,3.0.0) as can > be seen in [1]. I am not really sure about what I can do about it from my > side. There is a reopened bugzilla [2] and PR on jetty project to handle > this bundle dep. range for org.slf4j, but who knows when it will be fixed. > > I am trying in a meantime to omit any bundles from my plugins in release, > not sure if that can help. > > [1]: > https://ci.eclipse.org/simrel/job/simrel.runaggregator.VALIDATE.gerrit/2274/console > [2]: https://bugs.eclipse.org/bugs/show_bug.cgi?id=573454 > > On Wed, Jun 9, 2021 at 6:47 PM Jonah Graham > wrote: > >> Ondrej, >> >> I think your analysis is correct. RAP tools publishes jetty to its p2 >> site, but does not include the slf4j so just happened to pick it up from >> Platform until they removed it, now it picks it up from Reddeer. >> >> Markus, >> >> Not sure what the issues with removing slf4j 2.0.0 alpha is. Do you mean >> that RAP references it in too many places? If you mean too many projects, >> then you might be right, but I hope not. Hopefully with rap, wtp, and >> reddeer making their update we can get rid of it from the 2021-06 release >> entirely. >> >> Nitin, >> >> I think the RC2 contribution of WTP only validated because Reddeer is >> still publishing slf4j 2.0. >> >> Jonah >> ~~~ >> Jonah Graham >> Kichwa Coders >> www.kichwacoders.com >> >> >> On Wed, 9 Jun 2021 at 10:55, Ondrej Dockal wrote: >> >>> Hi Folks, >>> >>> Gerrit aggregator validation job [1] is failing for me due to RAP >>> requiring jetty 10.0.3 and that transitively requires slf4j in 2.0.0 +, I >>> guess I have to wait for you to update jetty deps to make it work, right? >>> >>> [1]: >>> https://ci.eclipse.org/simrel/job/simrel.runaggregator.VALIDATE.gerrit/2247/ >>> >>> On Wed, Jun 9, 2021 at 4:50 PM Markus Knauer >>> wrote: >>> >>>> Switching to Jetty 10.0.4 seems to be doable for RAP, especially >>>> because the Webtools team was so kind to give us access to their p2 >>>> repository for building. I will try that now. >>>> >>>> slf4j 2.0.0 is a different issue. It was required until today, and is >>>> now referenced in too many places. I am not sure if it will be possible to >>>> remove it in a quick and safe manner in a last build towards RC2. >>>> >>>> Thanks >>>> Markus >>>> >>>> On Wed, 9 Jun 2021 at 15:32, Jonah Graham >>>> wrote: >>>> >>>>> Hi folks, >>>>> >>>>> Eclipse Platform have successfully updated their contribution* >>>>> (Thanks Sravan, Thomas, Jetty team and anyone else who got this done that >>>>> I >>>>> don't know about!) *to SimRel to their RC2a build and that means that >>>>> Eclipse Platform now no longer contributes the alpha 2.0.0 version. >>>>> >>>>> However other projects still are contributing the bundle to simrel >>>>> because they are republishing parts or all of Platform RC2 or earlier or >>>>> jetty 10 from other sources. >>>>> >>>>> Can both *reddeer *and *rap *projects look at their contribution to >>>>> ensure that they are not contributing slf4j 2.0.0 alpha to the simrel >>>>> please. >>>>> >>>>> As Platform have updated to Jetty 10.0.4, I also see that *rap* has >>>>> Jetty 10.0.3 contributed to simrel and *webtools* has 10.0.2 >>>>> contributed to webtools. *All three versions* are in the simrel >>>>> output repo! >>>>> >>>>> Thank you, >>>>> Jonah >>>>> >>>>> ~~~ >>>>> Jonah Graham >>>>> Kichwa Coders >>>>> www.kichwacoders.com >>>>> ___ >>>>> cross-project-issues-dev mailing list >>>>> cross-project-issues-dev@eclipse.org >>>>> To unsubscribe from this list, visit >>>>> https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev >>>&g
Re: [cross-project-issues-dev] FW: Re: [eclipse-ide-wg] [eclipse-pmc] Fwd: IMHO serious issues in the Eclipse Java IDE 2021-06 M3
Open an issue with the project and we can discuss there, not sure the right balance to strike for that value, thus far we have just told concerned parties to simply use the previous slf4j versions. https://github.com/eclipse/jetty.project/issues cheers, Jesse -- jesse mcconnell jesse.mcconn...@gmail.com On Thu, Jun 3, 2021 at 7:30 AM Thomas Watson wrote: > The issue is now the Import-Package for the jetty bundles have a > non-optional import on the slf4j package with a range forcing it to be 2.0: > > For example: > https://search.maven.org/artifact/org.eclipse.jetty/jetty-io/10.0.2/jar > > > Has this import: > > org.slf4j;version="[2.0.0,3)" > > If this either had a range that included 1.x, or was made an optional > import then it would allow us to keep using the current stable version of > slf4j (the latest 1.x version). As far as I can tell slf4j 2.0 is has not > released a final version. It seems to have been in a perpetual alpha state > since 2019. > > Tom > > > > > - Original message - > From: Jesse McConnell > Sent by: "cross-project-issues-dev" < > cross-project-issues-dev-boun...@eclipse.org> > To: Cross project issues > Cc: > Subject: [EXTERNAL] Re: [cross-project-issues-dev] FW: Re: > [eclipse-ide-wg] [eclipse-pmc] Fwd: IMHO serious issues in the Eclipse Java > IDE 2021-06 M3 > Date: Thu, Jun 3, 2021 5:30 AM > > From the jetty perspective, you don't need to use a slf4j version 2 unless > you're making use of the JPMS features. I believe you should be fine just > running with the older version of slf4j. > > On Wed, Jun 2, 2021, 05:58 Sravan K Lakkimsetti > wrote: > > Slf4j version 2 dependency is coming from jetty 10. At platform we are > consuming jetty. This is where the slf4j.api version 2 is coming from. > Since Jetty stopped building p2 repositories we built jetty p2 repositories > with bare minimum components that are required for platform. > > > > We tried to use update Jetty around 2021-03 M3. But we thought this > upgrade will be disruptive so we postponed to 2021-06 M1. > > > > We added the feature announcement in N > https://www.eclipse.org/eclipse/news/4.20/platform_isv.php#jetty-10-update > > We also sent a note because of jetty upgrade there are conflicts in simrel > to crossproject-dev list. There was a considerable discussion on this topic. > > > > I am just listing what happened with update Jetty 10. Now we cannot go > back to older version of slf4j that means downgrading Jetty. Now what > should be the way forward? > > > > -Sravan > > > > *From:* Mickael Istria > *Sent:* 02 June 2021 14:49 > *To:* eclipse-...@eclipse.org > *Cc:* Discussions on Eclipse IDE Working Group > > *Subject:* [EXTERNAL] Re: [eclipse-ide-wg] [eclipse-pmc] Fwd: > [cross-project-issues-dev] IMHO serious issues in the Eclipse Java IDE > 2021-06 M3 > > > > Thanks for raising this issue folks. About Orbit or not, I fail at seeing > what would that change: if slf4j 2.0 -which is a requirement- were in > Orbit, how would that have prevented this issue in m2e from happening? > > > Thanks for raising this issue folks. > > About Orbit or not, I fail at seeing what would that change: if slf4j 2.0 > -which is a requirement- were in Orbit, how would that have prevented this > issue in m2e from happening? > ___ > cross-project-issues-dev mailing list > cross-project-issues-dev@eclipse.org > To unsubscribe from this list, visit > https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev > > ___ > cross-project-issues-dev mailing list > cross-project-issues-dev@eclipse.org > To unsubscribe from this list, visit > https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev > > > > > ___ > cross-project-issues-dev mailing list > cross-project-issues-dev@eclipse.org > To unsubscribe from this list, visit > https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev > ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev
Re: [cross-project-issues-dev] FW: Re: [eclipse-ide-wg] [eclipse-pmc] Fwd: IMHO serious issues in the Eclipse Java IDE 2021-06 M3
>From the jetty perspective, you don't need to use a slf4j version 2 unless you're making use of the JPMS features. I believe you should be fine just running with the older version of slf4j. On Wed, Jun 2, 2021, 05:58 Sravan K Lakkimsetti wrote: > Slf4j version 2 dependency is coming from jetty 10. At platform we are > consuming jetty. This is where the slf4j.api version 2 is coming from. > Since Jetty stopped building p2 repositories we built jetty p2 repositories > with bare minimum components that are required for platform. > > > > We tried to use update Jetty around 2021-03 M3. But we thought this > upgrade will be disruptive so we postponed to 2021-06 M1. > > > > We added the feature announcement in N > https://www.eclipse.org/eclipse/news/4.20/platform_isv.php#jetty-10-update > > We also sent a note because of jetty upgrade there are conflicts in simrel > to crossproject-dev list. There was a considerable discussion on this topic. > > > > I am just listing what happened with update Jetty 10. Now we cannot go > back to older version of slf4j that means downgrading Jetty. Now what > should be the way forward? > > > > -Sravan > > > > *From:* Mickael Istria > *Sent:* 02 June 2021 14:49 > *To:* eclipse-...@eclipse.org > *Cc:* Discussions on Eclipse IDE Working Group > > *Subject:* [EXTERNAL] Re: [eclipse-ide-wg] [eclipse-pmc] Fwd: > [cross-project-issues-dev] IMHO serious issues in the Eclipse Java IDE > 2021-06 M3 > > > > Thanks for raising this issue folks. About Orbit or not, I fail at seeing > what would that change: if slf4j 2.0 -which is a requirement- were in > Orbit, how would that have prevented this issue in m2e from happening? > > > Thanks for raising this issue folks. > > About Orbit or not, I fail at seeing what would that change: if slf4j 2.0 > -which is a requirement- were in Orbit, how would that have prevented this > issue in m2e from happening? > > ___ > cross-project-issues-dev mailing list > cross-project-issues-dev@eclipse.org > To unsubscribe from this list, visit > https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev > ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev
Re: [cross-project-issues-dev] The "new user -> ECA -> signed-off by" workflow is broken
Denis, Is that a hard and fast rule everywhere? Because I get forced to sign on the jetty.git website repository on git.eclipse.org Jesse -- jesse mcconnell jesse.mcconn...@gmail.com On Mon, Mar 15, 2021 at 2:09 PM Denis Roy wrote: > As per the bug, Signed-off-by is NOT required for committers on that > project. You are a committer on that project. > > s/Yay/Boo/ > > > > On 2021-03-15 3:05 p.m., Wim Jongman wrote: > > I have seen that the BIRT project does NOT require the dreaded "signed-off > by:" footer. Yay, maybe it is already working: > > e.g. https://github.com/eclipse/birt/pull/616 > > On Thu, Mar 4, 2021 at 5:20 PM Gunnar Wagenknecht > wrote: > >> > On Mar 4, 2021, at 16:47, Jesse McConnell >> wrote: >> > >> > I added an action item to discuss on AC call next week. >> >> Thanks Jesse. I also added the other two items in the thread to the list. >> >> For visibility, the bug (with further details) around "Signed-off by" is: >> https://bugs.eclipse.org/558653 >> >> This requires change in IP policy. Nothing the AC can decide but we can >> capture our wish in our meeting notes. >> >> For the others I am collecting ideas (preferably bug numbers that should >> be prioritized) that we can give to Denis & team. >> >> -Gunnar >> >> -- >> Gunnar Wagenknecht >> gun...@wagenknecht.org, http://guw.io/ >> >> >> >> ___ >> cross-project-issues-dev mailing list >> cross-project-issues-dev@eclipse.org >> To unsubscribe from this list, visit >> https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev >> > > ___ > cross-project-issues-dev mailing listcross-project-issues-...@eclipse.org > To unsubscribe from this list, visit > https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev > > -- > > *Denis Roy* > > *Director, IT Services | **Eclipse Foundation* > > *Eclipse Foundation* <http://www.eclipse.org/>*: The Community for Open > Innovation and Collaboration* > > Twitter: @droy_eclipse > ___ > cross-project-issues-dev mailing list > cross-project-issues-dev@eclipse.org > To unsubscribe from this list, visit > https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev > ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev
Re: [cross-project-issues-dev] Move websites to GitHub
Presumably because Eclipse wants control of all Eclipse project web content to maintain their desired standards, maintain their cookie and data tracking policies, etc. cheers, Jesse -- jesse mcconnell jesse.mcconn...@gmail.com On Thu, Mar 11, 2021 at 12:09 PM Liviu Ionescu wrote: > > > On 11 Mar 2021, at 20:02, Wim Jongman wrote: > > > > The websites stay hosted @ eclipse.org. > > Why not also publish it on GitHub? It might greatly simplify things. > > > Liviu > > ___ > cross-project-issues-dev mailing list > cross-project-issues-dev@eclipse.org > To unsubscribe from this list, visit > https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev > ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev
Re: [cross-project-issues-dev] Move websites to GitHub
I was not aware that the EF was allowing projects to leverage github pages for project content. There have been a handful of issues opened over the last couple of years to just allow the www.eclipse.org project git repos to instead exist out on github but they have not been approved because the whole thing was under review by the webmaster team for what approach they wanted to allow and provide support for. Seems like now is the time for a solid update on where the future of this is intended to be! Wayne? Denis? cheers, Jesse -- jesse mcconnell jesse.mcconn...@gmail.com On Thu, Mar 11, 2021 at 11:23 AM Liviu Ionescu wrote: > > > > On 11 Mar 2021, at 19:01, Wim Jongman wrote: > > > > move the websites to GitHub > > Embedded CDT already uses GitHub Pages to publish the project web, and > there were no problems with it: > > - https://eclipse-embed-cdt.github.io > > > The content is Jekyll markdown and is stored in a separate project: > > - https://github.com/eclipse-embed-cdt/web-jekyll > > Since the default GitHub Pages features were not enough, the conversion is > performed by a custom script executed via GitHub Actions. > > --- > > So yes, moving websites to GitHub is a convenient solution. > > Recommended. > > > Regards, > > Liviu > > > > > > > > > ___ > cross-project-issues-dev mailing list > cross-project-issues-dev@eclipse.org > To unsubscribe from this list, visit > https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev > ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev
Re: [cross-project-issues-dev] The "new user -> ECA -> signed-off by" workflow is broken
I added an action item to discuss on AC call next week. -- jesse mcconnell jesse.mcconn...@gmail.com On Thu, Mar 4, 2021 at 9:33 AM Ed Merks wrote: > Folks, > > I did repeatedly try to get this change, posting arguments such as this > below (in which I did to remove some email addresses to not post them > here). I got Matthias Sohn to also back up the arguments. But so far to > no avail... > > I can try again, but it seems pointless to repeat the same arguments so > perhaps the AC, would like to make a case that I can bring forward yet > again? > __ > > Hi, > > I'm not sure this specific topic is actually one that needs to be reviewed > and considered by the IP Advisory Committee nor that it even requires > some type of Board approval... > > The committer community has request via > https://bugs.eclipse.org/bugs/show_bug.cgi?id=558653 that the requirement > for commits to contain a Signed-off-by tag be eliminated. > > I.e., this part of the handbook needs to change to remove the "Signed-off- > by" tag requirement: > > https://www.eclipse.org/projects/handbook/#resources-commit > > The fundamental point is that when one looks at a commit like this one: > > > https://git.eclipse.org/c/oomph/org.eclipse.oomph.git/commit/?id=a0bf842d3539f2a34516ccd2b1b257950875db37 > > Which looks like this when the email addresses are not filtered out by > the web view: > > commit a0bf842d3539f2a34516ccd2b1b257950875db37 > Author: Christoph Läubrich <...> 2020-07-05 > 14:10:03 > Committer: Ed Merks 2020-07-11 > 08:05:19 > Parent: 6c2e79c17db44454e8b518ba1da8654d4f77490c ([Releng] Eliminate > deprecation warnings new to Java 11.) > Child: 25df8caf7ba3841e3e9efd63d83b567771ebe61d ([Releng] Build against > 4.16 to avoid surprising Java 11 BREEs.) > Branches: change/165847/2, master, origin/master > > [494735] Eclipse Installer does not create .desktop file for the > menu - add Linux Desktop support > > Change-Id: I145791e1ab63278fffca199fb3660ca017e62a00 > Signed-off-by: Christoph Läubrich <...> > > It's clear that the Author: > > Author: Christoph Läubrich <...> > > and the Signed-off-by: > > Signed-off-by: Christoph Läubrich <...> > > specify the same information. > > As such, any checking that's done on Signed-off-by tag can be done on the > Author tag instead and similarly any IP tracking done via Signed-off-by > can be done via the Author tag instead. > > I other words, the Signed-off-by tag is redundant. Given it represents > one more hurdle that contributors often forget, this requirement should be > eliminated. After all, the Author tag is required in a commit so > contributors necessarily must specify one. This is sufficient for all > verification and tracking purposes. > > In terms of implementation effort by the staff, Mikaël Barbero says the > following: > > The business logic implementing the signed-off-by is currently replicated > in various systems (gerrit, github, gitlab). While there are efforts > currently to develop a centralized commits validation service, this check > has already required a couple of re-work of the Gerrit ECA validation > service after some backward incompatible upgrades of Gerrit. Getting rid of > the signed-off-by requirement would greatly simplify the validation logic > and would stick to the strict validation of the ECA signature requirement. > > Thanks, > Ed > > > On 04.03.2021 16:08, Jonah Graham wrote: > > Hi Wim, > > Thanks for sharing your methodology. I can't speak for the 1% result, but > it does not surprise me. The Step 8 is the biggest PITA for contributors on > the GitHub PR flow. Many (most?) PR contributors on github never rebase or > amend their commits (for other projects). I have had to regularly walk > people through the flow of rebasing and amending changes. > > Jonah > > ~~~ > Jonah Graham > Kichwa Coders > www.kichwacoders.com > > > On Thu, 4 Mar 2021 at 09:52, Wim Jongman wrote: > >> >> Hi, >>> >>>> We lose 99% of our casual contributors. >>>> >>> >>> Can you share some insight on how you got this high number? >>> >> >> I have done a scientific measurement. See below how the process works in >> practice [1] with drop-off percentages in each step of the process. >> >> Cheers, >> >> Wim >> >> >> [1] >> *This is the original mail that I decided not to send because it was >> typed in frustration. Take this with a grain of salt; it might not fully >> accurate reflect the current process: * >> >&g
Re: [cross-project-issues-dev] The "new user -> ECA -> signed-off by" workflow is broken
Not to mention the situations where you are a committer on the project and it rejects you because you didn't sign off your own commit. +1 for seeking a path forward I think Trivial is the key here that we could lean in on, if there is no potential IP involved then we should do our best on streamlining those commits, and have a signed off requirement on things more substantial. Even 'no signed off required for a 5 or less lines' would be an improvement I think. cheers, Jesse -- jesse mcconnell jesse.mcconn...@gmail.com On Thu, Mar 4, 2021 at 9:16 AM Liviu Ionescu wrote: > > > > On 4 Mar 2021, at 16:51, Wim Jongman wrote: > > > > I have done a scientific measurement. See below how the process works in > practice [1] with drop-off percentages in each step of the process. > > Regardless of the actual calculation, I fully agree with Wim, there are > many Eclipse Foundation procedures that are far from developer friendly (to > put it politely). > > Given that many projects moved to GitHub, a simple GitHub account should > be enough for contributors. > > > Not directly related, but similar in results, is the absurd strictness of > GitHub access rights, even for project leads and committers. > > For example, if I want to set the Embedded CDT description in GitHub, an > operation that usually takes less than a minute, I cannot do it myself, I > have to open a Bugzilla ticket and some authorised Foundation administrator > will do it for me. > > Completely inefficient, as many other Foundation procedures. :-( > > > Regards, > > Liviu > > ___ > cross-project-issues-dev mailing list > cross-project-issues-dev@eclipse.org > To unsubscribe from this list, visit > https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev > ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev
Re: [cross-project-issues-dev] Simultaneous Release participation and the Eclipse IDE packages
Security model for artifacts in Maven Central is sufficient for most of the known world, and if the eclipse foundation was interested in signing the keys of committers then the artifacts that committers from the eclipse foundation published to Maven Central could have a web of trust associated with the .asc and checksum files. Then if the bundlers of the eclipse editor wanted to further sign their artifacts using jarsigner then that's their prerogative, they can validate the web of trust on anything they're using that's coming from a Maven Central and keep doing whatever the status quo is for P2 repositories. That's up to them but they're not pushing that sort of requirement out to everyone else. cheers, Jesse On Sat, Jan 23, 2021, 16:36 Torkild U. Resheim wrote: > Hi Jesse, > > To paraphrase Wayne, in short: the Eclipse Foundation has a responsibility > in making sure that the community can trust every bundle they consume from > the simultaneous release. > > What we currently do is to sign these bundles with a certificate from the > Eclipse Foundation. This is a quality mark: Implicitly stating that we have > a complete history of every commit to every repository producing these > bundles; A pretty good QA process for these commits, and a very good idea > of who these committers and contributors are; A rigorous process to ensure > safe licensing/patent use and provenance of third party bundles. It's > pretty much as good it as it can get in open source. > > I think I understand from your message, is that you believe this signing > is worthless and that no consumer should require a signed artefact. If I'm > right, how do you propose we otherwise could do this better? What is > impractical with having to deal with signed bundles? > > Best regards, > Torkild > > > > 22. jan. 2021 kl. 20:33 skrev Jesse McConnell >: > > > > > > All bundles must be signed using the EF's certificate. Obvious > exceptions will be made in cases where signing is impossible. > > > > We will be applying this standard to the next release and for every > release thereafter. > > > > The means by which the simultaneous release participation rules are > changed is to engage with the Eclipse Planning Council via your Eclipse > Planning Council representative. > > > > So if I understand correctly everything from above can be changed via > the Planning Council. I'm especially interested in the signing as it's > becoming harder and harder to keep up with external ecosystem due to way > faster pace and being able to use different means of signing as discussed > at https://www.eclipse.org/lists/p2-dev/msg05910.html becomes critical. > But let's keep this discussion for the next Planning Council meeting. > > > > Personally, I think the entire concept of this sort of signing should be > reviewed. If the editor wants to release signed artifacts then the onus > should be on the editor to trust and sign everything it pushes out with the > EF cert, it shouldn't export requirements to projects it consumes to > themselves have things signed by the EF cert. That whole service that the > EF provides for jar files to show up in some directory and signed artifacts > popping out in another is hokey and combined with the concept of p2 > repositories is a big reason Jetty left the release train. > > > > cheers, > > Jesse > > > > ___ > > cross-project-issues-dev mailing list > > cross-project-issues-dev@eclipse.org > > To unsubscribe from this list, visit > https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev > > ___ > cross-project-issues-dev mailing list > cross-project-issues-dev@eclipse.org > To unsubscribe from this list, visit > https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev > ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev
Re: [cross-project-issues-dev] Simultaneous Release participation and the Eclipse IDE packages
> *All bundles must be signed using the EF's certificate. *Obvious >> exceptions will be made in cases where signing is impossible. >> > >> We will be applying this standard to the next release and for every >> release thereafter. >> >> The means by which the simultaneous release participation rules are >> changed is to engage with the Eclipse Planning Council via your Eclipse >> Planning Council representative. >> > > So if I understand correctly everything from above can be changed via the > Planning Council. I'm especially interested in the signing as it's becoming > harder and harder to keep up with external ecosystem due to way faster pace > and being able to use different means of signing as discussed at > https://www.eclipse.org/lists/p2-dev/msg05910.html becomes critical. But > let's keep this discussion for the next Planning Council meeting. > Personally, I think the entire concept of this sort of signing should be reviewed. If the editor wants to release signed artifacts then the onus should be on the editor to trust and sign everything it pushes out with the EF cert, it shouldn't export requirements to projects it consumes to themselves have things signed by the EF cert. That whole service that the EF provides for jar files to show up in some directory and signed artifacts popping out in another is hokey and combined with the concept of p2 repositories is a big reason Jetty left the release train. cheers, Jesse ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev
Re: [cross-project-issues-dev] [aeri] Introducing project dashboards
where is this information coming from? none of the numbers under the Jetty project make any sense to me :) -- jesse mcconnell jesse.mcconn...@gmail.com On Wed, Jul 20, 2016 at 11:55 AM, Marcel Bruch <marcel.br...@codetrails.com> wrote: > Greetings cross-projects, > > I’d like to announce the availability of project dashboards for all > Eclipse projects. Dashboards provide you a quick overview about your > project’s key metrics and problem queries. See the EPP Marketplace project > dashboard [1] for an example. A detailed description of the dashboard > feature and guidelines how to customize the charts is available at [2]. > > > In case you have any questions about using dashboards or feature requests, > please let me know. > > Cheers, > Marcel > > > [1] > https://dev.eclipse.org/recommenders/committers/aeri/v2/#!/projects/54bc9f06bee886e008a60d1b/dashboard > [2] https://blog.ctrlflow.com/project-dashboards/ > > ___ > 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 > ___ 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] CodeEnvy continues to use deceptivewording that's harmful to Eclipse
I think Eclipse (the Foundation) does a disservice to itself every year with its naming scheme for Eclipse (the IDE). The word 'Eclipse' is either a book about vampires to most people, or a fancy code editor to more technically inclined people. While pushing all the projects to prepend Eclipse to all of the project names I get that they are trying to broaden the usage of the Eclipse moniker but by seemingly changing the name of the IDE every year it just clouds the whole naming problem. Is it really Eclipse or Eclipse IDE? or Eclipse Neon? Indigo or Neon? Eclipse IDE the Fancy Editor? In that way I think it is fine that CodeEnvy is saying what they are since there is no clear name from the Eclipse Foundation for their flagship fancy editor...at least that I am aware of...because to me it just changes every year. -- jesse mcconnell jesse.mcconn...@gmail.com On Thu, Jun 30, 2016 at 9:49 AM, Konstantin Komissarchik < konstantin.komissarc...@oracle.com> wrote: > > I do not believe the foundation as such should restrict a specific > projects > > > ability to market it self as long as it is not directly deceiving nor > outright lying. > > > > I contend that the wording is used expressly for the purpose of deceiving > Eclipse user base into thinking that Che is the future roadmap for the > traditional Eclipse IDE. > > > > People wouldn’t object if Che marketed itself based on merits of it’s > features or even if it had a slogan, such as: > > > > “Eclipse Che, the next generation IDE” > > > > Since “IDE” is understood to be a generic term, everyone in the industry > would read that statement as a marketing promotion. > > > > Since “Eclipse IDE” is not understood by vast majority of people familiar > with the brand to be a generic term, the wording is easily interpreted as a > statement of technical roadmap and seeds confusion in the marketplace. > > > > I understand that there are some that wish “Eclipse IDE” to be a generic > term, but wishes don’t make fishes. > > > > Just like Ford wouldn’t get away with marketing itself as the next > generation Chevy, Che shouldn’t be allowed to promote itself in this manner. > > > > Of course, continued investment in the desktop IDE is paramount, but that > doesn’t mean that we should let the brand that some of us invested close to > a decade into deteriorate. > > > > Thanks, > > > > - Konstant > > > > > > > > > > > > *From: *Max Andersen <mande...@redhat.com> > *Sent: *Thursday, June 30, 2016 12:37 AM > *To: *Cross project issues <cross-project-issues-dev@eclipse.org> > *Subject: *Re: [cross-project-issues-dev] CodeEnvy continues to use > deceptivewording that's harmful to Eclipse > > > > Hi Konstantin, > > Below is my opinon as an Eclipse community member (not speaking on behalf > of the foundation nor my employer) > > I recognize the wording CodeEnvy or rather the Eclipse Che project is bold > and for some maybe even directly threatining - but I do not believe the > foundation as such should restrict a specific projects ability to market it > self as long as it is not directly deceiving nor outright lying. > > And Che stating it is a next generation Eclipse IDE is not false, neither > was it when the similar wording was used by the press when Eclipse Orion > was starting off. > > If we (the desktop Eclipse IDE community) want desktop Eclipse IDE to > survive and grow we should not be scared about words stated by other > communities inside or outside Eclipse. > > We should be encouraged to show show the desktop Eclipse IDE also can grow > and not stay stagnated as it have done for a while now. > > This really is nothing new and sure we can "blame" IBM and other companies > for retracting its original people investement into desktop Eclipse IDE - > but that are those companies choice, not the Foundation. We'll either need > to replace those people or change how we do things. I've helped where I can > from my role in Red Hat but just like IBM couldn't pull it of forever > alone, neither can Red Hat. > > This is why I've done what I can and will continue to do in future on the > desktop Eclipse platform features, and I encourage everyone to do what you > can too. Talk to your companies, talk to your contributors and encourage > collaboration and more contributions to grow the desktop Eclipse IDE. > > And in that, we cannot ignore there are other markets where a cloud IDE > like Eclipse Che has its major advantages over desktop Eclipse - just like > desktop Eclipse IDE has advantages over cloud IDE's. > > We are entering a world where there no longer will be a "single" IDE, the > community
Re: [cross-project-issues-dev] New UUID in Eclipse Platform
I am not surprised the feature is here, I am more surprised that it is
opt-out and not opt-in.
--
jesse mcconnell
jesse.mcconn...@gmail.com
On Fri, Jun 3, 2016 at 3:49 PM, Pascal Rapicault <pas...@rapicorp.com>
wrote:
> On 6/3/2016 4:39 PM, Doug Schaefer wrote:
>
> I'll add to that. You say this is in the Platform. Do you mean that all
> products that build with the platform inherit this feature as well, not
> just Eclipse released product?
>
> All, but the UUID is only sent when contacting the EF servers.
>
>
>
> On Fri, Jun 3, 2016 at 4:35 PM, Alexandre Montplaisir <
> <alexmon...@voxpopuli.im>alexmon...@voxpopuli.im> wrote:
>
>> Hi Ian,
>>
>> Sorry I will have to be "that guy", but I do find this a bit concerning.
>>
>> First, The eclipse.uuid file is put in the user's home directory, which
>> means that it ends up identifying a *user*, not just an Eclipse
>> installation. If the same user wipes his installation and re-installs
>> another Ecilpse, he keeps the same ID.
>>
>> This is also done by default, with no warning to the user. Even
>> proprietary programs often pop a window on the first run, asking the user
>> if they want to provide anonymous usage statistics and the like, and giving
>> them the option to disable it. Even if that option is enabled by default in
>> the dialog, that is still miles better than not telling the user about it
>> at all, and requiring him to know about an obscure "eclipse.uuid=0"
>> configuration option.
>>
>>
>> I realize I'm late to the party and the decision has already been made,
>> but you said to let you know if we have questions or concerns, so I am
>> doing just that ;)
>>
>> Regards,
>>
>> --
>> Alexandre Montplaisir
>> Trace Compass Committer & Project Lead
>>
>>
>>
>>
>>
>> On 2016-06-03 11:13 AM, Ian Skerrett wrote:
>>
>>> All,
>>>
>>> I wanted to make everyone aware that a UUID has been added to the Eclipse
>>> Platform [1] and is available in the current Neon RC. This was done at
>>> the
>>> request of the Eclipse Foundation.
>>>
>>>
>>> The UUID is automatically generated and stored in the
>>> ${user.home}/.eclipse/eclipse.uuid file. The UUID does not contain any
>>> personally identifiable information. If a user do not want to have this
>>> property set they are instructed to set eclipse.uuid=0. Information about
>>> the UUID has been included in the Eclipse Platform N [2].
>>>
>>> The UUID will be automatically added to the user-agent of http requests
>>> to
>>> *.eclipse.org servers. For Neon, the projects that make these types of
>>> requests include p2 [1], MPC [3] and AERI [4]. I would expect other
>>> projects
>>> will add a uuid in the future.
>>>
>>>
>>> The immediate questions for many people are 1) why are we doing this,
>>> and 2)
>>> what about the privacy concerns. Let me attempt to answer both of these
>>> questions.
>>>
>>> Why are we doing this?
>>>
>>> The Eclipse Foundation has started an program to better understand our
>>> user
>>> community. We are using a log file analysis service, Splunk, to analyze
>>> many
>>> of our log files to get a better idea of how people are using Eclipse.
>>> For
>>> instance, how many people actively use Eclipse, what version of Java is
>>> the
>>> most popular with the Eclipse user community, what version of Eclipse
>>> Platform is being used or what operating system is being used? In the
>>> past,
>>> this type of information was typically a 'best guess'. We believe can do
>>> better by having the actual data of our user community. The UUID will
>>> allow
>>> us to get a more accurate answer to many of these questions.
>>>
>>> What about the privacy concerns?
>>>
>>> The UUID is anonymous and does not contain personably identifiable
>>> information. We only intend to use and analyze the UUID at an aggregate
>>> level. A user is able to opt-out of sending a UUID by setting
>>> eclipse.uuid=0. The Eclipse Foundation has a published Privacy Policy [5]
>>> that details our specific practices.
>>>
>>> Please let me know if you have any questions or concerns. I appreciate
>>> this
>>> might be a sensitive topic but I do believe it is the right thing to do
>>> for
>>> the Eclipse community.
>
Re: [cross-project-issues-dev] usage of general parent pom and settings.xml
I don't think so, they were located in the old nexus repository that was smoked a few months back...I think CBI has some of their own recommended parent poms cheers, jesse -- jesse mcconnell jesse.mcconn...@gmail.com On Wed, Nov 6, 2013 at 11:50 AM, Henrik h...@protos.de wrote: Hi all, I'm a Maven newbie and just looking at some CBI stuff which I could use for the eTrice project. I saw that http://wiki.eclipse.org/Maven/Parent_POM recommends to use a parent pom [1]. parent groupIdorg.eclipse/groupId artifactIdeclipse-parent/artifactId version3/version /parent but it is not clear to which repository this is published. Also the settings.xml [2] seems to be outdated. Is it still recommended to uses these two files? Thanks, Henrik [1] http://git.eclipse.org/c/dash/org.eclipse.dash.maven.git/tree/eclipse-parent/pom.xml [2] http://git.eclipse.org/c/dash/org.eclipse.dash.maven.git/tree/settings.xml ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
Re: [cross-project-issues-dev] Making your project more openŠhowto enable Gerrit
jetty generally finds this to be the case as well -- jesse mcconnell jesse.mcconn...@gmail.com On Fri, Oct 4, 2013 at 12:54 PM, Igor Fedorenko i...@ifedorenko.com wrote: Yes. Patches attached to bugzilla are easier. -- Regards, Igor On 2013-10-04 12:25 PM, Mickael Istria wrote: On 10/04/2013 06:08 PM, Igor Fedorenko wrote: m2e has no plans to accept gerrit contributions, at least not for now. I'm curious: Why is this so? Did you find a process that makes contributing easier than it is by Gerrit? -- Mickael Istria Eclipse developer at JBoss, by Red Hat http://www.jboss.org/tools My blog http://mickaelistria.**wordpress.comhttp://mickaelistria.wordpress.com - My Tweets http://twitter.com/**mickaelistria http://twitter.com/mickaelistria __**_ cross-project-issues-dev mailing list cross-project-issues-dev@**eclipse.orgcross-project-issues-dev@eclipse.org https://dev.eclipse.org/**mailman/listinfo/cross-**project-issues-devhttps://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev __**_ cross-project-issues-dev mailing list cross-project-issues-dev@**eclipse.orgcross-project-issues-dev@eclipse.org https://dev.eclipse.org/**mailman/listinfo/cross-**project-issues-devhttps://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
Re: [cross-project-issues-dev] FW: [Doug on the Eclipse CDT] New comment on Eclipse smells kind of dead???.
that sounds like something that should be cleaned up a la CLOSED/RESOLVED reminds me of stackoverflow's recent close changes http://blog.stackoverflow.com/2013/06/the-war-of-the-closes/?cb=1 jesse -- jesse mcconnell jesse.mcconn...@gmail.com On Fri, Jul 12, 2013 at 1:06 PM, Igor Fedorenko ifedore...@sonatype.comwrote: Just to clarify on terminology I used/implied. WONTFIX is a real problem which won't be fixed for lack of interest and/or resources. INVALID when the system works as designed. -- Regards, Igor On 2013-07-13 12:57 AM, Ed Merks wrote: Igor, I think it's even stronger than that. In the end, WONTFIX shouldn't mean I don't have time or I don't feel like it but rather it's working as designed and changing it isn't what I believe is appropriate. As such, even if someone provided a fix, that's not what's desired. Committers have the right and in fact an obligation to maintain design integrity; sometimes that annoys people.In any case, we're not obligated to spend every waking moment of every day to fix every reported problem, though it sometimes feels that way Regards, Ed On 12/07/2013 7:26 PM, Igor Fedorenko wrote: How is this going to help? In most/all cases bugs are not fixed because nobody comes forward with quality fixes. Weather somebody says it needs to be fixed does not matter unless his/her words are backed up by the code. -- Regards, Igor On 2013-07-12 11:50 PM, Ed Willink wrote: Hi Get a committer from a related but independent project to review the Bugzilla discussion to form a less prejudiced on view on whether the WONTFIX is justified. Regards Ed Willink On 12/07/2013 17:25, Doug Schaefer wrote: It is. And I'm sure there are hate sites for every tool people use. Eclipse isn't unique that way. My point is that user experience is so important to our success, we need to be sensitive to the issues our users are facing. There are a lot of such issues marked WONTFIX, and CDT is as guilty of that as anyone. I'm just wondering how we fix it. Doug. __**_ cross-project-issues-dev mailing list cross-project-issues-dev@**eclipse.orgcross-project-issues-dev@eclipse.org https://dev.eclipse.org/**mailman/listinfo/cross-**project-issues-devhttps://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev __**_ cross-project-issues-dev mailing list cross-project-issues-dev@**eclipse.orgcross-project-issues-dev@eclipse.org https://dev.eclipse.org/**mailman/listinfo/cross-**project-issues-devhttps://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev __**_ cross-project-issues-dev mailing list cross-project-issues-dev@**eclipse.orgcross-project-issues-dev@eclipse.org https://dev.eclipse.org/**mailman/listinfo/cross-**project-issues-devhttps://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev __**_ cross-project-issues-dev mailing list cross-project-issues-dev@**eclipse.orgcross-project-issues-dev@eclipse.org https://dev.eclipse.org/**mailman/listinfo/cross-**project-issues-devhttps://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
Re: [cross-project-issues-dev] 6 month release cycle
Just wondering here... but since LTS has the a goal of having a set of set points in time (the existing releases) that is maintained into the future, doesn't it make sense to have LTS be the primary stakeholder for the entire simultaneous release concept (maybe they are?) and then if, as Doug is calling for here, there was interest in a more fast moving, ideally generally bug free but sometimes glitchy IDE experience then folks can download and update their editor based on that stream? And have a durable update repository that isn't getting smoked, renamed, or what have you that people can just use for years on end. A bit like how ubuntu lets you have your stable and unstable streams that you can keep updated from As for version resolution...I thought one of the points of osgi was to allow multiple runtime versions of stuff to coexist so from a repository perspective, let them update whatever they want and downstream projects that trust their upstreams can have open version ranges and those that don't can take a more deliberate approach. I am aware I am probably trivializing much of the osgi experience there, but really...from a users perspective of Eclipse (which I am speaking from) I would like to just be able to flip a switch in the IDE and have it notify me of updates, download in the background and either update automagically or restart the IDE as needed and not care about adding p2 update repo this for that thing or download Milestone X or Y or whatever... cheers, jesse -- jesse mcconnell jesse.mcconn...@gmail.com On Wed, Jul 3, 2013 at 11:53 AM, Mike Milinkovich mike.milinkov...@eclipse.org wrote: On the flip side, we need to evaluate the benefits of more frequent releases to see if it's worth it. Completely agree. My assumption is that some projects will want to ship more often, and some will not. We have a large community, and one size rarely fits all. A strategy that can accommodate differing requirements will be necessary. ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
Re: [cross-project-issues-dev] 6 month release cycle
But it is quite scary we're relying on individuals performing manual tasks to get the releases out. I hope that we can automate more of what they do. The beauty of Maven/Tycho/Hudson is that you can automate everything from source to download pages. We talk of the big red button, it would be great if that's all it was. Agreed, which was the lionshare of intent behind my questions regarding LTS assuming some of that role :) cheers, jesse D On 13-07-03 1:55 PM, Mike Milinkovich mike.milinkov...@eclipse.org wrote: ok, fair enough...but if the LTS has been investing so much time and effort into building a process for being able to release updates to simultaneous releases, will they assume that burden from the Planning Council eventually? No, not that I am aware of. As far as I am concerned, LTS is solving quite a different problem. Will that effort be rolled back into the simultaneous release process that the Planning Council currently takes care of? At this point in time, the LTS working group is still very much in start-up mode. They're still figuring out how to do the builds and manage the processes. My advice is that any variant of the thought that somehow LTS will allow change to the simultaneous release process is wrong for at least the next year or two. I won't say never, but I certainly don't see it within any reasonable planning horizon. maybe a slight off topic, if so my apologies No problem at all. For the record, I _like_ the idea of trying to accelerate our releases to encourage more innovation and participation. But there are lots of moving parts, requirements, and expectations which need to be satisfied. And very limited resources to do them. As but one example, our entire community lean heavily on the time and personal commitment of David Williams and Markus Knauer. Asking them to do more does not seem reasonable. Perhaps this conversation will spur others to step forward to help. ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
Re: [cross-project-issues-dev] script that checks presence of file headers (copyright+legal)
there are a number of maven plugins that provide this support, we use one in jetty that scans all our java files at build time to ensure certain licence block presence. http://code.google.com/p/maven-license-plugin/ tis a good goal to have :) cheers, jesse -- jesse mcconnell jesse.mcconn...@gmail.com On Mon, Dec 10, 2012 at 10:42 AM, Henrik Rentz-Reichert h...@protos.dewrote: Hi all, we're considering to introduce a script that checks for the presence of file headers (copyright+legal). The script should be able to scan certain file extensions (.java, .xtend, .xml, ...) and create an XUnit test report. Before developing such a script from scratch I want to make sure that no similar script already exists. Has anybody heard of something like that? Thanks, Henrik ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
Re: [cross-project-issues-dev] Missing project_summary.php
ditto here -- jesse mcconnell jesse.mcconn...@gmail.com On Wed, Oct 3, 2012 at 10:42 AM, Konstantin Komissarchik konstantin.komissarc...@oracle.com wrote: I can confirm this issue. None of the project summary pages are accessible due to the SQL issue. ** ** - Konstantin ** ** ** ** *From:* cross-project-issues-dev-boun...@eclipse.org [mailto: cross-project-issues-dev-boun...@eclipse.org] *On Behalf Of *Sopot Çela *Sent:* Wednesday, October 03, 2012 6:45 AM *To:* Cross project issues *Subject:* Re: [cross-project-issues-dev] Missing project_summary.php ** ** Hi, ** ** I'm continuously getting this http://snag.gy/ATH5R.jpg when I search for project data http://www.eclipse.org/projects/project.php?id=eclipse.e4 . I think it is related to this thread but if not I can file a bug. ** ** Sopot ** ** On Wed, Oct 3, 2012 at 4:17 AM, Wayne Beaton wa...@eclipse.org wrote:*** * Webmaster has made everything right. The redirect should be working now. Wayne On 10/02/2012 09:13 PM, Wayne Beaton wrote: A couple of years ago, I retired the project_summary.php pages and set up a redirect to the new project.php pages. That redirect seems to be failing. I'll check with Webmaster to see why the redirect is being ignored. In the meantime, I've updated every reference to project_summary.php that I can find, so the listofprojects.php page should work properly now. Wayne On 10/02/2012 05:55 PM, Konstantin Komissarchik wrote: The project summary pages such as [1] do not come up (404). I tried a few different projects as linked from the projects list page. None seem to work. [1] http://www.eclipse.org/projects/project_summary.php?projectid=technology.sapphire [2] http://www.eclipse.org/projects/listofprojects.php ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev ** ** -- Wayne Beaton The Eclipse Foundation Twitter: @waynebeaton Explore Eclipse Projects http://www.eclipse.org/projects [image: EclipseCon Europe 2012] http://www.eclipsecon.org/europe2012 ** ** ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev ** ** -- Wayne Beaton The Eclipse Foundation Twitter: @waynebeaton Explore Eclipse Projects http://www.eclipse.org/projects [image: EclipseCon Europe 2012] http://www.eclipsecon.org/europe2012 ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev ** ** ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev image001.png___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
Re: [cross-project-issues-dev] Pleased with Hudson performance and stability
Ha! someone is getting snarky now :) Of course I was just about to reply that it certainly wasn't jetty's fault :P -- jesse mcconnell jesse.mcconn...@gmail.com On Fri, Sep 14, 2012 at 10:25 AM, Denis Roy denis@eclipse.org wrote: That's probably Jetty's fault :P On 09/14/2012 11:18 AM, Eike Stepper wrote: Hi Denis, with all the continous effort you're investing I hate to say it, but the other minute one of my builds died with something like Problem spawning process: https://hudson.eclipse.org/hudson/job/emf-cdo-integration/2336/console Currently I can't look up the exact message anymore because Hudson does not react at all here ;-( Cheers /Eike http://www.esc-net.de http://thegordian.blogspot.com http://twitter.com/eikestepper Am 14.09.2012 16:58, schrieb Denis Roy: I've been quite pleased with Hudson's performance and stability recently. It's not perfect, but it is much, much better than it was a few months ago. I think the software update and the good work Matt has done with the slaves has made a noticeable improvement. As I type this, 25 build jobs are currently running. I find that pretty impressive. Many thanks to the Hudson team for their hard word and support, and to the volunteer Hudson admins who help keep the ball rolling. Denis ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
Re: [cross-project-issues-dev] Sporadic download failures
download.eclipse.org was what was failing yesterday for us -- jesse mcconnell jesse.mcconn...@gmail.com On Thu, Sep 13, 2012 at 9:19 AM, Denis Roy denis@eclipse.org wrote: I thought I had, but I guess not. Do you have a link I can use? Is it on download.eclipse.org or on www.eclipse.org? On 09/13/2012 04:54 AM, Daniel Megert wrote: Hi Denis Did you fix it? I ask because I ran into this several times this morning. Dani From: Denis Roy denis@eclipse.org denis@eclipse.org To: cross-project-issues-dev@eclipse.org, Date: 12.09.2012 21:21 Subject: Re: [cross-project-issues-dev] Sporadic download failures -- I know what that is. I will fix. On 09/12/2012 02:44 PM, Konstantin Komissarchik wrote: I am seeing sporadic cases where the download server returns “download is invalid” page one minute and processes the download just fine the next. Is anyone else seeing this? - Konstantin ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
Re: [cross-project-issues-dev] Sporadic download failures
yes, we have seen that with jetty javadoc from the download.eclipse.org/jetty urls jesse -- jesse mcconnell jesse.mcconn...@gmail.com On Wed, Sep 12, 2012 at 1:44 PM, Konstantin Komissarchik konstantin.komissarc...@oracle.com wrote: I am seeing sporadic cases where the download server returns “download is invalid” page one minute and processes the download just fine the next. Is anyone else seeing this? - Konstantin ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
Re: [cross-project-issues-dev] target audience for release review documents
I was going to say it was just that wayne likes to have a bit of light reading always available But I think the answer is anyone that is interested in the state of the project, and who knows about URL's like this: http://www.eclipse.org/projects/project.php?id=technology.m2e I am interested to hear more of the theory behind these documents. They rank somewhat high on the list of things I would like to stop having to provide. :) cheers, jesse -- jesse mcconnell jesse.mcconn...@gmail.com On Mon, Jun 18, 2012 at 3:25 PM, Igor Fedorenko ifedore...@sonatype.com wrote: I am sorry if this is a question with an obvious answer but who is supposed reader audience for the release review documents and what they expect to find in the docs? -- Regards, Igor ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
Re: [cross-project-issues-dev] IT Support for Strategic and Entreprise Members
I'll just point out the obvious confusing detail on that page, In Services Covered: Tier 2 is _called_ Best Effort yet in Service Availability: Tier 3 is actually Best Effort, while Tier 2 is 99% cheers, jesse -- jesse mcconnell jesse.mcconn...@gmail.com On Tue, Jun 12, 2012 at 8:41 AM, Denis Roy denis@eclipse.org wrote: On 06/12/2012 09:38 AM, Benjamin Cabé wrote: Hello, Hudson is a tier-3 service, meaning webmasters invest their best effort in keeping it alive. It is listed in the tier-2 section on the Wiki page [1], is this a mistake then? Apologies, it was a typo in my email. The SLA doc is correct. Denis ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
Re: [cross-project-issues-dev] IT Support for Strategic and Entreprise Members
yep, that is much improved, thanks! jesse -- jesse mcconnell jesse.mcconn...@gmail.com On Tue, Jun 12, 2012 at 12:11 PM, Denis Roy denis@eclipse.org wrote: Thanks for pointing that out. I've done some edits to (hopefully) clarify things. Denis On 06/12/2012 12:00 PM, Jesse McConnell wrote: I'll just point out the obvious confusing detail on that page, In Services Covered: Tier 2 is _called_ Best Effort yet in Service Availability: Tier 3 is actually Best Effort, while Tier 2 is 99% cheers, jesse -- jesse mcconnell jesse.mcconn...@gmail.com On Tue, Jun 12, 2012 at 8:41 AM, Denis Roy denis@eclipse.org wrote: On 06/12/2012 09:38 AM, Benjamin Cabé wrote: Hello, Hudson is a tier-3 service, meaning webmasters invest their best effort in keeping it alive. It is listed in the tier-2 section on the Wiki page [1], is this a mistake then? Apologies, it was a typo in my email. The SLA doc is correct. Denis ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
Re: [cross-project-issues-dev] p2 repositories ... we can do better
yep, https://bugs.eclipse.org/bugs/show_bug.cgi?id=354756
cheers,
jesse
--
jesse mcconnell
jesse.mcconn...@gmail.com
On Tue, Mar 6, 2012 at 12:48, Denis Roy denis@eclipse.org wrote:
On 03/06/2012 01:46 PM, Jesse McConnell wrote:
heck ideally we could sign with a key that was signed by the
foundation key for a web of trust and not have to do this build
machine signing kludge
Hey, that sounds like fun. Have you opened a bug? Perhaps even provide
a small clue as to what it is you envision?
Thanks,
Denis
anyway, we can add it to the signing plugin in the short term and hope
tycho handles it later (or they might now, I don't know)
or we can just see if tycho does it now and if not ask them nicely to
add support for it...i don't mess with tycho enough to know what they
do and don't do...I just figured that someone who really uses it would
have found the option and chimed in by now. There is time though, it
will be a while til I can get to the plugin to tweak it so if someone
did the research that would be grand
jesse
--
jesse mcconnell
jesse.mcconn...@gmail.com
On Tue, Mar 6, 2012 at 12:40, David Carver d_a_car...@yahoo.com wrote:
Honestly, the p2.Mirror URL and other items that get injected into the
artifacts.xml, p2.index, etc. Really need to go into the Tycho P2
repository creation support. The signing plugin shouldn't be the one doing
this stuff.
Dave
On 03/06/2012 12:35 PM, Jesse McConnell wrote:
Not sure for tycho but given some time I could have that in the
signing plugin in an hour or so I would think.
I'll see if I can scrape some time together to get that support added
in, at least in the interm until tycho could support it
cheers,
jesse
--
jesse mcconnell
jesse.mcconn...@gmail.com
On Tue, Mar 6, 2012 at 11:25, Marcel Bruchbr...@cs.tu-darmstadt.de
wrote:
On 06.03.2012, at 13:04, Jesse McConnell wrote:
could the eclipse-signing-maven-plugin provide a parameter to
inject the p2.mirrorsURL property into artifact repositories and
parameters to generate the p2.index file ?
can you give me a specific example of what that xml (assuming that
would be in some of the xml metadata) would look like?
= Support for p2.mirrorsURL =
According to http://wiki.eclipse.org/Equinox/p2/p2.mirrorsURL just add:
property name=p2.mirrorsURL
value=http://www.eclipse.org/downloads/download.php?file={repository_path}amp;format=xml/
Since webmaster thinks that we have been hit by this issue recently
(https://bugs.eclipse.org/bugs/show_bug.cgi?id=373352) this makes me think
even more about how to integrate this into our builds. As last means of
resort I'll write a bash script that unzips artifacs.jar, adds the
property
to the artifacts.xml, and zips the file again.
But I wonder how much effort it takes to add this in Tycho's
eclipse-repository packaging since tycho generates these files?
It wouldn't be specify to Eclipse; just a generic support for properties
- I think.
= Adding support for p2.index =
The file looks like this:
version = 1
metadata.repository.factory.order = compositeContent.xml,\!
artifact.repository.factory.order = compositeArtifacts.xml,\!
Whether it's xml or jar should depend on the compress property we
already specify in the eclipse-repository.
= Enabling download stat in your repository =
And if we are already on defining properties: to enable download stats
it's...
...for artifacts.xml/repository:
property name='p2.statsURI' value='http://your.stats.server/stats'/
...for bundles:
property name='download.stats' value='test.plugin1.bundle'/
http://wiki.eclipse.org/Equinox_p2_download_stats
So, in theory it's just adding properties and looks from outside like a
simple thing to do. But how long it takes to implement it - at least the
p2.mirrorsURL feature - I've no idea. But maybe a tycho committer knows
better?
I suspect is
possible but I also think it is probably more appropriate to have that
support in tycho
the signing plugin is really just a hack to support this aspect of the
eclipse requirements that is outside of the traditional tycho
workflow...having said that we can always put another hack or two into
it :)
cheers,
jesse
--
Matthias
___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
Thanks,
Marcel
--
Eclipse Code Recommenders:
w www.eclipse.org/recommenders
tw www.twitter.com/marcelbruch
g+ www.gplus.to/marcelbruch
___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
Re: [cross-project-issues-dev] p2 repositories ... we can do better
Great! then someone that actually uses p2 and this stuff on a regular
basis should do this...maybe even replace the signing plugin all
together since there are eclipse ant plugins for signing and packing,
etc...
it would not break my heart at all to never look at the signing plugin again :)
jesse
--
jesse mcconnell
jesse.mcconn...@gmail.com
On Tue, Mar 6, 2012 at 12:47, David Carver d_a_car...@yahoo.com wrote:
It looks like some of this stuff should be doable using Tycho 0.14 and the
Tycho P2 Extras plugin. Included is the ability to run the various Ant
Tasks provided by eclipse.
http://wiki.eclipse.org/Tycho/Additional_Tools
Dave
On 03/06/2012 01:37 PM, Jesse McConnell wrote:
having to go to the cli to tweak this stuff is a non-starter, i have a
mechanism leveraging that for the packing process and I dislike that
immensely
anyway, i am already in java code and mucking with the xml fixing
checksums and the leftovers from the packing process so probably
easier to just add a couple of properties for these settings and
inject them into the xml at that point
not ideal but little about the situation is so will make do with what I have
jesse
--
jesse mcconnell
jesse.mcconn...@gmail.com
On Tue, Mar 6, 2012 at 12:10, David M Williams
david_willi...@us.ibm.com wrote:
I think your eyes glazed over reading my original note before you got to
the part where I said there is already such a tool. See
http://wiki.eclipse.org/WTP/Releng/Tools/addRepoProperties
Feel free to use/copy that as you'd like.
The advantage of having a stand-alone app or tool (not only as part of a
build) is that is allows you to change the properties after the repo is
created, as is sometimes required, after moving or mirroring the repo
elsewhere.
Good luck,
From: Jesse McConnell jesse.mcconn...@gmail.com
To: Cross project issues cross-project-issues-dev@eclipse.org,
Date: 03/06/2012 12:38 PM
Subject: Re: [cross-project-issues-dev] p2 repositories ... we can do
better
Sent by: cross-project-issues-dev-boun...@eclipse.org
Not sure for tycho but given some time I could have that in the
signing plugin in an hour or so I would think.
I'll see if I can scrape some time together to get that support added
in, at least in the interm until tycho could support it
cheers,
jesse
--
jesse mcconnell
jesse.mcconn...@gmail.com
On Tue, Mar 6, 2012 at 11:25, Marcel Bruch br...@cs.tu-darmstadt.de
wrote:
On 06.03.2012, at 13:04, Jesse McConnell wrote:
could the eclipse-signing-maven-plugin provide a parameter to
inject the p2.mirrorsURL property into artifact repositories and
parameters to generate the p2.index file ?
can you give me a specific example of what that xml (assuming that
would be in some of the xml metadata) would look like?
= Support for p2.mirrorsURL =
According to http://wiki.eclipse.org/Equinox/p2/p2.mirrorsURL just add:
property name=p2.mirrorsURL value=
http://www.eclipse.org/downloads/download.php?file=
{repository_path}amp;format=xml/
Since webmaster thinks that we have been hit by this issue recently (
https://bugs.eclipse.org/bugs/show_bug.cgi?id=373352) this makes me think
even more about how to integrate this into our builds. As last means of
resort I'll write a bash script that unzips artifacs.jar, adds the property
to the artifacts.xml, and zips the file again.
But I wonder how much effort it takes to add this in Tycho's
eclipse-repository packaging since tycho generates these files?
It wouldn't be specify to Eclipse; just a generic support for properties
- I think.
= Adding support for p2.index =
The file looks like this:
version = 1
metadata.repository.factory.order = compositeContent.xml,\!
artifact.repository.factory.order = compositeArtifacts.xml,\!
Whether it's xml or jar should depend on the compress property we
already specify in the eclipse-repository.
= Enabling download stat in your repository =
And if we are already on defining properties: to enable download stats
it's...
...for artifacts.xml/repository:
property name='p2.statsURI' value='http://your.stats.server/stats'/
...for bundles:
property name='download.stats' value='test.plugin1.bundle'/
http://wiki.eclipse.org/Equinox_p2_download_stats
So, in theory it's just adding properties and looks from outside like a
simple thing to do. But how long it takes to implement it - at least the
p2.mirrorsURL feature - I've no idea. But maybe a tycho committer knows
better?
I suspect is
possible but I also think it is probably more appropriate to have that
support in tycho
the signing plugin is really just a hack to support this aspect of the
eclipse requirements that is outside of the traditional tycho
workflow...having said that we can always put another hack or two into
it :)
cheers,
jesse
--
Matthias
___
cross-project-issues-dev
Re: [cross-project-issues-dev] Hudson Jetty conversion
I am able click around quickly right now.. jesse -- jesse mcconnell jesse.mcconn...@gmail.com On Mon, Mar 5, 2012 at 08:08, Markus Knauer mkna...@eclipsesource.com wrote: I've got two new problems today... :( One is the web interface. It's painful slow today and/or I am getting our 'Bad Gateway' error. The same problems are shown when I try to update any of my job configurations. Maybe it's a bandwidth problem, maybe a problem with Hudson. Are others having the same problem? The next problem is the file system access. Is /shared/technology available or what's the status there? I thought it should be accessible but every attempt to create/add/modify anything there ends up with error messages like this Cleaning the workspace because project is configured to clean the workspace before each build. java.io.IOException: Failed to mkdirs: /shared/technology/epp/epp_repo/juno Regards, Markus On Thu, Mar 1, 2012 at 08:52, Laurent Goubet laurent.gou...@obeo.fr wrote: We were seeing a steady increase in the time taken by our builds to complete, eventually reaching the time out we had set at 30 minutes, then reaching the time out we had raised to 40 minutes in order to have a build... since Winston started working on this and switching to jetty, all the builds we launched went back to a rough 13 minutes each. So yeah, seen from our side, we have a winner :p. Thanks for all the work you've done on this! Laurent Goubet Obeo On 29/02/2012 22:33, Denis Roy wrote: I was kidding yesterday, but after 24 hours, I'll echo other people's comments here ... Hudson on Jetty, seems like we have a winner. Many thanks to Winston and Jesse for helping out. On 02/28/2012 04:28 PM, Denis Roy wrote: Yeah, nice try, buddy. Man, is it just me, or has Hudson been soo slw for the last 6 minutes? :-D ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
Re: [cross-project-issues-dev] Hudson Jetty conversion
not sure what is meant by 'bundled' vs 'standalone' really maybe osgi vs normal distribution? or embedded vs normal distribution? in those cases there shouldn't be any real default difference, osgi has its natural bit of classloader muckity muck muck but in terms of processing of a request from start to finish...not that I know of. more info on what is meant by 'bundled' vs 'standalone' would help clarify that though cheers, jesse -- jesse mcconnell jesse.mcconn...@gmail.com On Tue, Feb 28, 2012 at 14:08, Winston Prakash winston.prak...@gmail.com wrote: On 2/28/12 11:42 AM, Webmaster(Matt Ward) wrote: Hi Folks, I know it's short notice but as it's quiet for Hudson this week I'm going to move us off the Winstone servlet and onto Jetty. I've got everything ready to go so at 4pm I'll shut Hudson down and then startup the Jetty instance. I expect we'll be offline for about 10 minutes. Nice. Good news is, for Hudson 3.0.0 we don't have to do this, because we replaced Winstone with Jetty as a bundled server. I'm interested to know, from Jetty folks, if there is a difference between Jetty bundled server and Standlone server in terms of performance. - Winston -Matt. ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
Re: [cross-project-issues-dev] Hudson Jetty conversion
ok...for the record... if there are issues with hudson from here on out it is _NOT_ immediately jetty's fault. thank you for listening :) cheers, jesse -- jesse mcconnell jesse.mcconn...@gmail.com On Tue, Feb 28, 2012 at 15:17, Webmaster(Matt Ward) webmas...@eclipse.org wrote: Hi Folks, Ok, the move is complete. -Matt. -- Eclipse WebMaster - webmas...@eclipse.org Questions? Consult the WebMaster FAQ at http://wiki.eclipse.org/index.php/Webmaster_FAQ View my status at http://wiki.eclipse.org/index.php/WebMaster EclipseCon 2012 http://www.eclipsecon.org/2012 ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
Re: [cross-project-issues-dev] Hudson shutdown wait from hell
a new mailing list for hudson build issues? how about hudson-needs-rebooted-ag...@eclipse.org it could be processed by a script even, after 5 distinct messages from different addresses it could trigger the restart itself and free up the webmasters time! :) jesse -- jesse mcconnell jesse.mcconn...@gmail.com On Fri, Feb 10, 2012 at 08:14, Campo, Christian christian.ca...@compeople.de wrote: FWIW I am personally very much in favor of having a new mailing list for hudson build infrastructure messages. Many issues like slaves hanging, hudson is restarted are short-lived issues that are not always worth a bugzilla entry. Also cross project list gets really a lot of traffic from hudson issues currently which maybe is not interesting to people who dont build there. I am sure also some messages get lost because not cross project mails dont have a high priority for everyone. And they could reduce the redundant traffic on all the other channels that Denis mentioned. It shouldnt make bugzilla redundant but it could be used for every message about hudson that we otherwise post to cross-projectŠ. just a thought christian Am 08.02.12 20:49 schrieb David M Williams unter david_willi...@us.ibm.com: I'd agree with this general idea ... perhaps a general notice go out on a mailing list hudson is being shutdown and restarted ... any jobs not done by +1 hour [or something] will be killed. (I'm proud to say I cancelled one of my running aggregator jobs when I saw it was about to be shutdown, saving 50 minutes or so (if I was only job running) partially because I knew it needed to run again anyway. But, now I am panicking ... seeing 30 jobs stacked up in queue! I suggest anyone that has a non-essential job running or queued up consider canceling it until Hudson stabilizes and then run your nightlies, etc. I looks like the number of threads (executors) has been reduced again (understandably). But, who knows, maybe it will clear itself up in an hour or two? In time for our RC3 deadline? In general, I'll say there's been very little communication about the state of Hudson seems several comments made or questions asked on this list with no response ... Hudson restarted, configuration changes all without comment. Is there some resistance to that? Everyone too busy to communicate? Is their a better channel? Hudson bug list? Do we need a hudson-and-infrastructure mailing list? Just asking. The queue is down to 26 now ... in the 10 minutes I took to write this note ... if that rate holds, it will be clear in 90 minutes or so? :/ Thanks, From: Miles Parker milespar...@gmail.com To: Cross project issues cross-project-issues-dev@eclipse.org, Date: 02/08/2012 02:22 PM Subject: [cross-project-issues-dev] Hudson shutdown wait from hell Sent by: cross-project-issues-dev-boun...@eclipse.org Hi all, I wanted to bring up a Hudson annoyance and see if people had ideas for improving this. What's happening now is that any time Hudson gets sent a shutdown, everyone is locked out until the last job in queue finishes. Which is a) Good news for the people with running builds, b) Bad news for everyone else. Observing that most of the time most of us are in category b) I vote for making things work better for group b). Nothing against PTP :D, but they happen to be in group a) this time around and the last run took 22 hours. :O But there are lot's of long builds out there. This means that snapshots are delayed for everyone. So I'm wondering if it might be possible to have some kind of policy where builds are terminated with prejudice under shutdown. I'm not sure if a) this is even supportable OOTB in Hudson, and b) whether that would have the possibility of FUBAR'ing anyone project builds. As project builds should not be relying on previous state, I would say that the answer to b is probably no. I also imagine allowance should be made for key builds such as aggregator. IIRC in the past when in release panic mode we were triggering hard shutdowns from time to time. thoughts? Miles ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev - compeople AG Untermainanlage 8 60329 Frankfurt/Main fon: +49 (0) 69 / 27 22 18 0 fax: +49 (0) 69 / 27 22 18 22 web: http://www.compeople.de/ Vorstand: Jürgen Wiesmaier Aufsichtsratsvorsitzender: Christian Glanz Sitz der Gesellschaft: Frankfurt/Main Handelsregister Frankfurt HRB 56759 USt-IdNr. DE207665352 - ___ cross-project-issues-dev mailing list
Re: [cross-project-issues-dev] Looking for a few brave projects
not much I can do til the network mess is sorted out, I am switching our build back to the other machines for now jesse -- jesse mcconnell jesse.mcconn...@gmail.com On Mon, Jan 30, 2012 at 08:28, Nicolas Bros nb...@mia-software.com wrote: The Metacity window manager does not seem to be installed: metacity: command not found We need a window manager for our UI tests. Is there another one installed? On Fri, Jan 27, 2012 at 9:16 PM, Matthias Sohn matthias.s...@googlemail.com wrote: on slave5 hudon can't find git https://hudson.eclipse.org/hudson/job/egit/2033/console on slave6 there is no access to the network as hudson can't download anything from maven central and maven.eclipse.org https://hudson.eclipse.org/hudson/job/egit/2034/console -- Matthias 2012/1/27 Jesse McConnell jesse.mcconn...@gmail.com looks like the proxy goop for maven hasn't been wired up either https://hudson.eclipse.org/hudson/view/Jetty-RT/job/jetty-8/72/console jesse -- jesse mcconnell jesse.mcconn...@gmail.com On Fri, Jan 27, 2012 at 13:01, Jesse McConnell jesse.mcconn...@gmail.com wrote: issue is on slave 5 as well -- jesse mcconnell jesse.mcconn...@gmail.com On Fri, Jan 27, 2012 at 09:33, Webmaster(Matt Ward) webmas...@eclipse.org wrote: Ah, sorry about that. I've installed SVN and GIT on hudson slave6. Im trying to get the SDK tools to be able to build them for hudson-slave5. Thanks for finding this! -Matt. ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev -- Nicolas Bros RD tel: 06 75 09 19 88 nb...@mia-software.com nbros@gmail.com Mia-Software, 410 clos de la Courtine 93160 Noisy-le-Grand http://www.mia-software.com .: model driven agility :. ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
Re: [cross-project-issues-dev] Looking for a few brave projects
\o_ slave 5 - https://hudson.eclipse.org/hudson/job/jetty/1766/console - git issue slave 6 - https://hudson.eclipse.org/hudson/view/Jetty-RT/job/jetty-8/70/console - git issue -- jesse mcconnell jesse.mcconn...@gmail.com On Thu, Jan 26, 2012 at 19:18, Webmsaster(Matt Ward) webmas...@eclipse.org wrote: Hi Folks, I've just added 2 extra slaves to hudson. Right now I have them set so that only 'bound' jobs will run, and before I open them to all the jobs I'd like to ask a few projects to help us out by making sure I didn't miss something in the setup. They should* just work, so if your project has some cycles would you please set your build host to either hudson-slave6 or hudson-slave5? Let me know about any issues you encounter(either via a bug or email). *: the 'issue' is that Hudson slave5 is not our usual x86_64 architecture(it's IA64). While 32bit JDKs seem ok, using an x86_64 JDK may fail. The host does have an IA64 JRE installed. Thanks! -Matt. ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
Re: [cross-project-issues-dev] git?
And jetty, I think its part of the SOPA blackout, eclipse must be participating, just forgot to put up the banners.. jesse -- jesse mcconnell jesse.mcconn...@gmail.com On Wed, Jan 18, 2012 at 11:09, Henrik Rentz-Reichert h...@protos.de wrote: same for http://git.eclipse.org/c/etrice/org.eclipse.etrice.git/ -Henrik Am 18.01.2012 18:07, schrieb Stephan Herrmann: Hi, anyone seeing any git repositories currently? I see EGit answering '/gitroot/jdt/eclipse.jdt.core.git' does not appear to be a git repository Still on the server the files are all there. best, Stephan ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
Re: [cross-project-issues-dev] git?
so far so good -- jesse mcconnell jesse.mcconn...@gmail.com On Wed, Jan 18, 2012 at 12:04, Wayne Beaton wa...@eclipse.org wrote: ** They seem fine to me. Is everybody else back in business? Wayne On 01/18/2012 12:11 PM, Jesse McConnell wrote: And jetty, I think its part of the SOPA blackout, eclipse must be participating, just forgot to put up the banners.. jesse -- jesse mcconnelljesse.mcconn...@gmail.com On Wed, Jan 18, 2012 at 11:09, Henrik Rentz-Reichert h...@protos.de h...@protos.de wrote: same forhttp://git.eclipse.org/c/etrice/org.eclipse.etrice.git/ -Henrik Am 18.01.2012 18:07, schrieb Stephan Herrmann: Hi, anyone seeing any git repositories currently? I see EGit answering '/gitroot/jdt/eclipse.jdt.core.git' does not appear to be a git repository Still on the server the files are all there. best, Stephan ___ cross-project-issues-dev mailing listcross-project-issues-dev@eclipse.orghttps://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev ___ cross-project-issues-dev mailing listcross-project-issues-dev@eclipse.orghttps://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev ___ cross-project-issues-dev mailing listcross-project-issues-dev@eclipse.orghttps://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev -- Wayne Beaton The Eclipse Foundation Twitter: @waynebeaton [image: EclipseCon 2012] http://www.eclipsecon.org/2012[image: AGILEALM 2012] http://www.eclipsecon.org/2012 ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev logo138x38.gif138x38.png___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
[cross-project-issues-dev] hudson performance
Is anyone getting reasonable performance from hudson lately? The UI just seems incredibly unresponsive making the most mundane tasks take far to long... If its just me then I'll deal with it but if everyone is having these issues maybe we can open an issue for it.. jesse -- jesse mcconnell jesse.mcconn...@gmail.com ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
Re: [cross-project-issues-dev] hudson performance
thanks, am watching that bug now cheers and merry xmas jesse -- jesse mcconnell jesse.mcconn...@gmail.com On Tue, Dec 20, 2011 at 12:36, Kim Moir kim_m...@ca.ibm.com wrote: +1 I see the same issue. I opened a bug, it has been bothering me too. https://bugs.eclipse.org/bugs/show_bug.cgi?id=367238 Andrew Overholt mentioned in the architecture council that he asked the folks who manage the JBoss Hudson servers to work with the webmasters and try to address some of the ongoing Hudson issues we have been seeing. It seems there are significant performance problems that necessitate frequent restarts. I hope that their discussions can help address the underlying issues that destabilize our Hudson install. Restarting Hudson frequently isn't addressing the root cause of these issues. Kim From: Jesse McConnell jesse.mcconn...@gmail.com To: Cross project issues cross-project-issues-dev@eclipse.org Date: 12/20/2011 01:24 PM Subject: [cross-project-issues-dev] hudson performance Sent by: cross-project-issues-dev-boun...@eclipse.org Is anyone getting reasonable performance from hudson lately? The UI just seems incredibly unresponsive making the most mundane tasks take far to long... If its just me then I'll deal with it but if everyone is having these issues maybe we can open an issue for it.. jesse -- jesse mcconnell jesse.mcconn...@gmail.com ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
