On 06/18/2013 06:24 AM, David Tardon wrote:
On Mon, Jun 17, 2013 at 09:49:37PM +0000, "Jóhann B. Guðmundsson" wrote:
From my point of view If you are not involved with upstream ( at
least subscribed to their mailing list and have a account in their
upstream tracker ) you should not be maintaining package in the
distribution but should instead just be maintaining it in a side
repo.
That is your opinion. Others can have their own opinions about the
matter.
I never said they could not are you implying that I cant?
Agreed but at least they should know how to debug their own
components which when I started the how to debug initiative a while
back in QA revealed many of them did not even know how to do that.
And how is this relevant here?
This for example is relevant to debug the component in question and or
provide that reporter with that debug information encase he needs to
provide the packager with the proper report so the packager can forward
the proper information upstream.
Basic triage stuff really...
So here is where I see things go wrong for many packagers they fail
to understand or rather we fail to provide proper info on how much
time it takes to maintain a package in the distribution.
Because there is no way to quantify that. Because the world is not black
and white and it differs from package to package.
Yes there is a way to quantify that and provide an base time at best
conditions
2) There's a 100% chance that I don't have the time between work and
family obligations.
We do not need unresponsive or poor maintained packages in the distribution
and if there is really need or demand for the component you maintain,
co-maintainers will appear or people to pick it up if you drop it so if you
dont have the time to properly maintain your component(s) in the
distribution then either find yourself co-maintainers or drop the package.
Again, our key disagreement here is on the definition of "proper
maintenance". I have more than enough time to keep up with new
versions as they are released (most of the time) or to pull a patch
out of the upstream's version control and add it to the package. But
even if I had the hardware I don't have the kind of time it takes to
set up test environments to reproduce a bug, and then dig into the
code and find the bug, develop a fix and then test it.
When you decide to maintain a component in the distribution you need
to ensure that you have enough time to perform steps a) b) c) d) and
e) not only steps a),b) and c).
What are these steps?
The once that you conveniently cut out when responding to this.
The load or rather the time of the maintenance can however be
distributed between co-maintainers and between existing sub
communites in the distribution or for packagers/maintainers
themselves by building a sub-community surrounding the component(s)
in question.
I see two interpretations of the above paragraph:
1. You imply that the solution is to put every existing maintainer into
several groups/sub-communities.
2. You think that there are hordes of people eager to become
co-maintaineres, if only we had given them the chance.
Both are wrong.
No you interpretation of my response is wrong.
Agreed that's inefficient but it's still a necessary and unavoidable
part of maintainers responsibility from my point of view.
It is by no means unavoidable. In fact, it is very easy to avoid.
Yes at this point in time you can ignore bugs all you want and nobody
said you could not but rather you should not.
Says who? The people around here are _volunteers_, not slaves. One does
not create a community by forcing rules on others.
Trying to follow your logic hence the question do o you think we
increase our user and contributing pool by delivering broken components
in the hands of our userbase?
Anyway just because you are volunteering does not mean that you are an
slave, cannot follow a set or rule or we cant have one.
This is purely your interpretation.
Yes this is my interpretation and findings after being over 5 years in
the QA community, working on feature that spans multiple packages and more.
I'm allowed to have one right?
JBG
--
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/devel
