Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [cf-dev] Next Californium release?
Ok so just creating a bunch of issue in bugzilla and pointing to them in the plan would be fine?
I think we should start doing that or the plan will be just forgotten and not maintained. 

--
Julien Vermillard :::: http://people.apache.org/~jvermillard/

On Thu, Oct 9, 2014 at 11:10 AM, Benjamin Cabé <benjamin@xxxxxxxxxxx> wrote:
It's as simple as "as plans are a valuable means for the community to get involved with your project, the plan should be started at the beginning of the release cycle. By establishing the plan early, you give prospective contributors help in determining how they can most usefully contribute, and adopters can prepare their own development schedule and themes. ", as stated in [1].
If you are excelling at communicating to possible contributors know what areas they can contribute on for the current cycle, and letting adopters know what exactly will be in the future release / was in a past release, I'm pretty sure your PMC would tolerate a project plan that just point to information maintained elsewhere :)

Benjamin – 


De : Julien Vermillard <jvermillard@xxxxxxxxx>
Répondre à : "Californium (Cf) developer discussions" <cf-dev@xxxxxxxxxxx>
Date : Thu, 9 Oct 2014 11:01:13 +0200

À : "Californium (Cf) developer discussions" <cf-dev@xxxxxxxxxxx>
Objet : Re: [cf-dev] Next Californium release?

There is a doc explaining the rationale of this plan process? 
I just hate doing paperwork stuff just because I have to and not understand why I have to :)


On Thu, Oct 9, 2014 at 10:57 AM, Benjamin Cabé <benjamin@xxxxxxxxxxx> wrote:
It looks great – good job!

Benjamin

De : Julien Vermillard <jvermillard@xxxxxxxxx>
Répondre à : "Californium (Cf) developer discussions" <cf-dev@xxxxxxxxxxx>
Date : Thu, 9 Oct 2014 10:52:58 +0200
À : "Californium (Cf) developer discussions" <cf-dev@xxxxxxxxxxx>
Objet : Re: [cf-dev] Next Californium release?

I did a first version of the project plan paperwork: https://projects.eclipse.org/projects/iot.californium/releases/1.0.0/plan
Crowd: any comment?

If it's fine, next step is to read the doc and generate the M1 release from the actual source code.


On Fri, Sep 26, 2014 at 5:48 PM, Julien Vermillard <jvermillard@xxxxxxxxx> wrote:
I fixed the tests failing due to map order changes.
I still have some test failing due to weird synchronization code,
but they fail only in eclipse, not in maven. I'm not sure to understand the issue.
I asked for java 8 on hudson.
Now back to fixing scandium :)


On Thu, Sep 25, 2014 at 6:41 PM, Julien Vermillard <jvermillard@xxxxxxxxx> wrote:
On Thu, Sep 25, 2014 at 6:26 PM, Kovatsch Matthias <kovatsch@xxxxxxxxxxx> wrote:

BTW they don't run on Java 8. I see a lot of test using Thread.sleep(..) and order of Map (serialization of map to string and test)

 

I tried to keep Java 6 compatibility for Android, which is already broken in Scandium due to the security providers required from Java 7.

Is there a general problem with Thread.sleep() in Java 8 (why would they do that…) or are there restrictions for unit tests?


In Java 8 they tweaked the map, so if your test, test (directly or indirectly like after a json conversion) the order of the map, the test break.

For example: ResourceAttributesTest.java

Assert.assertEquals(serialized,
                               "</sensors>;title=\"Sensor Index\"," +
                               "</sensors/light>;if=\"sensor\";rt=\"light-lux\"," +
                               "</sensors/temp>;if=\"sensor\";foo;rt=\"temperature-c\";bar=\"one two\""
                               );
Since for building the string we walk HashMap we are dependent of order produced the HashMap implementation (which changed in Java8).

In some language (Go for example) walking a hashmap is done in random order for preventing this type of problems and hitting hard when you write the test :)

For sleep in test, it's a bad practice since java is far of being time predictable and it's a source of flaky tests.

 

 Should we contact the Webmaster about this? When I log in, I do not have the Manage Hudson link. 

 

Great, thanks!

How about repo.eclipse.org? What needs to be done there to get the artifacts into the Maven repo?

 

Okay, but the recent builds are missing since Hudson exhibits the above error, aren’t they?


Exactly :( 
We should configure hudson to send a mail to this mailing list in case of problem.
I'll do it when the webmaster give back my hudson configuration rights.
 

Is it otherwise fully linked with commits to GitHub (i.e, the Web hook to Hudson and Hudson to install the artifacts)?

 

I am really sorry for my inactivity on the project, there are so many other things I still have to attend :/


No problem, we all have real jobs ;)
 


_______________________________________________ cf-dev mailing list cf-dev@xxxxxxxxxxx To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/cf-dev

_______________________________________________
cf-dev mailing list
cf-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/cf-dev

_______________________________________________ cf-dev mailing list cf-dev@xxxxxxxxxxx To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/cf-dev

_______________________________________________
cf-dev mailing list
cf-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/cf-dev

Back to the top