Difference from Checkout?

Hello Grayside,

well the basics can be found here:

- #550730: Checkout not working at all with any WYSIWYG. Including new checkout.module implementation, fixing several things
- #663722: Offering to maintain Checkout (Content locking)

Thats the reason the fork happened. I cannot undestand who actually the maintainer is the this project (sun?, smk?, joel?), but at least what i see, the maintainer does not respond at all. He is gone for a while in addition, the submitted patch did not get into the module at all. Yes, the coding standards were not fullfilled, but hey, in the meantime the module is (nealry) not useable at all? So actually, the maintainer should have fixed or even refactor that patch ( in term of applying it and press ctrl+shift+f in Eclipse..) .. but i guess the maintainer is not eager to do anything at all. So finally after 3 months i asked for the status and if help is needed. As you see, i stated, that without any response i will open a issue for the webmaster to become the maintainer and checkin the code i was using for 3 months in production.

But somehow sun comes into play - acting like he is the maintainer (he is not) - renaming that issue, adjusting the priority and stated things, he does not have a clue about. He simply did not investigate at all but judged directly. He stated, there was no patch / contribution at all, but actually thre was one, a 7KB patch, which was not only a small adjustment to fix 1 or 2 bugs, but basically fix nearly all of them. So this was kind of rude - and kind of rude was my reaction upon this.

Eventhough making me the Co-Maintainer i cant see a valid point of keeping a Maintainer (joe) who has not done anything in this module since _3 years_. So actually, i dont think it helps anybody keeping him in that position .. most probably he wont even recognise. As you see also in this module, iam not eager to "steal credits". I cleary state in this project from the start, that the credit / the ideas belongs also to the initial authors.

But after making a complete rewrite - sharing the module to others (which kind of pleased of the result i think.) - and letting it work and test in productin for ~ 4 months i actually think this two ways:
1. The maintainer is going to lead the developement. He gives the roadmap, he makes the ultimate decisions if needed. He maintains the project and organizes it. He is the only person which can get new Co or a new Maintainer if he becomes not interested anymore and he is the only one giving away his project to someone else.
2. A new maintainer is going to do those tasks

Well, case 1 is simply not going to happen, as the old maintainer is gone for 3 years now.
Well case 2 was my offer and it was declined by only giving the Co-Maitainer.

Conclusion
Eventhough i could have checked in as a Co and also make releases, there is the reason to keep the maintainer. This decision was not based on any facts, this decsion was based on personal feelings, as smk and sun or brothers. I cant see any other point in this.

Yes, i could still have opened a task in the webmaster queue and (probably) get the maintainership because the maitainer will not answer BUT...
... why should i fight my way through this? Why should i fight my way though somebody like sun .. who is not a simple contributor of modules like iam but a core-developer being quiet known and respected? Well the only thing would have been happen, that i would have been recognised, what "having powers" means in a project. This _realy small_ case and small module would have become a general discussion and bashing BECAUSE

"Hey Eugen is trying to rip away someone else module".

Well no way i jump into that self bashing trap. So i dodged and created a fork after 4 months...

1. The question is, why sun is acting here at all?
2. Who would have been harmed, if someone who has rewritten the module in big parts to get it working more robust would have become the maintainer IF the old maitainer has been gone.
3. So finally, who would have been harmed when someone caring much more about the module as the maintainer would actually become that one?

Technically:

The idea of both modules is exactly the same - there are nearly no extra-features in content_lock compared to checkout.
Technically content_lock is a rewrite of checkout, because checkout is not working in ajax enabled enviroment (so nearly all?).
I think overall content_lock is much more robust, but thats for the user to decide in all of there different env.

Hi Eugen,
I think I can understand your motivation - I had looked at the checkout module before, but refrained from installing it because some of the issues (and the apparent non-reaction to them) seemed not very promising to me.
I've installed your module for now and will try to test it.
However, I would prefer to see the fork undone, if there is any way to do so.
Creating a new branch (as smk-ka suggested) and waiting for the CVS access to be transferred would IMHO be a much better solution...

Guys i accept your arguments, but actually the decision has been done. I already ported the code - i have waited enaugh time. Now it simply too late. Over and out.
And even if its the standard to prove the credentials EVEN if the maintainer if gone forever - that is not a valid point for me at all (especially if you rewrite the whole module). Actually for me the old maintainer has to establish his credentials. Leaving this module in the dust is much more "against" the community then my actions.

