Transfer ownership of User Relationships project

Hi,

I hope it is, but I would love to ask the same question... is it? :-D

I think it's an important one for Drupal.

Merc.

Last commit dates back to April 2008:
http://drupal.org/project/cvs/167682
http://drupal.org/user/107579/track/code

I wouldn't dare to conclude yet this module is abandoned, but a little notice from the maintainer wouldn't hurt.

A duplicate: http://drupal.org/node/300859

Hi,

I submit a task to the Drupal infrastructure people to see if they could put a notice about the module being abandoned IF the maintainer doesn't show up.

Bye,

Merc.

http://drupal.org/node/251466 documents the process to take over the module, which takes a couple weeks to give the maintainer enough time to respond. Unless you can find a place where the maintainer's publicly stated that they're no longer maintaining it, then we can do the process a bit faster.

My apologies for not doing this sooner, but I'd like to publicly request a new maintainer. I no longer have the time to work on UR. Nor do I continue to develop drupal sites for that matter.

Ok since @ #303537: Anyone interested in taking over this module?, alex.k offered to be a maintainer, I've set the project node authorship to him. DaniOrama also offered to help, but I couldn't tell if that just meant via submitting patches or via working directly with the maintainer, so I'll leave that to Alex to decide.

Marking fixed. Thanks a lot, sprsquish and alex!

Also, moving to Webmasters queue so there is record of this change.

User Relationships project transferred to alex.k. See above for discussion.

Wow, thank you for fast work Angie! Was just typing up a request issue to apply for maintainership. DaniOrama msg'd me and offered help too so we'll talk as well.
Thanks sprsquish for clearing the confusion!
Looking forward to moving the project forward.

Returning fields to what they were.

Hi,

I think I have to make you guys aware of this:

http://drupal.org/project/friendlist

Alex.k, I beg you to have a look at Friendlist's code. It's amazingly neat, and I frankly don't see much point in Drupal having two different modules to manage friend lists.

If you do decide to go ahead, please let's at least talk so that the database structures are identical so that migration is istantaneous and things like views integration is shared. They db structures are amazingly similar -- I have just improved UR's a little.

Keep in mind that Friendlist is a complete rewrite from the ground up. I went that way because had decided that there was nothing worth rescuiing in User Relationship's code.

I am not precious about FriendList. I don't care about ownership. All I care is that its source code is _perfect_.

Bye,

Merc.

Since User Relationships already has an install base, and Friendlist doesn't, it seems the sensible thing to do would be for you to contribute patches to User Relationships to clean it up so it fits your standards. That way we don't hurt our users with yet another choice in terms of friend management. The primary reason listed for not working with UR is that it was abandoned, and it no longer is now. :)

Looking forward to your contributions!

Hi,

Webchick: I don't think there is anything worth rescuing in the User Relationship codebase. Nor its database structure.

All I can do is feel sorry for its existing user base. ANd keep developing solid code based on solid data.

Please compare the source code of the two modules and you will agree with me.

SInce *now* there is a good, well written module to manage user relationships, it makes sense to me to work on *that* and maybe provide an exist route for old users.

Merc.

Uh, so how true is your own statement: "They db structures are amazingly similar -- I have just improved UR's a little."?

It would have made sense to take over UR since it was admitted to be abandoned. You could have simply kept the space, rewritten a new version as version 2.x and then worked on (or let the community work on) the upgrade path from v1 to v2. It would have made so much of this clearer and less confusing for everyone.

Alex, Merc please DO work together -- I do not have the time to review the codebases now. If you two so decide that indeed Merc's new code is so far superior -- then why a whole new project? Make a new branch, write an upgrade path, and make Merc a co maintainer.

Having two projects for the same purposes hurts pretty much everyone.

Subscribing.

Hi,

I am not precious about my project. All I am precious about is that good code is used for friend lists.
If my codebase is to be used for "user relationship V. 2", I will make sure that code submitted to it is not sub-standard. The reason is simple: I am not willing to see any more bad code pollute such an important part of Drupal.

Update: I checked the db structure more. Mine is a simplification. I checked it more and I was wrong: I think the way they work is quite different.

Alex, everybody else: please have a look at my source code, then at UR's source code, and _then_ let's talk.

BTW, I am not normally this bloody radical. However, I have had to deal with lack of responses, bad code, bad modules, senseless db structures, etc. about this "Drupal Driend List" issue, and am a little sick of it.

Right now, I am actually applying morbus' advice from the "general discussion":

http://drupal.org/node/304014

Bye,

Merc.

