Fwd: [eclipse.org-planning-council] ECF possibly leaving the train
by Nick Boldt
FYI. ECF might leave the simultaneous release train. Reasons why this
is potentially bad for us are outlined below.
https://dev.eclipse.org/mhonarc/lists/ecf-dev/msg07938.html
---------- Forwarded message ----------
From: Sam Davis <sam.davis(a)tasktop.com>
Date: Tue, Aug 16, 2016 at 3:00 PM
Subject: [eclipse.org-planning-council] ECF possibly leaving the train
To: Eclipse Planning Council private list
<eclipse.org-planning-council(a)eclipse.org>
Hi,
I want to bring to the Council's attention the fact that ECF is
considering pulling out of the simultaneous release train, because I
haven't seen any discussion about this. This is concerning for a
couple of reasons:
* a number of projects in the train, including Platform, depend on
ECF, so we may end up with different projects pulling in different
versions of ECF, which is not ideal
* The fact that participation in the train entails so much overhead
that an active project with a long history of successful participation
is considering pulling out seems like a larger and quite serious
problem for Eclipse. I believe at least part of the overhead is due to
the instability of the build infrastructure.
I'm afraid I don't have any concrete solutions to propose, but I
wonder if, given the current resources, we should consider simplifying
the contribution process (somehow), or reallocating resources from
elsewhere to improve the stability of the infrastructure.
Regarding the infrastructure, my experience from the Mylyn project is
that projects must spend a great deal of time dealing with broken
Hudson slaves, breakages in the signing service, and similar issues,
to the point where I can see why it threatens projects' ability to
participate. Just to be clear, I am not blaming anyone for this - I
know that it takes a lot of work to keep all these things running
smoothly.
Cheers,
Sam
--
Sam Davis
Software Engineer, Tasktop Dev
Committer, Eclipse Mylyn
http://tasktop.com
_______________________________________________
eclipse.org-planning-council mailing list
eclipse.org-planning-council(a)eclipse.org
https://dev.eclipse.org/mailman/listinfo/eclipse.org-planning-council
IMPORTANT: Membership in this list is generated by processes internal
to the Eclipse Foundation. To be permanently removed from this list,
you must contact emo(a)eclipse.org to request removal.
--
Nick Boldt :: JBoss by Red Hat
Productization Lead :: JBoss Tools & Dev Studio
http://nick.divbyzero.com
7 years, 8 months
Re: [jbosstools-dev] [devtools-team] Checkstyle proposal
by André Dietisheim
On 08/03/2016 10:00 PM, Dmitrii Bocharov wrote:
> Good part of the day, team!
> While reviewing someone's code or just looking through it while
> coding, i often want to correct the style of the code: insert a space
> or divide the line in two. I understand that it is really an
> idealistic niggle and a matter of taste, but some things really annoy.
+1, same to me.
This being said there are a few gotchas:
- if we dont want to duplicate Eclipse formatter and checkstyle rules
we'd have to find a way to share there. Even though I believe that this
isnt a big show stopper. Once done you wont change these often.
- we also have to commit the Eclipse code formatter we're using. Ideally
we'd have a way to facilitate workspace setup so that this wont get
another additional step
(http://stackoverflow.com/questions/17703706/any-way-to-automate-eclipse-w...):
* Oomph
(https://timdelbruegger.wordpress.com/2015/08/16/automating-project-specif...)
?
* PSF?
* Workspace mechanics?
We have a jira covering code formatters and checkers:
https://issues.jboss.org/browse/JBIDE-22439
> In my opinion it is a good practice to have agreements about the code
> formatting. Luckily, there is a mechanism in IDEs and usually
> checkstyle.xml-s are committed and then just imported by everybody.
> This is an example of our Red Hat colleagues from EAP team (they're
> just sitting next to me):
> https://github.com/wildfly/wildfly-core/tree/master/ide-configs/eclipse
> Of course if we apply such a checkstyle to one of our plugins, that
> didn't have it before, it'll be a real mess. So i think it's better to
> use it only for the files, where we correct the code. Soon we'll cover
> a big part of the code like this.
> Moreover, there is a maven checkstyle plugin:
> http://maven.apache.org/plugins/maven-checkstyle-plugin/. However, i
> suppose it makes sense to include it some time later when most of the
> code will be formatted and that will help to cover the rest.
>
> So the proposal is to do the following for plugins, that don't have
> such thing (didn't check all of them, but the ones, i'm working on -
> don't):
> 1) To create a checkstyle.xml file
> 2) Commit it (for every plugin or just in jbosstools-devdoc, for
> example) and add information about it to the Contribution part of the
> plugins' descriptions
> 3) All contributors should add it to their Eclipses
> 4) Make remarks about code style in PRs.
> 5*) configure maven checkstyle plugin in org.jboss.tools.parent (or in
> every plugin)
>
> Best regards,
> Dmitrii
7 years, 9 months
Release date for Tycho 0.26: late August 2016
by Nick Boldt
FYI, Tycho 0.26 should be available for use with 4.4.1.Final / 10.1.0.GA.
---------- Forwarded message ----------
From: Sievers, Jan <jan.sievers(a)sap.com>
Date: Mon, Aug 8, 2016 at 3:28 AM
Subject: Re: [tycho-user] Release date for Tycho 0.26?
To: Tycho user list <tycho-user(a)eclipse.org>
Cc: Tycho list <tycho-dev(a)eclipse.org>
it's been almost 4 months since 0.25.0 [1] so I propose to schedule
staging 0.26.0 this Friday, release one week later.
the list of bugs fixed/features added is not long [2]
but together with the support added for TestNG I guess there is enough
interest for a release.
@committers objections?
Regards,
Jan
[1] https://wiki.eclipse.org/Tycho/Release_Notes
[2] https://bugs.eclipse.org/bugs/buglist.cgi?classification=Technology&list_...
On 05/08/16 17:53, "tycho-user-bounces(a)eclipse.org on behalf of Nick
Boldt" <tycho-user-bounces(a)eclipse.org on behalf of
nickboldt(a)gmail.com> wrote:
Just wondering if there's a planned date for Tycho 0.26.
Looking forward to being able to use this new feature [1] but need a
full release (not a snapshot) in order to use this in our .Final
builds.
[1] http://wiki.eclipse.org/Tycho/Release_Notes/0.26#New_option_to_check_cons...
Thanks,
--
Nick Boldt :: Productization Lead :: JBoss Tools & Dev Studio ::
Red Hat, Inc.
http://nick.divbyzero.com
_______________________________________________
tycho-user mailing list
tycho-user(a)eclipse.org
To change your delivery options, retrieve your password, or
unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/tycho-user
_______________________________________________
tycho-user mailing list
tycho-user(a)eclipse.org
To change your delivery options, retrieve your password, or
unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/tycho-user
--
Nick Boldt :: Productization Lead :: JBoss Tools & Dev Studio :: Red Hat, Inc.
http://nick.divbyzero.com
7 years, 9 months
REMINDER: Code Freeze for 4.4.1.AM3 / 10.1.0.AM3 is tomorrow, Thurs Aug 11 @ 5pm EST
by Nick Boldt
We'll be building the bits to stage for QE from the master branch, so
there's no need to change your root poms or create branches.
Just be sure to have everything you want included in the build pushed
to github by 5pm EST on Thursday night.
Build will run over night, and will be copied from /snapshots/ to
/staging/ on Friday morning.
If you have anything blocking you from being ready by EOD on Thursday
(tomorrow!) let me know ASAP.
--
Nick Boldt :: JBoss by Red Hat
Productization Lead :: JBoss Tools & Dev Studio
http://nick.divbyzero.com
7 years, 9 months
[aeri] Create multiple JIRAs from one search query
by Marcel Bruch
Greetings JBosstools-Dev
I just noticed that today a few people created many bug reports “one-by-one”. This may be on purpose but if not, here is how you can create a set of JIRAs in one click:
1. Make sure that your project has a default JIRA project, component and version. If not set, go to projects > your project > bug tracking and select the values for your project.
2. Go to the problems page, filter all problems belonging to your project, and select the bulk edit action “create bug report”. Finally select all problems you’d like to create a JIRA for and press “Execute”.
That’s all. Now, you can make the final adjustments in JIRA as needed (set the target version, assign the bug report to s/o etc.)
HTH,
Marcel
7 years, 9 months
