[csw-maintainers] amendments and issues with recent prop

[Philip Brown]

On Mon, Jun 27, 2011 at 8:54 PM, Ben Walton <bwalton at opencsw.org> wrote:
> Excerpts from Philip Brown's message of Thu Jun 23 20:53:21 -0400 2011:
>
> Hi Phil,
>
> [In the future, please format your emails in a legible fashion.  It's
> very hard to read through the seemingly random line breaks, extra long
> lines, missing spaces, strange indentations, etc.]

Sorry, It's "gmail behaving badly", I suppose. (web interface).
I thought it was wrapping things appropriately, but I guess not. Suggestions
 on how to improve gmail configs
would be nice.

First of all, thank you for spending what was obviously considerable time
writing your response.
I appreciate that you were willing to put in that effort.

You went to more effort than I requested though. I only requested a re-review
 of 2-5.


On the negative side.. a chunk of what you wrote, was non-factual.
There was a chunk of ad-homimem attacks, and stating assumptions
about my motivation. You also spent many paragraphs writing about
"feelings".
Can we leave those out and have an objective discussion?

I will attempt to clip out all that stuff, and continue with a
fact-based discussion.

I also removed the parts where you factually responded to what I
wrote, such as #10.
Thank you for that.



>> 2. Amendment: Removal of "Anyone can participate[in the new
>> process]", and related lines.  This line falsely implies that
>> currently, people are somehow blocked from participating now.
>...
> In the sense of the proposal, this means that anyone is able to work
> on the code or documentation.  Anyone will be able to review packages
> and fully contribute to the QA process (regardless if their view lines
> up with yours).  Anyone will be able to suggest modifications to the
> process and if they're accepted, help implement them.

I think perhaps there is ambiguity of wording then. I was reading it
as relating to just the day-to-day flow of packages, but it seems you
intend it to cover more meaning that that.

The current summary merely reads, "1. Anyone can participate".
I would like to suggest you expand it to include the meaning that you wrote
 above.
Perhaps, "1. Anyone can participate in shaping the code, documentation,
 and the overall process itself"




>>[3] First of all, it implies, FALSELY, that a package can be completely
>> rejected by the release manager with no recourse. As formalized in
>> http://wiki.opencsw.org/release-manager , a maintainer can always
>> call for a vote if they disagree with the stance that the release
>> manager has taken. This has already happened, twice, and after the
>> vote, the package(s) were released, so it is a proven effective
>> method.
>
> First off, a vote is a new found power tool that didn't exist until
> the recent election (on paper yes, in practice no).  Before that it
> was your way or no way,
[assumptions and accusations about motivation snipped]

you're essentially contradicting yourself. past situations are irrelevant:
what matters is current policy. current policy is that people can
request a vote on this sort of thing. Additionally, it is more than
theoretical: it has been done so twice, AND I have abided by
the vote without further complaint. So it is a proven effective
tool.
Therefore, please adjust the wording.


>> 11. technical implementation issue:
...
>> Unfortunately, (as mentioned on maintainers list previously), making
>> the capability available, does not actually mean that people will
>> definitely make use of it.  The new proposal as prototyped,
>> currently allows for LESS people to scrutinize a package than
>> currently.
>
> Actually, it allows for more people to scrutinize a package, and more
> easily at that.

what you wrote, does not contradict what I said. The new system as proposed,
allows both "more people" and *also* "less people", unless hooks are
put in to specifically  require "at least one other person".



    ##########################################

This ends my official response to your comments on the proposal.
I hope you will take a little extra time to consider them.

Below, is a response to some (but not all of the ) incorrect things you
wrote, that I would like to respond to, even though they are not directly
 bearing on the above.



> Also, don't overlook the fact that currently packages might be
> submitted privately.  Any ensuing discussion at that point is private.
> The other party will still talk until they're blue in the face, but it
> won't be visible to anyone else.

You seem to be complaining on behalf of people who have no complaint.
I think I can accurately say that the people who choose to submit
packages privately to me, do so because we work well together, and they
that is the individual's choice. The people who do that, work well with
me. But if a problem occurs, they know that they always have recourse
to a public discussion of issues.


>  If
> we resorted to this every time a package was rejected based on your
> personal preference, we'd do nothing else.  Thus, _in practice_ you
> can and do reject packages on a regular basis.

This is a gross distortion of fact. You talk about "in practice". So,
"practically"
go do a count of how many packages have been "denied" in the manner
you describe, over the last 6 months.
(if you choose to do this, please be specific about package names)
No more than 3, I would guess.

1 vote every 2 months, is "doing nothing else"?
Please be more objective in the future.

> If you don't believe this, please review the list of stalled packages
> in [newpkgs]

you mean old files in newpkgs? that is not a valid way to tally this:
a lot of those are actually files that have just not been cleaned up properly,
when a maintainer submitted new files to fix issues with the older ones.
(sometimes due to renames)
a couple are ones that i myself should have removed on publishing,
 but missed them.
Some I think are ones where I pointed out clear, undisputed policy issues..
but the maintainer just forgot to come back to them.

If you took the time to actually go through the pkgsubmissions list and count
that way, I think it would be close to my estimate of 3 in 6 months.

I've taken the liberty to clean up some of the bogus lagging ones now.
but the others are
still there for now, simply because its a lot of hassle for me to go
dig up specifics for each
and every one.


> Thirdly, the wiki page you linked to [about release managers]
> was only just written when
> csw-upload-package was originally floated.  It is something you wrote
> without soliciting any input or feedback.  You now provide that as a
> reference to policy?


I wrote that as a summary for what I do in pratice. I consider that a
"draft policy"; it describes our "de facto" existing policies accurately,
I think. It seemed appropriate that if people were voting against
"a release manager", they should at least have some definition about
what a release manager is and does.
If people cared enough about having a release manager, to have a
separate vote/discussion on that page, I'd be happy to see it amended.


> If this is true, why were there no votes in the two years you yourself
> were on the board?  Why did every issue raised end with the other
> person giving up?

I would guess for two reasons:
1. we did not have a nice method of voting during that time
2. people may have incorrectly assumed that since I was President, I would
 either not allow the vote (ahem, sounds familiar), or not abide by it.
In both cases, such assumptions would have been incorrect.


[bit about technical issue resolution, moved to separate email,
  "tech board?" ]



>> 5. Removal of "unclear path to resolution of disputes" claim.  There
>> is actually a clear path: discussion on pkgsubmissions list ->
>> discussion on maintainers list -> vote if needed.  As far as
>> complexity, this is virtually identical to the "new" path to
>> resolution.
>....
>
> Currently it can take a "**month or more**" to get good packages out
> the door.

only very very rarely.

In real-world QA, that sometimes happens.
In the NEW system, that will most likely happen sometimes too.
Are you planning to put in some kind of "hey this has been waiting,
lets ignore all bug reports and publish it"! system?
If not, then this is a bogus comparison.