Screw you guys, EugenMayer is going home

Thank you for expression your value in for the work, very appreciated.

I keep it simple on those points:
- Those projects are GPL, they are published and are therefor part of the community to be used
- I will never be able to enforce they are not further build on drupal.org - this is not possible and that is _good_ ( so aim with you )

I will, under every behalf, respect the GPL - so please do not start a license decisions here.

But its more complicated on those:

As iam free as a human being, iam allowed to ask to respect my work on free time and not to fork it for d.o, just for the sake it "being on drupal.org". Iam _maintaing_ this projects on github and _will_ provide a release-based project page which includes a fserver. That said, installing a module released that way, will be updatable / notified the same way, as on drupal.org - no downsides for the user expect: well new place -harder to find the module.

So basically, aim _not at all_ removing the work out of everybody's reach - i published every bit of it on github and stated i will maintain them. But i will no longer do this under the hood of drupal.org - and i ask people to respect this decision. If i would ever want to remove the code - stop me by publishing it on every website you can.

If people continue those projects on drupal.org even though they are actively maintained in a good reach ( and for free and under the GPL and all this ), i will close down all my repos and you will be on your own then. That might be not a big deal for a lot, whatever. But a bigger deal might be that not a single new module will ever be released by me anymore - and we are currently talking about a set of 180 module we have developed ( which are not released ). This, iam just rushing on that point, will hurt (iam telling you that not as an ego but as a developer).

So basicaly i ask the people to take a small burden to be not able to download it from drupal.org on behalf to respect my personal decision to not continue them here and to thank for the work that has been done. Its a trade, its being respectful and that will motivate me working on those modules and keeping them up.

But, as Gerhard already teaching me, this will never happen - which furthermore really is another argument for me, to never publish anything on drupal.org. This is disrespectful.

If people continue those projects on drupal.org even though they are actively maintained in a good reach ( and for free and under the GPL and all this ), i will close down all my repos and you will be on your own then. That might be not a big deal for a lot, whatever. But a bigger deal might be that not a single new module will ever be released by me anymore - and we are currently talking about a set of 180 module we have developed ( which are not released ). This, iam just rushing on that point, will hurt (iam telling you that not as an ego but as a developer).

Very amusing.

I see Gerhard, you want to continue your personal dispute with me in this open discussion. Iam must disappoint you, i won't give you a podium here. Its not only private, its hijacking this issue. But well, iam not here to teach you i guess.

I asked, not "told", just to differentiate that. If you don't follow this, i cannot and will not act on this or whatever.

I will not agree ( in terms of "Iam fine with that" ) that modules are continued on drupal.org which are maintain actively and freely by me on a different platform - but i will not enforce anything, just to repeat that.

So you won't get my blessing on that, sorry, but you are of course free to do what you think is best for you/whom ever.

Hm, somehow i get your point on that. I will seriously consider this, give me 1 or 2 days to think about. Ok?

drupal.org has never provided external links to Drupal software. The focus on making all Drupal code available from drupal.org has made Drupal strong and I see no reason to abandon that policy.

While Eugen is of course free to do actual development on github or elsewhere, the result, ie downloadable tarballs, need to be downloadable from drupal.org. To facilitate this, the releases need to be pushed to drupal.org's git instance.

So i guess, Gerhard just killed that possible consensus.

That statement, thought, shocks me.

Drupal.org does not mean, "we give you a cool platform and we are happy to have you here. You can host here or were ever but we would be happy to have you here on board".

It more aggressive like, if we got your ass, we got your ass. Deal with it.

I guess that mood changed over the years when the project-count hits a number were you lose the overview and a single project does not really spike out to much. Its just a huge mass, and it seems to be a only about the mass and maintaining it to be "mass" - no matter whats inside - dead or alive. I pretty sure, drupal.org started differently, rather being happy to have contributors.

The "one more - one less - who cares" approach works better dealing with that mass, obviously. Not sure it brings healthy results, but well, its at leas "controllable".

The big monster seems to be fed now being picky on what will be eaten to lunch next.

Which one precisely?

You killed:
- projects will go on "not maintained" but with current releases ( so no downsides to current installations )
- project-page states, that development goes on at a different place ( github / fserver ) + link
So i guess our options shrinking to zero.
So lets bring it down to the fact:
You will sincerely ignore my note on that page, bringing back all projects without notes that the maintainer moved on to do its duty somewhere else (just changing platform ) and everything is back to normal. For most. And who cares less about my blessing.

