We can discuss this at our next meeting.

Perhaps a lot of this would be good to update or add to:
http://fedoraproject.org/wiki/Package_maintainer_responsibilities

I'm not sure I agree with your overview or proposed solutions, but we can discuss further at the next meeting and see what we are interested in persuing.

Looks like some of what I proposed would be good update or add to http://fedoraproject.org/wiki/Package_maintainer_responsibilities but out of curiosity who is actually overseeing that packagers/maintainers are following that in the first place?

I suppose FESCo in the end. There's no one I know of checking around and interviewing maintainers for compliance. I would expect if you see someone not following that that you should point them to it politely, and if there is a further issue, bring it to fesco's attention. There's no manpower I know of to examine all maintainer output.

Well first of all there's no point it setting policy's in the first place if there is nobody to make sure those policy's are being followed that's just waste of time.

I would think whom/whatever stamps "approved" on packager/maintainer is the one who is responsible for reviewing his performance after half a release then again after full release cycle.

I think there are number of good reasons to have a clear policy, even if there is insufficent manpower to police up front all possible violations of it.

Sure, see http://fedoraproject.org/wiki/Packager_sponsor_responsibilities for packager sponsors.

Lets let fesco read this and discuss your ideas. Thanks for the input.

Replying to [comment:4 johannbg]:

Well first of all there's no point it setting policy's in the first place if there is nobody to make sure those policy's are being followed that's just waste of time.

Thinking that enforcement is more important than having policies seems like a bad assumption to me. Policies without enforcement can set expectations and allow people to point you at the policy if you are violating it and causing problems. A concentration on enforcement can often cause extra work which sometumes is large enough that it disheartens people who would follow the policy anyway which can sometimes be an unwise direction.

The entity that implemented the policy has to be also actively monitoring the result of that implemented policy especially if people are using that policy to measure it's efficiency so it can take any kind of action based upon that like improving the policy or to see if there is a need to force or not force it etc.

• Require them and prove to have upstream bugzilla account before their package get accepted in the distribution before their component gets accepted in the distribution.

Not every upstream has a bugzilla.

• Require them and prove that they are either a part of or in good communication with the upstream before their component gets accepted in the distribution.

We have packages where upstream is effectively dead or don't communicate with us.

• Require them to demonstrate that they are familiar with the programming language the component they are introducing to the distribution is written in.

Why? Familiarity with the language says nothing about familiarity with the internals (and concepts) of the software. Therefore enforcing this rule can do more harm than good.

• Require them to provide test cases.

I'd rather not comment on that...

First implement and apply the above to all existing packages and allow current maintainers an adjusting period to provide the above required information.

Implementing a policy that will strip their packaging rights and orphan the package if they do not respond to bugs and bug reports against their component in a given time frame.

If no one claims the package drop the package from the distro.

I cannot wait for the breakages when some package is dropped in the middle of the release because no one wants it (or no one from those who would take it can fulfill the requirements)...

Implement a policy regarding ownership of packages in essence the packager/maintainers is responsible for the package but does not own it in any sense as in if another maintainer wants to fix etc to his package he can not prevent him from doing so.

So, after the hassle the maintainer had to go through to be deemed qualified, anyone else may simply change the package and the maintainer is not allowed to prevent it? What do you smoke?

Implement a firm bugzilla interaction policy which at least requires them to be the middle man between the report and upstream as in they can not just point the finger upstream when a report comes in, it does not scale for reporters.

OTOH, mediating several tens or even hundreds of bug reports between the reporter and upstream scales just fine...

Replying to [comment:8 dtardon]:

• Require them and prove to have upstream bugzilla account before their package get accepted in the distribution before their component gets accepted in the distribution.

Not every upstream has a bugzilla.

Or equivalent.

• Require them and prove that they are either a part of or in good communication with the upstream before their component gets accepted in the distribution.

We have packages where upstream is effectively dead or don't communicate with us.

Which begs the question if we should ship those packages et al.

Atleast they should be opted out from bugzilla abrt etc since any bugs reported against those packages wont get fixed anyway.

• Require them to demonstrate that they are familiar with the programming language the component they are introducing to the distribution is written in.

Why? Familiarity with the language says nothing about familiarity with the internals (and concepts) of the software. Therefore enforcing this rule can do more harm than good.