Merc: I have to ask you to stop suggesting that we look at your source code. The onus of "proof" is on you, not us, and it's a bit off-putting to be told to spend a crapload of effort when you, yourself, chose not to put in the effort of improving/rewriting UR (or the patience of waiting a week or so) and instead, forking and confusing the existing subject space (which your FL's module page states you know well). There's something to be said for enthusiasm, surely, but you should really have just waited until you received ownership of UR and could have started from scratch with a 2.0.

I tend to feel that UR is the stronger name and project here - as UR indicates and infers that I can associate many relationships to users, not just "friends". With the very naming of "FriendList" (and, sure, Buddylist, etc.), the inference is that it can never be used for "Son", "Mother", "Enemy" or what have you; even if it can, the name is a conceptual blocker. If the goal here is to create a masterful API of relationships between users (be they "friends" or anything else), then UR is a perfect choice for a name.

Hi,

I humbly accept being told off.
Sorry.
I agree that a much better route would have been gaining ownership of User Relationship. One of the reasons why I didn't was that I started coding, and got carried away. I also didn't feel I could handly inheriting UR's issue queue. I am somehow compulsive about it. It would have taken me 2 days to go through it .. and in 2 days, I coded the whole thing instead. But, that's not a good enough explanation either.

I also feel I should apologise to Alex as well.

I agree, the name "user relationship" is a lot better. If Alex hasn't been put off by me at this point, I am totally happy for him to commit my code as Version 2 of the code, and be made co-maintainer of it so that I can work on it and improve it.

I would also love to discuss things. FriendList is not set in stone -- and I realise that discussions will enrich it.

Bye,

Merc.

P.S.
Marking this as "active"... since it is.

Hi,

I just found this: http://drupal.org/node/303537 where Alex.b stated:

"Sure, I'd be interested. Using this a lot and adding our own customizations (D6) that we'd like to contribute back. UI improvements, integration with content_profile, Views integration."

Alex: what's your view on UR's current codebase? Do you agree on the need of the rewrite? Or would you rather work on/with the existing code?

Merc.

A little OT, but I'd like to put in a request that you put a note on the friendslist project page that people shouldn't use it until the dust settles. It would be bad for people to start using it and wind up with a dead end module that doesn't have an upgrade path.

Michelle

Hi,

I added a notice right at the top and in bold.
I will take it off as soon as this is all settled. Hopefully in the next 2 or 3 days.

Merc.

Hi,