I suppose - case closed

Removing all code from a project is just vandalism. As a consequence, I am sorry but I don't think we have any other choice then to revoke your Git privileges on Drupal.org and mark your modules as abandoned. Once marked as abandoned, those modules are going to be able to be picked up by more responsible maintainers by following the abandoned projects procedure.

To avoid any further vandalism, I temporarily revoked EugenMayer Git privileges.

@dman: Eugen can of course host his code externally, absolutely no problem. But we will then either unpublish or delete the projects themselves (unless somebody takes them over).

None of the resources you list have project pages on d.o (or should not, I didn't check).

Damien, if you would have looked closes,e.g. iam still minting fserver here and did not touch anything there - because its simply to my work in large and iam not going to do that. So its not unreflected what i did, i touched my own codebase and absolutely nothing more, even i could have done so ( e.g. with fserver ). But well, do what ever you think its best.

And as you surely know, there is now way to remove anything from git. But i guess it sound more like abusing using the word "remove".

Not if you actually MOVE the code. You guys just take the perspective which looks best for you.

I did not REMOVE it, and thats it. i moved it to a freely available, instantly available, including all informations.

So seriously, you should keep straight on that. Removeing would mean i would not have checked in the file with the URL to the new repo and i would not have linked this on the project page, or that link needs "registration, payment" or whatever.

#20 i was seriously considering this, but due Gerhard, this is not allowed or whatever. So we can't do that(?)

@killes
aegir was in the "we tell you dev is out there at aegirproject.org" mode for more then a year, or even more. Including issue queues and code AND releases. They moved to d.o. when git got available - not before. And therefore they were allowed to do so....for a long period.

No Extrawurst for anybody.

Nothing bad on cleaning up the confusion were the project will be continued actively. And until nobody does on drupal.org, the resource on gihtub is, objectively, the best source for the user. Period. But still, i really like the picture :)

There are 12 modules affected by this. Out of those 12 modules:

• 10 modules have seen their code vandalized: for all of them we need to revert the vandalizing commit and mark them as abandoned. Some of them have co-maintainers that would likely be good candidates to take over maintainership.
• SWFUpload is unaffected and EugenMayer is not the project owner: we just need to remove EugenMayer from the maintainer list
• Feature Server is unaffected but EugenMayer is the current project owner: I suggest we reassign the project to Frank Febbraro for now.

@killes:
Sorry Killes, but why you need to put oil in the fire ? What you do are trolling a discussion...

@other:
I do not want to be very involved in the discussion but what here currently happens is a big bullshit and destroys community and the fun on it. Dman has tried a lot to find a consense with EugenMayer ... other peoples tries to disturb them with positive success. Its not funny.

The next thing what i see is that peoples with administrative rights try now to find rules and match them to put again oil in the fire... there will be sayed "No link on d.o. to external projects" but... big companies in the drupal world has an exception ? Also sayed EugenMayer destroyed code ? On a VCS like Git ? come on... a simple revert and this problem is solved...

uhh come on guys... we talk on first over a simple minimalistic security issue and now you want to kick a good maintainer ? I think all involved peoples in this war need to be cool down and need to take a constructive fazit how it cant happend in the next time...

thanks
Dennis

Or to draw a line under your calculation:
-10 of 10 modules aim the initial author of, have been moved to github by the author ( me )
- 2 of 2 modules, which iam not the author of but the maintainer and could have do something - but didn't.

And now you seriously go forward and remove me from maintainership of a project i took from github myself and put on drupa.org, to merge efforts and have one maintained version.

How you treat people utilizing pure force is not healthy.

I've been simply stating the obvious: We will not change our procedures just to please Eugen.

Actually, dman asked. Not me. But yes, thats your perspective. Your heart - and thats exactly the point. You focus me in this discussion, not the best solution.

My focus is solely on the continued good health of the Drupal project.

Very amusing.

sure... only for the drupal project... come on let your personaly problems with EugenMayer from this discussion.

Could we please find a mediator that stands on neutral ground, that leads this negotiation? I think it's a good idea to let Dan or Damien lead this discussion. Gerhard and Eugen know each other on a personal level and at the moment this isn't helpful for settling this. Like Blackice2999 said, it's putting oil on the fire, even if it's not intentional.