How can you effectively fix any reports against the component if you are not familiar with the language he's written in?

• Require them to provide test cases.

I'd rather not comment on that...

I only mentioned that because process like proven testers wont work effectively without it.

First implement and apply the above to all existing packages and allow current maintainers an adjusting period to provide the above required information.

Implementing a policy that will strip their packaging rights and orphan the package if they do not respond to bugs and bug reports against their component in a given time frame.

If no one claims the package drop the package from the distro.

I cannot wait for the breakages when some package is dropped in the middle of the release because no one wants it (or no one from those who would take it can fulfill the requirements)...

Package would of course get dropped after release has effectively been EOL

Implement a policy regarding ownership of packages in essence the packager/maintainers is responsible for the package but does not own it in any sense as in if another maintainer wants to fix etc to his package he can not prevent him from doing so.

So, after the hassle the maintainer had to go through to be deemed qualified, anyone else may simply change the package and the maintainer is not allowed to prevent it? What do you smoke?

Absolutely nothing that does not grow from the ground itself.

If you are the individual that brought the package to the distribution you should be responsible for it while you maintain it however you should not effectively stand in the way if the need arises for other maintainers step to in to fix things and or do some other required changes.

Implement a firm bugzilla interaction policy which at least requires them to be the middle man between the report and upstream as in they can not just point the finger upstream when a report comes in, it does not scale for reporters.

OTOH, mediating several tens or even hundreds of bug reports between the reporter and upstream scales just fine...

Aren't we speaking of the same thing here ?

Replying to [comment:2 johannbg]:

who is actually overseeing that packagers/maintainers are following that in the first place?

The community, this includes everybody. If you have a problem with a certain maintainer, please bring it up.

Replying to [comment:4 johannbg]:

Well first of all there's no point it setting policy's in the first place if there is nobody to make sure those policy's are being followed that's just waste of time.

IMHO we should follow the presumption of innocence, this means we should trust package maintainers to do their job (until proven the opposite) instead of controlling them.

Replying to [comment:10 cwickert]:

Replying to [comment:2 johannbg]:

who is actually overseeing that packagers/maintainers are following that in the first place?

The community, this includes everybody. If you have a problem with a certain maintainer, please bring it up.

One way is to mobilise reporters to flush out those non responsive maintainers on reports ( For example EOL reports with no input from maintainer ) before doing so some policy needs to be in place for that and or some guideline to follow.

Replying to [comment:4 johannbg]:

Well first of all there's no point it setting policy's in the first place if there is nobody to make sure those policy's are being followed that's just waste of time.

IMHO we should follow the presumption of innocence, this means we should trust package maintainers to do their job (until proven the opposite) instead of controlling them.

Depends on what you mean by controlling them requiring them to accept a certain level of responsibility and requiring them to provide information to QA to work with is not too much to ask from my stand point.

Ask you self this why are we ( QA ) implementing various process for maintainers to follow?
What problems do you think we are trying to solve?

