[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [egit-dev] 2.4 project plan
|
On 03/18/2013 02:33 PM, Tomasz Zarna wrote:
Excluding all patchs that get a -1 from hudson without even telling us that you will not look at them will end up with cases such as André's :
he was waiting for feedback ... on something you would not look.
Guys, don't get me wrong. I'm doing this for fun, nobody's paying me
for working on EGit. It's all after-hours/weekend coding in my case. I
have a life too.
Yes absolutely and I'm pretty sure that this is true for most of the
EGit/JGit committers. Noticed the late evening/weekend comments and
review I got. I personally perfectly understand that you guys are trying
to do your best while trying to have a life.
On the other hand I guess that things could get improved when it comes
to accepting, reviewing patches. My personal impression is that it's
easy for contributors to get a bit frustrated with the not so obvioius
dev-workspace setup (TP, push to gerrit etc.), large and strict commit
rules (message formattings, code formating, etc.), sometimes very rapid
and sometimes very long response times. Dont get me wrong, I'm in the
convenient position that I'm pretty much used to it now and get work
time to fix/contribute important issues (EGit is high prio dependency
for JBoss Tools in OpenShift tooling). I'm not complaining, I'm only
trying to point out how contributors could get encouraged rather than
discouraged.
Also, I said it's just me. I'm pretty sure that other committers are
better at watching review inbox than me.
For the cases I've seen, we would need to re-push the very same change (is that even possible?) to "force" hudson to trigger a new build and vote... and if the test fails again, go back to step 1 and push again.
If you're not able to retrigger a Hudson job you can try rebasing the
patch. If none of these work, you can always leave a comment on the
change.
Cheers,
Tomek
On Mon, Mar 18, 2013 at 1:39 PM, Laurent Goubet <laurent.goubet@xxxxxxx> wrote:
Sorry to butt in but ... some of the "-1" I've seen from hudson were results
of seemingly random test failures, with one recent example was patch set 2
of https://git.eclipse.org/r/#/c/10654/
which received a -1 because of an SWTBot test failing because of an
IOException
(https://hudson.eclipse.org/sandbox/job/egit.gerrit/4233/testReport/junit/org.eclipse.egit.core/GitMoveDeleteHookTest/testMoveProjectWithinGitRepoMoveFromTopOneLevelDown/)
Excluding all patchs that get a -1 from hudson without even telling us that
you will not look at them will end up with cases such as André's : he was
waiting for feedback ... on something you would not look. For the cases I've
seen, we would need to re-push the very same change (is that even possible?)
to "force" hudson to trigger a new build and vote... and if the test fails
again, go back to step 1 and push again.
Laurent Goubet
Obeo
On 18/03/2013 13:10, Tomasz Zarna wrote:
Sorry, missed the link to JGit change.
As for the failure, the truth is that it's unlikely someone will look
at the patch that got -1 from Hudson. I have even excluded such
changes from my queries. Anyway, have you tried running those tests
locally (with and without your patch)?
Tomek
On Mon, Mar 18, 2013 at 12:55 PM, André Dietisheim <adietish@xxxxxxxxxx>
wrote:
Hi Tomasz
thanks for looking into it!
comments below.
On 03/18/2013 12:38 PM, Tomasz Zarna wrote:
Does the EGit change depend on the JGit one?
it does, added the following to my commit-msg:
Note: depends on jgit change I670782784b38702d52bca98203909aca0496d1c0
Do you know, why Hudson
doesn't like the latter?
As I tried to sum up in
http://dev.eclipse.org/mhonarc/lists/egit-dev/msg03047.html I'm not
completely aware of why SmartClientSmartServerTest would fail, but I'm
pretty sure it's not because of my patch. I wasn't completely sure of the
purpose nor on the test setup so I didn't try to fix it. If that helps I
could dig futher into it.
André
Tomek
On Mon, Mar 18, 2013 at 8:46 AM, Max Rydahl Andersen
<max.andersen@xxxxxxxxxx> wrote:
How about the patch allowing for streaming of output messages during
pushes
?
http://dev.eclipse.org/mhonarc/lists/egit-dev/msg03047.html
https://bugs.eclipse.org/bugs/show_bug.cgi?id=398387 ->
https://git.eclipse.org/r/#/c/9730/
https://bugs.eclipse.org/bugs/show_bug.cgi?id=398404 ->
https://git.eclipse.org/r/#/c/9732/
This would give a *significant* usability for egit vs the command line
IMO.
The patch have been sitting there waiting for feedback for a while now -
would love to
get just some kind of info on what is missing for this to go in ?
/max
On Fri, Mar 15, 2013 at 08:32:11PM +0100, Matthias Sohn wrote:
Eclipse projects are supposed to always have a plan.
I created a draft for 2.4 [1] containing the new features which
are already finished or close to that. Please review that and let me
know if any features you plan to finish until 2.4 are missing.
Committers can also edit the plan directly on this page.
[1] https://projects.eclipse.org/projects/technology.egit/releases/2.4.0
--
Matthias
_______________________________________________
egit-dev mailing list
egit-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/egit-dev
_______________________________________________
egit-dev mailing list
egit-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/egit-dev
_______________________________________________
egit-dev mailing list
egit-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/egit-dev
_______________________________________________
egit-dev mailing list
egit-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/egit-dev
_______________________________________________
egit-dev mailing list
egit-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/egit-dev
_______________________________________________
egit-dev mailing list
egit-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/egit-dev
