That's all just lovely sentiment Hans. The point is that communication is the
key, if you see a problem in the trunk due to a recent commit then report it to
the committer (if you know who it was) via the dev list. If it's a blocking
bug then reverting it is fine, but it really needs to come
Scott Gray wrote:
Keeping things productive was definitely the goal of my email. A jira just
wasn't necessary in this case and requiring one adds
additional burden to committers with very little real benefit. The only
purpose served would have been if somebody actually
applied the patch
Thanks for your opinion Scott,
Let's try to keep it productive...
Yes, that I agreed on: http://markmail.org/message/2e3qo2ydna4lp5gp
I'm sure you did not miss it even if it's not part of this email.
I still believe that, the more we share through Jira, the better. For many
reasons it's more
Keeping things productive was definitely the goal of my email. A jira just
wasn't necessary in this case and requiring one adds additional burden to
committers with very little real benefit. The only purpose served would have
been if somebody actually applied the patch and tested it which is
Thank you Jacques, you are doing a really good job not only committing
contributions but also keeping everybody working together.
I admit my action was a bit quick, but on the other hand getting a
change in the system which is blocking, (this change cannot be shown to
a customer) then still
If you would have announced this before you implemented it, i would have
known, now in first instance we think this is caused by our changes.
And only later check the svn updates
Regards,
Hans
Try entering a purchase invoice:
Expected collection or sequence. parameterList evaluated
This is indeed a concern. I believe we should always all follow the Jira way of
sharing and testing before committing any new major feature or major bug fix
(not trivial ones of course).
Then, it's possible to wait few days for others to check, not bullet proof but
surely better.
Jacques
Hans
Thank you for the detailed problem description. I fixed this problem in
rev 1517880.
-Adrian
On 8/27/2013 1:53 AM, Hans Bakker wrote:
If you would have announced this before you implemented it, i would
have known, now in first instance we think this is caused by our
changes.
And only
That was not the case in my commit. The macro widget renderers were
proposed by Jacopo years ago and we discussed it. The implementation was
incomplete however. So, I merely finished an incomplete implementation
of a new feature we agreed on years ago.
-Adrian
On 8/27/2013 3:06 AM, Jacques
Then maybe a few words on the dev ML would not have hurt.
Jacques
Adrian Crum wrote:
That was not the case in my commit. The macro widget renderers were
proposed by Jacopo years ago and we discussed it. The implementation was
incomplete however. So, I merely finished an incomplete
Stop trying to create some sort of solution to a non-existent problem. Things
get refactored and sometimes it causes issues, that is the nature of the trunk
and Hans can deal with it the same as anyone else, by reporting and/or fixing
issues first, and then reverting if no reasonably quick
Hans,
Normally, we report problems on the mailing list, not revert someone
else's commit.
This was rude and uncalled for. If I did the same thing to your buggy
commits, none of your contributions would make it into the project.
-Adrian
On 8/25/2013 11:28 PM, hans...@apache.org wrote:
I'd add that using trunk for clients's projects should not be an excuse, you
can always revert locally, waiting for a definitive solution...
Jacques
Adrian Crum wrote:
Hans,
Normally, we report problems on the mailing list, not revert someone
else's commit.
This was rude and uncalled
Fixed in rev 1517611.
Not only was this revert unnecessary, the commit message is false. The
Tomahawk theme was entirely usable, but one drop-down menu had a
slightly broken layout.
-Adrian
On 8/26/2013 1:47 AM, Adrian Crum wrote:
Hans,
Normally, we report problems on the mailing list,
Adrian,
Normally I would try to fix a problem and i did this pretty often.
Because this was a blocking problem i saw no other way then to revert it.
Very good to hear you like my commits which at least make a difference
for our end users. Although i personally appreciate your framework
Jacques,
Blocking, obvious problems like this one , should not be committed to
the trunk, they upset other developers because the system becomes un-usable.
Our customers do not use the trunk, so that is not a problem, but use a
version which run at our staging server for a month. We call it a
No one is asking you to fix anything. All you had to do was post a
message and I would have fixed it.
There was nothing blocking about my commit, and as I said there was no
reason to revert it.
Reverting a commit the way you did is NOT co-operation, and co-operation
is a concept you
17 matches
Mail list logo