I want to see a peaceful agreement, we're a community, everyone's free to contribute or to leave as they wish. I like the proposal from Dan in #5.

Also I'd like to emphasize on Mario Marić's last comment on "Response about SA-CONTRIB-2012-036":

IMHO this issue should not be anymore about code & security but about acceptance, forgiveness, flexibility, openness and learning.
...
So, if we want to learn from this than we could create some procedure / policy that will be applied when there is minor security issue in module e.g. stating that in module page - which will be moved only if maintainer repair security issue.
...
And also, I understand that security / best practice standards are really important, but IMHO they shouldn't be more important than people i.e. community.

When it comes to security, it's best to err on the side of more not less and as someone who has had a module handled in a similar way (which was eventually fixed and republished when I became aware of it), I agree with the handling of the security issue. And had the maintainer tried to address it with the security team in a calm and mature manner, I'm fairly sure a mutually agreeable solution could have been reached. However having a tantrum and deleting code, the equivalent of taking all your toys and storming off, makes restoring git privileges to the maintainer a non-starter-- something the maintainer only has himself to blame.

So, despite dman's laudable attempt at trying to bring attention to this fairly and evenhandedly, the issue is no longer about the original problem.

GPL issues aside, no one should be allowed to abuse their git privileges on drupal.org to wipe out code. period. That is hardly the mark of 'important people in the community' and doing so invalidates any other legitimate points they may have had.

Somehow i really thought, people know the difference between "delete/remove" and "move". But the first ones just are better to handler, much more clear to argue with i guess.

Take it, or do not take it: I moved to code, checked in a file to state, were the code resides now to not confuse people were the current maintained version of the code resides (instead of having 2 places). The code was available in the public, immediately and with all meta data. It was a full move, without any loss or filtering. Deal with it.
http://drupalcode.org/project/wysiwyg_imageupload.git/blob/6ae33d4:/move...

Drupal.org is not the centrum of the universe and if code moves from one platform to another and people looking at the old place find a not were to look at now - that is _good_. I admit,of course until both places are free of access / download - which is 100% the case here.

