How about as a first step we appoint a mediator and ask them to talk with him.
See if they can get him to change workflow/stop doing this.
They may carry more weight when officially appointed by us.

Reply by pfj via email:

Hi,

I know i and Toshio at least and probably others have spoken with
him
about
making sure he does not blow away other peoples changes.

Never has happened.

While I will admit that occassionally I have missed the odd diff (and
it's not that often when you consider how many times mono has been
updated in rawhide), the majority of the imports takes account of them.
Mono is a hideously nasty package sometimes with lots going on which
means that reverting some of the previous patches does occur (for 2.6.1
a pile of them went).

Of course, I will happily have a moderator talk with me about this as I
feel it is a priviledge to be a contributor to such a fast moving
distro.

TTFN

Paul

P.S. Happy new year folks!

Replying to [comment:2 toshio]:

Reply by pfj via email:

Hi,

I know i and Toshio at least and probably others have spoken with
him
about
making sure he does not blow away other peoples changes.

Never has happened.

Replying to this portion, I have emailed about this and other problems with the mono stack. However, one of the glaring problems is that I have only received responses from Paul a few of the times I've emailed. This could be a technical issue (spam filters or some such) but the result is a lack of communication about packager issues. In the case of changes getting blown away when Paul makes commits later, this lack of communication is especially frustrating as there's no acknowledgement of the problem and no written communication of how Paul is going to change his workflow to stop causing this problem.

While I will admit that occassionally I have missed the odd diff (and
it's not that often when you consider how many times mono has been
updated in rawhide), the majority of the imports takes account of them.
Mono is a hideously nasty package sometimes with lots going on which
means that reverting some of the previous patches does occur (for 2.6.1
a pile of them went).

In ausil's case we're not talking about the patches that are applied to the source code. We're talking about changes inside of the spec file. For instance, to include certain architectures in the build. That those changes have been dropped repeatedly is negligent. The first step should be to help Paul change his workflow so that CVS tells him when changes are outstanding and he can merge those changes instead of overwriting them. Lack of being able to establish communication is what lead to this ticket.

Of course, I will happily have a moderator talk with me about this as I
feel it is a priviledge to be a contributor to such a fast moving
distro.

A moderator would be a good thing, I think, as that would keep the communication flowing while we resolve the outstanding problems. If communication flow stops in the presence of a moderstor we know we have deeper issues.

As an additional note, I've talked to one member of the present set of mono packagers. He is somewhat miffed that his emails to Paul have also gone unanswered. However, Paul does a great service to the community by caring for some mono packages that have no other maintainers. If we could just figure out why emails with Paul don't elicit any response and remedy that he'd be happiest.

One method of communication that we don't know if Paul is aware of (he's been emailed about it but there was no response) is https://admin.fedoraproject.org/mailman/listinfo/fedora-mono . The currently active mono package maintainers have been collaborating here and would really benefit from having him join in the discussions as well.

Paul: would you care to reply to toshio's comment here?
What is your email situation? Can you join and post to the mailing list with the other mono contributors?

Paul is trying to fix his email/filtering issues, and has stopped using the script he was using that was removing changelog entries.

Removing this as a meeting item for now.
We can revist in a week or so and confirm that things are better?

Paul: Is there any update here? I don't see any posts from you on the mono list.
Have you gotten your filtering figured out?

Paul: Any news? I sent you email offering to assist in tracking down any bounces you are getting. Either find me on irc.freenode.net in #fedora-admin (nick: nirik) or drop me an email and we will get this fixed.

At todays FESCo meeting we decided to wait another week here, but we would really like to know that the communications issues are dealt with. We will revist at next weeks meeting.
Please work with us to get this solved. ;)

I'll chime in here too - I just looked on the box that houses the mailing lists, and I see you subscribed to several, just not the mono list.

Also, feel free to email me directly or ping me on #fedora-admin (jds2001) for help. Help us help you, man :)

I'd guess this ticket is solved? Paul is on the lists and I have not heard anything further about issues.

Shall we close this ticket now? Or is there anything new to address?

Paul,

while you're at it, could you please check also your bugzilla mail preferences and filtering? Tickets are waiting for comments/action from you. Several have been closed at dist EOL already without any sign of life from you. You might want to "orphan" and give away "xmms", for example.

Hey Paul.

It seems there's some continuing issues going on that I've noticed, and in turn I would like to bring to your and FESCo's attention:

1. You seem to have checked in the mono source directly to git with your recent updates. :( This means a clone of the fedora mono git repo takes up tons of space/Bandwith, and due to the way git works, I don't think we can never get rid of it. :(

http://lists.fedoraproject.org/pipermail/scm-commits/2011-March/578098.html

1. You still seem to be checking in complete spec files that just overwrite all the history in git.

http://lists.fedoraproject.org/pipermail/scm-commits/2011-March/578096.html

Not sure what we can do here moving forward, but some suggestions:

1. Could you just submit your changes to the mono sig/list and have someone who understands our git workflow commit them for you?

2. Could we get you a mentor to do the above and assist with workflow?

3. Would you be willing to let someone else be primary maintainer on those packages and provide patches to them?

I don't mean to discourage your contributions, but the above makes it hard for any other folks being willing to contribute to those packages. ;(

Oops. Typo: "I don't think we can never get rid of it." should be "I don't think we can ever get rid of it"

Additionally:

• boo
• mono-debugger
• nant

Also have binaries checked into git. ;(

We should determine a policy here... if we remove the binary and change the hash that was used for official builds or leave them in the repo forever.

I would suggest commit hooks which prevent checking in files with common archive extensions (.tar, .tgz, .bz2, .zip etc) and very large files (perhaps larger than 1MB).

Several actions came out of today's fesco meeting:

1. we are removing Paul from provenpackagers for now.
2. We still hope to hear from Paul and will revisit any further actions next week.
3. We will see if we can re-write history on the git repos with source checked into them.
4. We will see if we can add a git hook to stop this from happening again moving forward.

How does this ticket affect the status of pfj as a sponsor?[[BR]]
pfj is also a sponsor member and (from my script) he actually sponsors 7 people. In my recognition currently all sponsor members are also provenpackager members (and we assume that a sponsor must have an ability to be provenpackager).

Good question. I did not realize he was a sponsor. I would think we would want to remove this access as well for now, but will ask other fesco folks what they think.

Note that what I am concerned about is that while I want to leave it to FESCo's judgement whether pfj's sponsor status should be revoked or not, I am not sure whether his sponsornees may have to find out new sponsor or not if that happens.

No, they shouldn't. sponsorees who's sponsor is no longer active should become sponsored by fesco itself. They should feel free to ask fesco members for advise or help. I don't see this documented anywhere, but I am pretty sure we covered this when we had sponsors leave the project in the past.

At today's fesco meeting we:

• removed Paul's sponsor status for now.

• agreed to mail his sponsor and ask if he could help Paul with workflow or communication issues.

• Agreed to revisit this in a while and see if any additional steps need to be taken.

Also, with the binaries in git, we opened the following tickets:

https://fedorahosted.org/fedora-infrastructure/ticket/2678
https://fedorahosted.org/fedora-infrastructure/ticket/2679
https://fedorahosted.org/fedora-infrastructure/ticket/2680

Will leave this ticket open to track progress/revisit.

Shall we close this ticket now?

I think so.