What's wrong with google code? http://code.google.com/p/clojure/issues/list
On Fri, Jan 23, 2009 at 5:29 PM, Howard Lewis Ship <hls...@gmail.com> wrote: > > I'm always a fan of using a real issue tracking system; I'd love to > see Clojure using JIRA to track what's going on, and what's coming up, > in a public and visible way. It'll make it feel more like a community > project, less like a one-man show (I deal with that perception all the > time on Tapestry). > > I actually have a stable, permanent JIRA instance all set up: > http://tapestry.formos.com/jira. It would be a few minutes work to > set up a clojure project and get everyone registered. > > > > > On Fri, Jan 23, 2009 at 1:48 PM, Rich Hickey <richhic...@gmail.com> wrote: > > > > > > > > On Jan 23, 4:19 pm, Jason Wolfe <jawo...@berkeley.edu> wrote: > >> > On Fri, Jan 23, 2009 at 12:23 PM, Jason Wolfe <jawo...@berkeley.edu> > >> > wrote: > >> > >> >> OK, if these are not wanted in core right now, will anyone sign off > >> >> for adding them to clojure.contrib? > >> > >> > Well, *I* want these changes you've proposed in the core, but of > >> > course, I'm not in charge. > >> > >> Thanks. > >> > >> > I guess the real question is, what is the > >> > process to ensure that Rich sees and considers a potential core > >> > improvement like this? I think the main mechanism for this is to post > >> > it as an "issue" on google code, but I'm not certain whether you're > >> > supposed to post an issue unless he's seen the newsgroup thread and > >> > says, "Yes, that sounds good, please post it as an issue." But if he > >> > misses the thread for some reason, that will never happen. So it's a > >> > bit of a catch-22. Anyway, maybe someone can clarify the procedure. > >> > >> Yes, it is not supposed to be posted as a core issue unless Rich OK's > >> it here. > >> > >> I just had a discussion about just this "meta"-issue on IRC. Chouser > >> says that Rich still reads every message on the group. See also the > >> further-up discussion in [1] for more procedural details, where it is > >> also suggested that an explicit sign-off here should be required for > >> posting clojure.contrib issues. > >> > >> [1]http://groups.google.com/group/clojure/msg/657291bc62c48f32?hl=en > >> > >> Anyway, I'm feeling quite frustrated and won't try to push this (or > >> any other) issue further. I know Rich and the team are very busy, but > >> it really saps my will to contribute when I have to keep pushing to > >> get an authoritative answer (be it yes or no) on even (what seems to > >> me to be) a fairly uncontroversial change like this one, or [2]. > >> > >> [2] > http://groups.google.com/group/clojure/browse_thread/thread/5d11bc0da... > >> > >> Sorry for taking your question as a jumping off point for whining > >> about not getting attention. I guess my short answer is: the policy > >> is fairly clear, but its current implementation may be discouraging > >> potential contributors like myself. > >> > > > > I appreciate your desire to contribute, but Clojure is not just about > > your needs. You have flooded the group with every idea you have, some > > are bugs (important), some are good ideas, some not, but there are > > simply too many to address at the rate you are producing them. In > > addtion, sometimes you've made issues, and often blogged about them. > > So, for #2 the issue was addressed and you found out about it that > > way. I can't answer you (or anyone) in every forum. > > > > I'd advise you to be more patient, build up a small library of helper > > functions you use frequently, make contributions of the most important > > of them to contrib. Clojure doesn't change that fast and it's not > > going to. I like to consider things and I can't address every > > suggestion as it is made. > > > > Separate out the important things (like potential bugs) so they get > > more attention. > > > > As for these: > > > > - 0-arg distinct? returns true, not an exception (so (apply distinct? > > nil) = true) > > > > Not now, will consider. > > > > - rewrite concat so that (apply concat seq) doesn't evaluate the > > first three elements of seq > > > > No, may fall out of streams work. > > > > - make every?, not-every?, some, not-any? take multiple seq args like > > map, i.e., (every? not= [1 2 3] [2 3 4]) > > > > No. > > > > - allow arguments to merge-with after the first to be lists of > > pairs. > > > > No. > > > > Rich > > > > > > > > > > > -- > Howard M. Lewis Ship > > Creator Apache Tapestry and Apache HiveMind > > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~----------~----~----~----~------~----~------~--~---