During renaming the module i allready adjusted things including the translation strings and things..i will not merge that back.

1. The question is, why sun is acting here at all?

I am one of the drupal.org webmasters and CVS access administrators, and therefore I act whenever I see a related issue that needs attention. Sorry for not stating this, but it would massively increase my workload if I'd had to explain this every time I put on that hat.

2. Who would have been harmed, if someone who has rewritten the module in big parts to get it working more robust would have become the maintainer IF the old maitainer has been gone.

As Grayside correctly explained in #3, the usual procedure is to grant co-maintainer access to a project on drupal.org. If it then turns out that "the project maintainers" (in general, we don't differentiate here) agree on an additional project owner change (which really only switches the name on the project page), then this change is done by a drupal.org webmaster. But still, project owner changes require agreement from both parties involved.

3. So finally, who would have been harmed when someone caring much more about the module as the maintainer would actually become that one?

I cannot answer that question, the other project maintainers would have to. One of the current co-maintainers requested to grant you CVS access to the project, and although only the project owner is normally allowed to grant CVS access, you were granted anyway. Counter question: Who would have been harmed when someone caring about the module becomes a co-maintainer?

Like any other maintainer, you can collaborate and join forces with the other maintainers, work on the issue queue, commit code to the project, create new releases, etc.

Who would have been harmed when someone caring about the module becomes a co-maintainer?

Me if i put my time into this.
Me if its 100% of the work.
Me if the Maintainer exactly does: zero.

And actually if "me" is not a valid argument here, eventhough i do not only care about the module but even reimplemented the module and put quiet some time into it. Well why do you wonder about this fork at all?

Well forks are always giving the "end user" (searching for that solution) a confusion, thats true without a doubt.

But if its not possible to cleanly continue the checkout module as every other module (with all consequences and responsibilities) i would not put my time into it.

In this special case i even think, that most probably after finding checkout (well actually who searches for that name?!) and installing it, iam pretty sure there will be a second attempt to look fo an alternative. Out of my experience, checkout is broken on a mass of installation.

I second quiet some of your opinions, but this also is something about treatment. And as its open source, the personal feeling is not to unimportant - as you dont get paid for your work. So actually credits and respect is some of the most important things in open source to keep contributors motivated.

Anyway - the train is gone, i will focus on this module (keeping this story as a reminder and a lesson for all - me included)

heh, if all you're asking for is #711000: The "i like this module" issue!, then, hey! Such issues can be created for any project :-D

Me if i put my time into this.
Me if its 100% of the work.
Me if the Maintainer exactly does: zero.

This is true for 100% of all other projects and developers on drupal.org. Following that thinking, there really has to be a drupal_sun, views_sun, wysiwyg_twod, and whatnot project somewhere, don't you think?

You won't find those, because they do not exist, and because they would be conflicting with the principles of the Drupal project. I'm not sure whether my initial response on the other thread resulted in this disbelief of those principles. But let me state that - however it may have been interpreted - it wasn't meant to discredit you or anything of your work. I mean, that's just great! I was merely putting on my CVS maintainer's hat, keeping in mind the best practices for co-maintaining projects, and asking for clarification and perhaps justification. If that came through wrongly, I have to excuse my bad wording.

It would be great if there was a chance to de-fork this project.

Sun all i was asking for is the maintainership for checkout TO avoid a checkout_eugen fork. This is stated serveral times in that issue. And the only reason for asking that because the old maintainer is gone.

Lets state it in clear words:

If the old maintainer is _gone_ and that position is not filled with a active person, i expect to place somebody there, who is interested in that job. You must be _glad_ to have someone with that interest also..because that means offering time and work.

And its not about "i only contribute if iam the maintainer, otherwise i create a fork". Its just a pair of those conditions:
- You do all the work to be done.
- There _is no other maintainer.

I contribute to other projects without beeing a maintainer, co maintainer or anything else..

And we had that situation, but yeah - it did not go that ways and therefore thats the reason i created that fork.

There is no doubt that there were some missunderstandings and maybe some rude words from both, you and me - maybe in equal parts. I appolagize for that also.