( then you can ask your self if we should not be rewarding responsive maintainers by cutting them some slack from some of those process but that's a different matter )

The only way for us to effectively improve reporting is to provide the reporter with the information that the packager/maintainer requires on his report and the only way QA can do that is if the packagers/maintainers provide us with the information on what they need and how to get that information from their components.

Anyway the only way to effectively assess the situation and the effects of the policy we have to start actively measuring it as opposed deal with on case by case bases.

For example.

How many packagers/maintainers followed the previously mentioned policy for F12 release cycle?

When that has been done action can be taken based on the findings and policy adjusted accordingly that is if it's needed.

I do believe the community in whole might can do better in this area.

Replying to [comment:9 johannbg]:

• Require them and prove that they are either a part of or in good communication with the upstream before their component gets accepted in the distribution.

We have packages where upstream is effectively dead or don't communicate with us.

Which begs the question if we should ship those packages et al.

Maybe because they "just work"?

Atleast they should be opted out from bugzilla abrt etc since any bugs reported against those packages wont get fixed anyway.

And maybe the packager knows the package and is able to do the necessary fixing himself. Wait, isn't that what you demand for all packagers?

• Require them to demonstrate that they are familiar with the programming language the component they are introducing to the distribution is written in.

Why? Familiarity with the language says nothing about familiarity with the internals (and concepts) of the software. Therefore enforcing this rule can do more harm than good.

How can you effectively fix any reports against the component if you are not familiar with the language he's written in?

How can you reliably fix any report against the component if you are not reasonably familiar with the component's code? The language is not all...

• Require them to provide test cases.

I'd rather not comment on that...

I only mentioned that because process like proven testers wont work effectively without it.

The process IMHO won't work even with it... You're trying to imitate Red Hat QA's process without the manpower, with much larger package collection and with several times larger amount of updates.

Implement a policy regarding ownership of packages in essence the packager/maintainers is responsible for the package but does not own it in any sense as in if another maintainer wants to fix etc to his package he can not prevent him from doing so.

So, after the hassle the maintainer had to go through to be deemed qualified, anyone else may simply change the package and the maintainer is not allowed to prevent it? What do you smoke?

Absolutely nothing that does not grow from the ground itself.

If you are the individual that brought the package to the distribution you should be responsible for it while you maintain it however you should not effectively stand in the way if the need arises for other maintainers step to in to fix things and or do some other required changes.

We already have that--it's called provenpackagers. And you haven't answered how it helps "the overall quality of distribution" if, on one side, maintainer of a package is required to be familiar with it, but, on other side, anyone, possibly without any 'qualification' at all, may "step in to fix things".

Implement a firm bugzilla interaction policy which at least requires them to be the middle man between the report and upstream as in they can not just point the finger upstream when a report comes in, it does not scale for reporters.

OTOH, mediating several tens or even hundreds of bug reports between the reporter and upstream scales just fine...

Aren't we speaking of the same thing here ?

No. I was being sarcastic.

Maybe because they "just work"?

Congratulation for finding the first bug free code and since they are handing out the Nobel prize to just about anyone these days don't be surprise if you suddenly receive yours...

Atleast they should be opted out from bugzilla abrt etc since any bugs reported against those packages wont get fixed anyway.

And maybe the packager knows the package and is able to do the necessary fixing himself. Wait, isn't that what you demand for all packagers?

That effectively would make him upstream would it not ;)

How can you effectively fix any reports against the component if you are not familiar with the language he's written in?

How can you reliably fix any report against the component if you are not reasonably familiar with the component's code? The language is not all...

I guess we can then agree a skill of both would yield the best result..

The process IMHO won't work even with it... You're trying to imitate Red Hat QA's process without the manpower, with much larger package collection and with several times larger amount of updates.

Good that you keep track how many of us are in Fedora QA care to share that number with the rest of us we are always interesting in knowing how many we are.

For me to imitate Red Hat QA's process I would have to be familiar with it and somehow Red Hat forgot to send me the manual on that one.

Beside that I'm not one of those individuals that refuses to accept,learn and implement something that other are doing good job regardless if it happens to be Red Hat or someone else only for the sake of reinventing the wheel.

And me mentioning that we could learn something from Red Hat says more about their QA process than it does about anything else.

We already have that--it's called provenpackagers. And you haven't answered how it helps "the overall quality of distribution" if, on one side, maintainer of a package is required to be familiar with it, but, on other side, anyone, possibly without any 'qualification' at all, may "step in to fix things".

I never proposed nor mention anything on what was the best way to implement that but your point is noted encase I do.

Replying to [comment:13 johannbg]:

Maybe because they "just work"?

Congratulation for finding the first bug free code and since they are handing out the Nobel prize to just about anyone these days don't be surprise if you suddenly receive yours...

I am tempted to open a ticket about the improvement of the general standard of arguments in discussions in FESCo tickets.... If there is there are bugs in software, report them or do not use them. But do not make it hard for other people to use it, if they want or have to for whatever reason.

Atleast they should be opted out from bugzilla abrt etc since any bugs reported against those packages wont get fixed anyway.

And maybe the packager knows the package and is able to do the necessary fixing himself. Wait, isn't that what you demand for all packagers?

That effectively would make him upstream would it not ;)

How can you effectively fix any reports against the component if you are not familiar with the language he's written in?

How can you reliably fix any report against the component if you are not reasonably familiar with the component's code? The language is not all...

I guess we can then agree a skill of both would yield the best result..

