I totally subscribe to that
J The bugzilla issues could thus serve as kind of a backlog that we are working on …
Apart from my general aversion against “project plans”, I can see the value of indicating to interested users and potential contributors what we are planning
to work on. However, I’d rather like to use the term backlog as in “Scrum” than as in “Project Plan”
J
Mit freundlichen Grüßen / Best regards
Kai Hudalla
INST/TST
Mobile: +49 (151) 54336335
Phone: +49 (30) 726112-159
Von: cf-dev-bounces@xxxxxxxxxxx [mailto:cf-dev-bounces@xxxxxxxxxxx]
Im Auftrag von Julien Vermillard
Gesendet: Donnerstag, 9. Oktober 2014 12:08
An: Californium (Cf) developer discussions
Betreff: 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.
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 :)
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!
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.
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?
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
|
