Robert Z. has volunteered to prune the list manually. I think we should see
where that gets us.
Let's not forget that every bug report represents a significant investment
of time by a Tapestry user who earnestly wants to make the framework
better, and we definitely want to encourage that. A few
Ok, so we keep piling them up because we don't want to hurt people's feelings?
Don't you think that
people deserve to be told the truth: Guys, we are sorry, but this stuff is
old, we most likely
won't look at it ever because we have a lot of other tasks with higher
priorities, but if you feel
Uli, my only objection is to bulk closing the issues.
On Dec 18, 2012 6:52 AM, Ulrich Stärk u...@spielviel.de wrote:
Ok, so we keep piling them up because we don't want to hurt people's
feelings? Don't you think that
people deserve to be told the truth: Guys, we are sorry, but this stuff
is
This is not directly related, but: I would love to help by submitting
patches (at least for my bug report:
https://issues.apache.org/jira/browse/TAP5-1941), but it's really hard to
get tapestry running from source in eclipse (and i work with eclipse and
java based projects every day).
I will open
Okay, i would like to contribute back to the tapestry project and submit
patches and tests. I have difficulties to get tapestry running in my
current dev environment:
- eclipse 3.8.1 (jdt, gradle plugin, git team provider and m2 plugin
installed)
- win 7
usually i work with mercurial and
Don't use ./gradlew eclipse as gradle will not keep the eclipse project
up-to-date with any changes.
I haven't used the gradle tooling in eclipse but I'm assuming it's similar
to the maven tooling. Instead of import existing project into eclipse
there should be an option to import existing gradle
There's also this:
http://tapestry.apache.org/building-tapestry-from-source.html
--
View this message in context:
http://tapestry.1045711.n5.nabble.com/Getting-current-tapestry-5-4-SNAPSHOT-head-running-in-eclipse-with-git-and-gradle-tp5718810p5718812.html
Sent from the Tapestry - Dev mailing
And my objection is to wasting resources on going through every issue and in
the end still closing
most of them.
If Robert wants to spend the time on it, I'm all for it. But I really want to
see the list of open
issues significantly reduced in the near future and I believe that the mose
time
Uli, let's not make this a religious argument. If we all compromise a bit
we'll see that everyone wants the same thing, a smaller open bug count. Can
we just wait a bit for bulk closing anything, and in the meanwhile keep
sending a message that the time to take a look at the open issues is right
Agreed. I think that if after owner notification and about a month waiting
period, the issue can be closed.
On Dec 18, 2012, at 12:29 PM, Kalle Korhonen kalle.o.korho...@gmail.com wrote:
Uli, let's not make this a religious argument. If we all compromise a bit
we'll see that everyone wants
On 18.12.2012 18:29, Kalle Korhonen wrote:
Uli, let's not make this a religious argument. If we all compromise a bit
I'm not making this a religious argument. I simply don't see why we should
delay cleaning the list
any longer or put any of our valuable energy in outdated stuff. That's simply
We should define some tags that can be used to mark issues that are either
likely to be picked up, or likely to be closed.
On Tue, Dec 18, 2012 at 11:30 AM, Ulrich Stärk u...@spielviel.de wrote:
On 18.12.2012 18:29, Kalle Korhonen wrote:
Uli, let's not make this a religious argument. If we
That's exactly what I'm trying to avoid. I don't want us to manually go through
the list because I
fear that we'll tend to be rather inclusive and won't let go of the old stuff.
If someone wants to pick up an issue, they can just assign it to themselves and
the issue
automatically disappears
13 matches
Mail list logo