Michelle, for your information (and anybody else's), if the new User Relationship's maintainer doesn't think that it's a good idea to turn FriendList into User Relationships 2.0, I will still develop Friendlist and add myself pretty much immediately views support, workflow_ng and access support.

So, people using my codebase won't end up in a dead end no matter what.

People who use my code know that, and have known that for a while now.

Merc.

Merc, all, thanks for your comments. Merc, I've looked at the Friendlist source (http://drupal.org/node/304014).

As to spinning off User Relationships 2.0 - I don't see a need for this. The API is great, actually a strong point of u_r compared to other modules. It has a nice data model and the functions make a lot of sense. Buddylist has a much smoother UI and 'plug-and-play'-ness, but being able to have different types of relationships and uni/bidirectional relationships is what sold me on u_r in the first place.

It would take a lot of effort to port all the dependencies if the API changes to Friendlist's. I don't see grave problems in the u_r API to support a v2.0 and the big porting effort. Instead time will be better spent building features, like Views integration, some kind of activity stream support (http://drupal.org/project/activity sounded nice for 5.x, or check out http://drupal.org/project/activitystream), and others.

Looking at the similarities between Friendlist schema and semantics the easier way to go would be to port the UI side of it to use u_r API and just have that as a dependency. I can help you getting support for the missing features into u_r - supplying a message when requesting a relationship, and implementing a 'blocked' behavior when refused a relationship request. The UI - it's your call what you like to do.

Great, thanks for putting up the note, mercmobily. Will be good to have all this settled so there's a clear path forward. SN in D6 is a mess and this is one of the key areas.

Michelle

Hi,

Sorry, I am a little confused Alex.
When you write:

---------------------------------------------
Looking at the similarities between Friendlist schema and semantics the easier way to go would be to port the UI side of it to use u_r API and just have that as a dependency. I can help you getting support for the missing features into u_r - supplying a message when requesting a relationship, and implementing a 'blocked' behavior when refused a relationship request. The UI - it's your call what you like to do.
----------------------------------------------

Are you suggesting we should disregard friendlist_api.module, and I should port friendlist_ui so that it uses user relationship as a backend? Sorry, I don't think that's a direction I want to take. The point of building FriendList was to create a better API, whixh is what I did.

I think it's better to keep the discussion in one spot:

http://drupal.org/node/304014

In general, it looks like there will be two Friends APIs modules.

Bye,

Merc.

I think we should bring greggles into this. If alex.k and Merc can't come to an agreement then, to me, it looks like alex.k becomes maintainer of UR (as intended), and friendlist is unpublished as a duplicate effort. We just don't need more confusion in that space, and greggles (I think it's greggles) has been careful about letting duplicate projects with duplicate functionality pollute the airways.

If it comes to that, Merc, my apologies. Sometimes, too many choices is a bad thing.

Hi,

Morbus, unpublishing FriendList would be madness.
It's not a matter of "too much choice". It's a matter of killing a neat well designed API.

You are _surely_ not going to do this. Surely.

Merc.

We've done it in the past, Merc :) For someone not
attached to the code, you're getting a little defensive now ;)

* "I frankly don't see much point in Drupal having two different modules to manage friend lists." Note that you're the duplicate, not UR, not buddylist, not buddylist2. Remove yourself from the equation.

* "I am not precious about FriendList. I don't care about ownership. All I care is that its source code is _perfect_." Than lobby to make UR so. Provide technical reasons. Create new issues. Hash it over and come to agreements with the current maintainer. You're suffering "Not Invented Here" syndrome. Now, granted, I'm all for your "source code must be perfect" (cf. my Drupal Tough Love), but perfect source code is a lower rung than NIH.

Hi,

* I stated clearly that I don't consider User Relationship rescuable.

* I respect Alex's view that it is. But I don't agree with it.

* In many respects, FriendList is much more advanced than User Relationship right *now*

* Working on User Relationship's issue queue would have taken much longer than a good rewrite

* I have proven myself to be a very reliable and dedicated module maintainer

* I think User Relationship's database itself is flawed

So, which module should go, really?

Merc.

Merc: after talking it over with a few other folks, it appears we're no longer unpublishing duplicate projects and instead letting natural selection work it out. Not something I agree with, but I stand by the group's decision. So. Nevermind ;)

(And, for what it's worth, your argument is flawed - you're operating under the presumption that the duplicate module already exists. I'm operating under the assumption that the duplicate module should /never have existed in the first place/ and, thus, its current code and makeup is irrelevant.)

Anyways, could you prepare a technical document detailing exactly the rationale why FL is better than UR? Why the database is so flawed? Why the /design/ of UR is unrescuable? (Note: I said design, not code.) You don't /have/ to - nothing bad will happen if you don't. A technical document like this, however, will let additional modules decide which of the 5 modules in the SN space they should actually support.

Hi,

OK. Great.
I will talk to the User Relationship maintainer (Alex) about making sure that our modules - and ourselves - talk.

Bye,

Merc.

Hi,

(I agree to disagree with you on my argument being flawed. COde is _never_ irrelevant. But that's OK.)

I will work with Alex about why I think UR has problems. I think he knows it quite well, and can either prove me wrong (that wouldn't be the first time) or help him improve it.

The main issue wit hthe DB is that a reciprocal friend-to-friend relationship should have two records, one from me to you, and one from you to me (plus a db-optimisation flag to make View's life easier). This will reflect more clearly what a friendship is. Changing UR's code to implement this, however, might be nbightmare-ish.

But yes, I'll keep the information flow with Alex going. And about the SN people - they will decide according to what the modules provide, how well they are supported, how well they work, and how good the queues look -- and all this in the long term.

We will see. Natural selection at work.

And... thank you again for your comments on FriendList. I think it will make it much stronger.

Bye,

Merc.

I _really_ want to consolidate our efforts as you have already features in Friendslist that User Relationships does not have. And if you are handy with Views, and want to add workflow_ng (http://drupal.org/project/rules ?) support which I was not thinking of adding myself, it would be just great to combine efforts. Let's talk details in http://drupal.org/node/304014 and close this issue. I'm just reluctant to impose the burden of porting everything that depends on u_r API and upsetting the existing install base.

Hi,

Cool. I am totally happy to work with you. To me, Views is also a nasty but I think it can - and should - be done.
Happy to close this issue.

Bye,

Merc.

Hi,

So that anybody knows, Alex and I talked a _lot_ last night and clarified a lot of things.
Please have a look at this:

http://drupal.org/node/305031

This will hopefully address any issue about "why two APIs", etc.

Bye,

Merc.