Your ticket is not about what is supposed to be ideal, but what is required from every package maintainer. And it seems to be very unrealistic, because you demand that every package has a healthy upstream and that every package maintainer is skilled enough to be upstream of his packages, too. I am very sure that there are not that many package maintainers that fit into this description. And even in practise there is not a big difference for a user between a bug not being fixed by a skilled maintainer that does not have enough time to fix all bugs (see the kernel package) or a less skilled maintainer that cannot fix a certain bug, because he is not that familiar with the code of a certain package.

Your ticket is not about what is supposed to be ideal, but what is required from every package maintainer.

Yes because I feel that the "ideal" way is not working.

And it seems to be very unrealistic, because you demand that every package has a healthy >upstream and that every package maintainer is skilled enough to be upstream of his packages, >too.

Yes thus improving the general standard of packagers/maintainers in the distribution.

Ask you self this for whom are these people introducing the component their supposed to be maintaining for themselves or for the general end users.

When package is being shipped that is broken on whom do you think it reflects badly upon the packager/maintainer or the project in whole. . . .

I am very sure that there are not that many package maintainers that fit into this description. >And even in practise there is not a big difference for a user between a bug not being fixed by >a skilled maintainer that does not have enough time to fix all bugs (see the kernel package) or >a less skilled maintainer that cannot fix a certain bug, because he is not that familiar with >the code of a certain package.

Skilled or not it's very understandable that some maintainers do not have the time to fix all bugs however it does not excuse them from simply mentioning that on a report against his components it takes two minutes.

"I've looked at your report and it's not on my trop priority list I expect to get to it after the holidays and when I'm done with bugs x z y thank you for your report"

Let's walk through this and I try to explain this better.

• Require them and prove to have upstream bugzilla account ( or equivalent )before their package get accepted in the distribution before their component gets accepted in the distribution.

If you are unable to maintain package for whatever reason then you should at least be the liaison between upstream and the distribution so when reports come in against your component you can effectively forward the ticket upstream and from upstream back again to the reporter.

• Require them and prove that they are either a part of or in good communication with the upstream before their component gets accepted in the distribution.

Same as the above.

• Require them to provide how to debug and minimal information a report needs for the component they are introducing into the distribution.

This information is very vital to have improve the report and to reduce as much unnecessary back and forth between maintainer and reporter this will also demonstrate if the packager is qualified enough to maintain the packages ( if he does not know how to debug his own package who does... ) QA should not need to be running after maintainers begging them to give us information on how to debug their own component! They should just be obligated to provide us with that information.

• Require them to demonstrate that they are familiar with the programming language the component they are introducing to the distribution is written in.

Has been discussed here above.

• Require them to provide test cases.

This I is strictly mentioned to point out that for something like proven testers to work maintainers need to provide test cases for their component.

I'm on different view than some of the other members in QA in relation with proven testers it's flawed in some many ways which requires so much more to get right which will result in more burden on maintainers that it already is.

The rest I proposed are just implementation proposals.

If what it takes to stop asking and starting requiring instead we should be able to reduce some of the QA bureaucracy that is being imposed on all maintainers for the incapability of the few I mean I see absolutely nothing wrong with that if you have proven that you either are upstream or in good relation with upstream and you shown that you react and respond to bugs and fix them in timely manner and you have provided QA with the necessary information on debugging your component that you as a maintainer are given the trust and be allowed to bypass some of those QA bureaucracy that currently exist.

Notting is going to look at folding these into our maintainer responsbilities.
I am going to look at talking to FPC to see if they could be added as SHOULD or suggestions in package reviews and/or to a standard review template.

Will leave this open for those actions.

The FPC's mandate is "How to package". They leave questions of what to package and who can package to other groups. So:

• Require them to provide how to debug and minimal information a report needs for the component they are introducing into the distribution. Reviewer can pass the info to ticket in the QA trac instance where we will make it ready for the QA community wikify it etc.

• Require them to provide test cases.

These are the only two suggestions that might fall under the how to package jurisdiction. I personally would be against either of them on the grounds that it raises the bar on what it takes to be a packager at all when what we're trying to do is include, nurture, and grow good packagers without a clear idea of how to do it right. QA needs to create the infrastructure and expectations on what kind of testcases, debugging instructions, etc they would want package maintainers to provide before I'd consider a +1 to be a possibility. Even then I'm not sure that I would vote for it.