You take something i did, modulate it the way you need it and base all your argumentation on it, which then perfectly works out. You might slightly change things, remove unneeded parts like (copy+delete=move ... delete=delete....pitty, isn't it.) or add your own individual interpretation of the rest. More and more people jumping not the topics, not even trying to deeply investigate, but just take some parts and make up their minds.

@WorldFallz, what do you propose as a solution?

I see everyone losing by handling this the current way. So how can this be a solution that serves the community? We're losing modules and a fine developer over some bad calls that could have been ironed out easily with some social sense for handling this.

A developer pours a lot of heart, time and knowledge into developing and maintaining a module, all this for free! Security is very important, sticking to guidelines too, but these rules weren't made to expel fine people for human errors. That's one of the reasons why I don't see this going anywhere, because it's not taking this into account.

You all got your point. SA-CONTRIB-2012-036 for Content Lock sure looks like bad judgement, calling this a critical issue. The maintainer didn't respond in time because he saw it as a non-issue, that's a bad call too. This has gotten pretty emotional, and while everyone is talking about being rational it's definitely not taking into account that no one was right in the first place.

I think an apology and reworking the policy for handling minor security issues would solve so much more than pounding on rules and arguing about who made what mistake.

Damien already described basically the only way forward we have at this point: http://drupal.org/node/1494212#comment-5765896.

@WordFallz, judging only by policy you're right.

To me this issue is completely missing any social competence on how to handle an issue like this. Send an email -> no reply -> action. Maintainer "removes" code from project -> action. A machine could've been programmed with the policy to make such a call, we don't need humans to make this kind of judgement. If people were in the same office they would have had a face to face talk first, maybe with a mediator and this wouldn't have gotten so out of hand. Handling a community not only needs people who are fine coders but also people with social competence for handling such situations. I don't think there was much, if any, personal face to face talk or at least a personal phone call before making these decisions. To me social competence and personal talks are key to a vital and happy community, that's why we have so many usergroup meetings, camps and the DrupalCon. For handling a dispute, social competence and face to face conversations are crucial and it's completely missing right now.

Policies exist to expel malvolent people who would otherwise destroy the community. A highly skilled developer who was just upset doesn't fall into the category of malvolent people these policies target.

You decided, thats the only option. So its buried. This issue is to be closed, enough time wasted ( of every participants ).

@troyer: there were three emails sent, not just one.

@troyer -- you seem to be ignoring the fact that by throwing a tantrum and deleting code from drupal.org it was the maintainer that abruptly ended any further rational discussion of how to best handle the situation. This was not a 'highly skilled developer who was just upset' -- code was deleted. That is a line that cannot be uncrossed. Git commit privileges are just that-- privileges. Abuse the privilege and it will be removed.

Sorry, but I have exactly zero tolerance for this type of narcissistic egotistical and childish behavior that seems to be consuming the world, let alone drupal.org. This 'my way or the highway' crap is quite antithetical and poisonous to an open source community and should not be tolerated for any reason-- not even for prolific and 'highly skilled' developers. No one is that important.

Gerhard, like I said it's a bad call not to reply to these emails. The signup terms for git access on drupal.org clearly state that one agrees to respond in time. At the time this was the right call. But the aftermath is out of proportion. Why's everything still locked down after it's clear that there's not a critical issue?

Policies aside, you both live in the same city, you know each other in person, so it would have taken as little as a phone call and settle things in person. It's definitely not a requirement on your side, especially since you have a lot of responsibilities, but it's a sensible thing to do and it would show some generosity to not just enforce a policy on a fellow in your local usergroup.

I'm not blaming you or anyone else, I just want to point out that policies lay a groundwork to handle technical issues but not how we should interact as human beings or as a community. If we don't take this into account the whole platform will deteriorate over time.

@WorldFallz, I'm not arguing with you on responsible behavior with git commit privileges. I'm just having a hard time that no one sees an obligation to have a personal talk that would have prevented a lot of what is now the aftermath of not talking with one another. It's easy to act upon simple logic of a policy, it's hard to make good calls on how to socially interact to prevent this in the first place.

@troyer: I wasn't involved in this particular security advisory at all and only learned about the issue after Eugen had already marked the releases unsupported and moved the code to github. Especially marking the releases unsupported is a rather destructive action, since every website using any of his modules (~ 10k, aggregated count), would get a nasty warning from the update status module. Also, his announcement that people shouldn't resurrect his modules on drupal.org or otherwise he'd make all his code unavailable is IMO rather disgusting and can only be seen as a thinly veiled blackmail attempt.

At that point, and especially since I know Eugen, I knew it would be very hard if not impossible to mend relations. I have to stress though that, at least in my opinion, I have no personal issues with Eugen. These are professional problems only.

However, I did try to not pull this issue too much into the public eye and created a rather technical issue at #1491720: What should we do when code for a project is migrated off of Drupal.org?. This was to keep things under wraps for a bit since most of the people whose input I would have valued there are at DrupalCon this week. Unfortunately, this failed.

Thank you Gerhard for that reply.

thats not sarcasm: You used "moved". Others use delete. Thank you.

. Also, his announcement that people shouldn't resurrect his modules on drupal.org or otherwise he'd make all his code unavailable is IMO rather disgusting and can only be seen as a thinly veiled blackmail attempt.

I get your POV, point given.
But you might also consider mine: I have no intentions maintaining duplicate work which is not even coordinated, as its mainly my spare time. So if those projects are took by the community on d.o i leave it to them, not participating as a maintainer on github, therefor closing down that repositories. It simply does not make sense having this on 2 different platforms. If people chose to not go with my wish and use the more comfortable way for the community to host on drupal.org, no matter this will be a long-term maintership or not.
Iam pretty sure, you have read those actions a bit different way.

At that point, and especially since I know Eugen, I knew it would be very hard if not impossible to mend relations. I have to stress though that, at least in my opinion, I have no personal issues with Eugen. These are professional problems only.

I leave that uncommented, can be cleared in a PM.

However, I did try to not pull this issue too much into the public eye and created a rather technical issue at #1491720: Code removed, what now?. This was to keep things under wraps for a bit since most of the people whose input I would have valued there are at DrupalCon this week. Unfortunately, this failed.

fair deal. A bit one-sided look on those points, but still fair. Thank you.

The discussion here seems mostly resolved and #1491720: What should we do when code for a project is migrated off of Drupal.org? is a more actionable issue on the same topic, so I'm marking this one as a duplicate.