Posted by johnbarclay on October 6, 2011 at 6:10pm
29 followers
Jump to:
| Project: | Feeds |
| Version: | 7.x-2.x-dev |
| Component: | Miscellaneous |
| Category: | task |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | active |
| Issue tags: | D7 stable release blocker |
Issue Summary
I'm looking for some insight into feeds 7.x-2.0 release plans. I've used it quite heavily over the past couple of weeks and applied quite a few patches to get the functionality I needed. I added some notes at http://drupal.org/node/1301604. Not sure who are the current maintainers and their thought on 2.0 release are, but below are mine. If this seems like a worthwhile discussion, we can move it to the g.d.o. wiki. Maybe we need a 7.3 placeholder for pushing issues forward.
Keep core feeds project as simple as possible. Its heavily used and easy to build on top of. Move as much extra functionality as possible to feeds_tamper, other field modules (references, etc.), and special use case modules.
Definitely in
- Fix simpletests for D7. Many are broken.
- Error Catching: #1110762: Feeds does not catch file exceptions properly in file mapper and FeedsParser.inc getFile() function , #955236: Handle fatal errors for entity create with better error handler function , #723548: Provide better URL validation and error reporting for invalid feed URLs
- #1046916: Importing nodes with their original NID fails because of ambiguity in node_save() in FeedsNodeProcessor
- #686470: Filefield mapper: URLs with spaces not parsed properly
- #1127696: Attach multiple importers to one content type (in D7)
- Language Issues #1183440: Make field import language-aware , #1247536: Allow users to choose node import language, #1228570: Add user language to FeedsUserProcessor
- #1266890: Additional targets for nodes
- User Imports: #1300764: Feeds User Processor User Update Feature Needs clarity in user interface, #1228568: Add user status to FeedsUserProcessor, #1189000: submitting patch to map to username OR user ID OR current user in same field
- #1033202: add a generic entity processor
- #1362378: Provide entity post-save hook
- #1369874: Don't roll own CSV parser; use PHP's native one
Maybe In, maybe separate module
- Support for hierarchical taxonomy imports. #1152940: Feeds term import with hierarchy and weight
- #658574: SQL Fetcher and Parser
Definitely out
- One to many relationships. #759966: CSV: Support one to many relationships, #661606: Support unique targets in mappers / hook_feeds_node_processor_unique()
- Multivalue fields. #1039134: Multi Tag import when importing a node, #1165506: Add pipe delimiter to csv parser, [#] Feeds tamper can resolve some of these.
- Edge Case? #1190470: URL prefix and suffix for HTTPFetcher
Comments
#1
Would be great to get some kind of confirmation or affirmation from phase 2 on this direction. Anyone?...
#2
We're holding another module maintenance jam at Phase 2 during lunch on Wednesday. I'll make sure we talk about this, so we can get you some feedback on our thoughts and what direction we'd like to go in.
#3
I dont have any comprehensive plan for Feeds 7.x-2.x just yet, there are too many outstanding issues/patches to focus forward just yet. I have mobilized a few guys from my team to help tackle the long list of outstanding patches and once we make some good headway there we can start to formulate more of a plan for moving forward. All that to say we will dig into outstanding patches including the "Definitely In" section above.
As of this morning I have all unit tests running cleanly (please verify)
I also have a group of us spending our lunch hour or so right now reviewing patches.
#4
Will the generic entity processor ever be rolled in to this module? The patch seems to work well...
#5
We should stick these in there as well:
...as other issues either could or do depend on them. We should add any others that are framework-ish.
I think the biggest job that has to happen (ideally before we get this thing out), is cleaning out the issue queue. I'm finding tonnes of duplicates, and those are metric tonnes! We could probably have a summer student work on this exclusively. :)
#6
@colan, We've been working on testing patches in the past week or so.
If you see any issues that are duplicates, please feel free to close that issue and in the comments, refer to the issue that asks the same question. We'll be doing this as we go through the issue queue as well, but any help you can give us would be greatly appreciated!
#7
Way ahead of you - been doing that for the past week at least. ;) Thanks for testing patches - wasn't sure if anyone was still maintaining this!
#8
@colan, Thanks! I wasn't sure by your comment above. We really appreciate your help!
#9
Marking #1400042: Create stable release of Feeds for 7.x as a duplicate of this issue.
#10
May I suggest that someone who has the appropriate authority (febbraro?) tags the important issues with 7.x-2.0 blocker?
Gives quick entry for anyone wanting to give a hand.
#11
From greggles' duplicate:
Xen: I think anybody can add tags; extra permissions not required.
#12
Making sure tag can be added.
EDIT: I was able to add the tag to some issues (including this one), and I don't have any extra permissions. So other folks can help with the ones I didn't get to.
#13
@colan
Wasn't so much a question of permissions, but more to get the stamp of approval from the maintainers on the selected issues. If everybody just adds their favorite issue, we'll never get anywhere.
#14
Might I add:
#996808: Update existing doesn't reset targets that have real_target set.
#712304: Batch import does not continue where it left off, instead starts from the beginning
I actually think there are multiple issues here, but I've been getting a lot of complaints from this one:
#625196: Fatal errors (Unsupported operand types) and warnings (Argument is not an array) in FeedsConfigurable.
#15
@twistor
That's why we need a maintainer to draw out a roadmap.
#16
I think drush integration is a must, and it is quite there #608408: Drush integration
#17
Xen: That's a good point, but is might save the maintainer(s) work if we tag what we think is appropriate, and then he/she/they edit it.
#18
@colan:
Well, if someone would gather together all the contenders and make a list for the maintainers to give the nod, it might.
Would be nice if the maintainers would show up and give their input.
#19
Given the fact that the issue queue is so huge, I don't think any one person will have time to evaluate all of the things that should go into a stable release. We would certainly appreciate any support in identifying all of the critical issues for a 2.0 stable release with the 'D7 stable release blocker' tag. These need to be real critical issues though, not just that something specific (or obscure) does not work for a particular use case.
In any case, tagging the issues will help us focus our efforts and allow us to get there faster. Thanks.
#20
@febbraro
Having everybody and their dog tag their favorite issues with the 'D7 stable release blocker' is just going to make another big list of issues. Somebody has to play hardball and decide which of those issues is *really* needed for a stable release, and what'll have to wait.
There's been issues mentioned here that's not really needed to get a stable D7 release out the door, and the more that's added to the list, the longer it'll take.
Having a clear "these are the issues that the maintainer says needs to be fixed" list rather than a big "these are the issues that some random thought should be fixed" list is a bigger motivator for anyone that wants to dig in.
#21
@Xen, Issues can be un-tagged just as easily as they can be tagged. A maintainer just asked for assistance finding the critical issues as this queue is huge.
Might I suggest a few guidelines:
#22
@twistor
I'm just asking for someone to take a bit of charge here. It's been six months since the last alpha, there's still major functionally issues, and everybody agrees that we need to get things moving and prioritize.
So why is #1369874: Don't roll own CSV parser; use PHP's native one considered a blocker? I'm all for using the standard PHP parser, but considering the problem of too many issues, is it really needed for the first D7 release? If the old code works, let it be and refactor it in a later release.
It's fine if people can help out pointing out the issues, but someone has to decide whats considered a blocker, because we can't all do it.
#23
@Xen: Then this one is something that can be dropped from the draft list once its complete. But let's add a refactor tag to this type of issue, so that these don't get lost.
@febbraro: Do you want more co-maintainers? I (and probably others) would be happy to help, as it seems like you're overwhelmed.
#24
that would be awesome (a stable release) - though 'job scheduler' is still in alpha. could this be configured to work with elysia cron instead? http://drupal.org/project/elysia_cron (seems that it would present potential for more granular control in large import scenarios or predictable intervals at bigger scale)
#25
Hi guys. I'm the lead for Feeds module here at Phase2, so with guidance from febbraro, and your input, I'm trying to get this stuff moving. I've been committing smaller changes over the last few months, while trying to get more familiar with the code base. But anyway, just wanted to chime in here so you know where to direct your questions and concerns.
#26
thanks for the intro - it sounds like the floating question is where things stand for a stable 7x release, whether it's soon or later this year, any insights would be greatly appreciated!
#27
Hope things are going well. Another approach to getting a beta out and perhaps make the core feeds module maintainable would be to split out the feeds modules as such:
feeds
feeds_ such as:
feeds_user
feeds_node
feeds_taxonomy
feeds_webservices
In the long run, this might make the module releases more viable because "feeds" could be released as stable without all these other dependencies. In this model, the modules like feeds_user would also be architected as contrib feeds modules are expected to be and would server as better templates for contrib modules. It might also help to get core feeds in core drupal.
I have some funding to do some work on feeds if there can be some hint of an exit strategy for 7.2, otherwise I just need to work around feeds altogether. I'm just not in a position to build on top of a module that has path out of dev.
#28
emackn, I'm also in for co-maintainer role, if it's needed.
I don't think #1033202: add a generic entity processor, #1362378: Provide entity post-save hook and #1369874: Don't roll own CSV parser; use PHP's native one should be listed as blockers at all. New features need to be pushed into 3.x, and we should work hard on fixing the bugs at this time, as we all need a stable realease of 2.x. I'm tired of using -dev release or patching already committed fixes in the old release, so maybe we should setup a sprint or something to get this done.
#29
@franz, I agree that those issues shouldn't be blockers. Although, they don't need to be pushed back to 3.x either. New features, as long as they are backwards compatible, can be considered.
Count me in for a sprint.
#30
I think we should add a new alpha release at this time. Already a handful of bugfixes in.
#31
It's 11 months since the last alpha - makes a ton of sense to me.