In an advisory role, I think the idea of adding these (the broader these of all the suggestions) to the package maintainer tips and tricks pages might be best -- I'm +0 on adding them to the official-ish package maintainer responsibilities page as suggestions for people to follow. Tips and tricks seems more appropriate but that might just be bike-shedding if it's non-mandatory in either place.

A couple hints for the reporter: Package maintainers are maintaining their packages for themselves. They contribute them to Fedora and put in time making them usable for others but in the end, the package and packaging must be rewarding to them personally or they will not continue to package (at least, that particular piece of software).

Making demands and attempting to enforce compliance are a poor way to get things done in Fedora. Come up with plans that educate people on how to be better packagers by doing these things and you'll have a lot more success as you're increasing the benefit to the people doing the packaging.

Replying to [comment:17 toshio]:

The FPC's mandate is "How to package". They leave questions of what to package and who can package to other groups. So:

• Require them to provide how to debug and minimal information a report needs for the component they are introducing into the distribution. Reviewer can pass the info to ticket in the QA trac instance where we will make it ready for the QA community wikify it etc.

• Require them to provide test cases.

These are the only two suggestions that might fall under the how to package jurisdiction. I personally would be against either of them on the grounds that it raises the bar on what it takes to be a packager at all when what we're trying to do is include, nurture, and grow good packagers without a clear idea of how to do it right. QA needs to create the infrastructure and expectations on what kind of testcases, debugging instructions, etc they would want package maintainers to provide before I'd consider a +1 to be a possibility. Even then I'm not sure that I would vote for it.

Debugging might have been a bit poorly phrased from me.

Let me try to rephrase that for better understanding what I'm getting at.

The information we ( QA ) essentially need from packagers/maintainers is what's needed for the best and or minimal possible report from reporter for the packager/maintainer to work on the report so when either a triager or a packager/maintainer changes a status to NEEDINFO on a report he can post a link to a wiki page we ( QA ) have prepared for the reporter with instruction on how to provide that necessary information.

To give you example for the new and upcoming feature Systemd that would have a report against it that does not contain the necessary information from a reporter.

"The information you have provided on your bug report does not contain the necessary information for the maintainer to work on your report please follow the instruction on https://fedoraproject.org/wiki/How_to_debug_Systemd_problems to identify the area you are experiencing problem with and provide the maintainer with the necessary information to effectivly work on your report.

Thank you."

In this case as was also with Dracut both Lennart and Harald only provided me with absolute necessary information ( One maybe two lines in email/irc ) they need to effectively work on the report I then proceeded with writing a step to step guide for reporters which then James, Paul or Adam fix my not so good English followed by the maintainers themselves to review after I ping them and they modify the page has the code changed from the initial time of writing.

I however am very particular when writing the necessary guide for reporters to follow since I believe that a guide needs rewriting if a reporter becomes confused or uncertain when following it and under no circumstances should the reporter have to run around the whole internet obtaining that information however not all share that point case in point being https://fedoraproject.org/wiki/How_to_debug_Firefox_problems which have been touched by Paul Adam Christoph and James and Fenris02 who's real name I do not know vs what I wrote https://fedoraproject.org/wiki/How_to_debug_Thunderbird_problems these components are so close related in reporting that you could effectively s/thunderbird/firefox...

In an advisory role, I think the idea of adding these (the broader these of all the suggestions) to the package maintainer tips and tricks pages might be best -- I'm +0 on adding them to the official-ish package maintainer responsibilities page as suggestions for people to follow. Tips and tricks seems more appropriate but that might just be bike-shedding if it's non-mandatory in either place.

A couple hints for the reporter: Package maintainers are maintaining their packages for themselves. They contribute them to Fedora and put in time making them usable for others but in the end, the package and packaging must be rewarding to them personally or they will not continue to package (at least, that particular piece of software).

If this is the case does it not contradict the whole stable vision?

Making demands and attempting to enforce compliance are a poor way to get things done in Fedora. Come up with plans that educate people on how to be better packagers by doing these things and you'll have a lot more success as you're increasing the benefit to the people doing the packaging.

Duly noted unfortunately sometimes one has to scream to be heard.

Hello everybody!
A newcome package maintainer speaking here, so please be gentle :)

