Posted by puzzlemaster on April 5, 2009 at 11:41pm
5 followers
| Project: | Views Date range |
| Version: | 6.x-1.0 |
| Component: | Miscellaneous |
| Category: | task |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | active |
Issue Summary
Following the guidelines set out here: http://drupal.org/cvs-application/requirements - I would like you to confirm our discussion to bring me on as a co-maintainer of the Views date range module.
Comments
#1
The first thing you could do is to test patches that fix bugs (not new features). Apply the patch, make sure it applies cleanly, test it, you might need to think it through a little bit and make sure that the patch really solves all the cases, or if the patch is done in a good way. I'd like all my modules to be secure, internationalizable and adhere to coding standards. Not everyone does a great job with using t(), l(), and check_plain(), or with spacing and curly bracket placement. If their missing stuff like this, and you think that the patch is fundamentally sound after testing it, reroll the patch to fix these things. If you test a patch and think it's good, you can mark it as RTBC. You'll need to ping me to ask me to look at it. And I apologize in advance if you need to ping me more than once ... but you might need to. I'll review the RTBC and commit them.
Once you get your CVS commit access, I'd still like to review your stuff for a bit. But I might ask you to make the commit. And once we're both comfortable then you'll be able to handle these things on your own.
The second thing you could do is just help people in the issue queues by telling them how they can or can not use the module. Most issues are probably non-issues.
#2
The first thing you could do is to test patches that fix bugs (not new features). Apply the patch, make sure it applies cleanly, test it, you might need to think it through a little bit and make sure that the patch really solves all the cases, or if the patch is done in a good way. I'd like all my modules to be secure, internationalizable and adhere to coding standards. Not everyone does a great job with using t(), l(), and check_plain(), or with spacing and curly bracket placement. If their missing stuff like this, and you think that the patch is fundamentally sound after testing it, reroll the patch to fix these things. If you test a patch and think it's good, you can mark it as RTBC. You'll need to ping me to ask me to look at it. And I apologize in advance if you need to ping me more than once ... but you might need to. I'll review the RTBC and commit them.
Once you get your CVS commit access, I'd still like to review your stuff for a bit. But I might ask you to make the commit. And once we're both comfortable then you'll be able to handle these things on your own.
The second thing you could do is just help people in the issue queues by telling them how they can or can not use the module. Most issues are probably non-issues.
#3
Uh. I have no idea who puzzlemaster is as I've never spoken to him, and I don't know why douggreen is replying as he's not a maintainer for views date range either. I suspect you're both lost, and looking for: #424682: Per our conversation, would like to be a co-maintainer of this module with you ...
#4
Crell, hrm, that's interesting. I never knew that there was a "Views Date Range Filter" (my module) and a "Views Date Range" (your module). Have you ever looked at my module? My module provides a views filter for date ranges and has been around for some time. Should I obsolete it for 6.x?
http://drupal.org/project/daterange
http://drupal.org/project/views_daterange
#5
Marking fixed so it still shows up in the issue list while we're still talking...
Bah and double bah! Just once I'd like to actually know about a module before I write something like it. :-) Although it looks in this case like they're somewhat different things. views_daterange is all about creating arbitrary date ranges for summary views. It's an argument handler. It looks like your module is a filter, and at least some (but I don't think all) of its functionality is already in Date module in D6.
Probably not a duplicate, but if you make a D6 version we should definitely cross-link to help avoid confusion.
#6
Automatically closed -- issue fixed for 2 weeks with no activity.
#7
Hello....
This is probably the wrong issue for this, but I'd like to throw a potential third module into the mix and I figure both maintainers are subscribed to this issue :)
It produces Views date filters with options like 'today', 'this week', etc, like this:
Might this feature belong in either of your respective modules, or would it be better to start a new project?
It's also pretty basic right now, as I'm just working to a client's spec. But adding options through the Views UI wouldn't be hard.
#8
Hm. I don't know if it would be part of this module in particular, unless we expanded this module's scope to be "fancy schmancy date-views integration." I'm not sure if Karen would want that in Date proper, either. It almost sounds like a natural replacement for Doug's module above, which has only a D5 version.
That said, I could actually use that sort of functionality myself. :-) Or more precisely a "within the past week", "within the past 2 weeks", within the past month", etc. So I'd be interested to see it, wherever it lives.
#9
> It almost sounds like a natural replacement for Doug's module above, which has only a D5 version.
That's what I was leaning towards too.
I was thinking I'd have to ask Doug to take over his old project, but his machine name is daterange and mine is views_date_range_filter. So no problem there -- I'll just file an issue asking him to put a forwarding link on his project page.
#10
Done: http://drupal.org/project/views_date_range_filter