I had mixed feeling on this proposal: on one hand who wouldn't want more quality and stability in Fedora? On the other I got a bit scared about the idea of enforcing all the topics discussed here. I mean, I like to learn new things and to make positive contributions but why should you threaten me to orphan my package and kick me off of the community if I have difficult fixing it or I'm not learning ThisReallyWonderfulLanguage fast enough to be able to fix it myself? In any case I'm putting my spare time and best effort into doing something for the community. Moreover, driving away contributors simply mean that they will flee towards more friendly communities!

Instead, while reading this post, the following idea occurred to me:

What about starting a "learning program" for contributors?

The idea is that I come here, wanting to give something back to Fedora but not knowing enough. Someone contacts/sponsors/notices me and explains that there are various levels as a contributor. I will start in the lower one and he will nurture me to the high levels if I want. In the process there are things to learn (a programming language, a versioning system, making patches, submit and fix bugs, use fedora infrastructure etc etc..) and things to do (make a review for an other package, have a package approved, submit an update, show that I know and apply the QA rules etc...). When I'm ready, we will meet again, give me feedback and I can change level. Other people can see that now I'm a level 2 packager and so on.

A nice addition to the aforementioned idea is that each right thing that I do will earn me karma points (like lauchpad's ones) and each error (e.g. submit a package to stable without waiting enough time) will have some (small!) negative punctuation. Like in launchpad, karma could diminish over time to encourage people involvement into the community.

I think that this can meet all the needs of the proposal in this ticket, without leaving bad taste in the mouth.

It will provide a way to:
* knowing what a contributor knows, does and how he usually behaves.
* knowing if he always makes the same errors, if his sponsor helps him enough and/or if he keeps abusing of the infrastructure or breaking the policies.
* encouraging him to increase his commitment in the community
* provide a cheap reward system (seeing his level rise and his karma move with time) to guide him to the good practices
* better define what does being a good contributor mean.

Well... these are just my two cents :)

Best regards,

Mario

Not a bad idea but instead of actually packaging and shipping something from the start you first would have to be a co-maintainer for your "mentor" and his packages for a release cycle or so before you would start shipping your own from my perspective anyway regardless of any learning process we still need to get necessary QA related information from packagers/maintainers one way or another..

Several things to note here:

• FESCo is simply looking at adding some of these items as "nice to have" or "if you can do this that would be great", there's not going to be any punishing people or the like.

• The Board recently mentioned topics they are going to work on over the coming year, and Mentoring was one of them. ;) I think a mentoring program like you mention would be a great addition. We will need to see how and what we can get implemented.

So, no need to worry. ;)

That would be great!

Thanks for the explication and waiting for the mentoring program then :)

Cheers,

Mario

Replying to [comment:21 kevin]:

• The Board recently mentioned topics they are going to work on over the coming year, and Mentoring was one of them. ;) I think a mentoring program like you mention would be a great addition. We will need to see how and what we can get implemented.

Just a few notes about this:

• The topics that the Board proposed as goals to work on is a preliminary brainstorming at this point. They're going to winnow it down to two or three things that they want to work on happening.

• The Board as an entity (not the individuals who make it up) has an interesting definition of "work". The Board as a whole is largely powerless and depends on two things:

• Board members who feel strongly enough about things (and have enough time) to push forward on projects that align with what the Board wants.

• People who feel strongly enough about things (and have enough time) to push forward on projects that align with what the Board wants.

As you can see, there's really nothing special about being on the Board in terms of getting stuff done.

So if mentoring is part of the goals that the Board decides to work on for the coming year, I'll be trying to recruit people to help figure out how best to mentor and educate new (and existing) packagers. But I'm just one person so I'll be building up a body of other people who end up doing a lot of the work. If someone else steps up first and says that they have some ideas for how to implement mentoring of contributors to Fedora, I'd be more than happy for them to do the job instead and I'd end up helping them to see that their vision was fulfilled :-) .

Replying to [comment:16 kevin]:

Notting is going to look at folding these into our maintainer responsbilities.
I am going to look at talking to FPC to see if they could be added as SHOULD or suggestions in package reviews and/or to a standard review template.

Will leave this open for those actions.

Done, changes are at: https://fedoraproject.org/w/index.php?title=Package_maintainer_responsibilities&diff=212270&oldid=212266

Closing; please file new tickets with further ideas.