[csw-maintainers] amendments and issues with recent prop

[Ben Walton]

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.]

> 1. Amendment: more technical details need to be given.  (perhaps as
> a side referenced document) The proposal suggests that opencsw adopt
> a "new system", without *fully* *defining* this new system at a
> technical level. There are some technical specifics, but not full
> coverage.  There is a lot of [will do, in the future] language
> without giving specifics.  OpenCSW is supposed to be a technical
> organization. It seems to me that we should be voting on specific
> full technical implementations, rather than something with fuzzy
> chunks in it

Some things are technical and require a full technical writeup.  Some
things are not technical.  While the changes required by this proposal
will be technical, this proposal is addressing an organizational
issue.  It says: We want to change directions and start automating the
release process.  This includes catalog updates, mirror pushes, QA
processes, etc.

While Maciej has written an excellent tool that handles a large
portion of what we think the details will look like, there is more yet
to do.  At the current time, writing all of the code and tools would
be counter-productive as we have not formally adopted the new
direction yet.  Determining all of the details to begin implementation
up front is equally pointless.

If the proposal is accepted, there is more discussion to be had.

> 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.  This
> is untrue, both at the direct package level and at the discussion
> level, as shown below. Therefore this red herring should be removed.
> (and possibly, maintainers should be re-informed of some facts):

Please don't pass this off as 'uninformed maintainers' as that is not
what you're dealing with here.  We're all well versed in how things
work.

Participation implies that people work together on an even footing to
advance a goal they share.  The current system is anything but
participatory.

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.

This does not describe the current process.

> At the discussion level, all packages "held" from release, are
> discussed in the pkgsubmissions mail list.  Right now, "anyone can
> participate" in the discussion of a held package.

People can talk until they're blue in the face, but unless we beat you
down with a vote (something that wasn't an option until the election,
I might add), packages don't flow unless you allow it.  Not
participatory.

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.

> At the direct package participation level: If a maintainer chooses
> to have their packages examined/tested before pushing them out to
> the general public, they can already drop them in "experimental" and
> ask that people look at them before publicly pushing them out to
> newpkgs.

"Pay no attention to the man behind the curtain."

This isn't what we're talking about here.  We're talking about holding
an equal status in the process.  To play on Jonathan's wording, we'd
see everyone be freemen instead of serfs.

> The fact that others rarely choose look at them now when a
> maintainer requests feedback, is not a failure of the current
> system, but rather an indication that maintainers rarely choose to
> look at other people's packages. It is doubtful that a wholesale
> "new system" will change that.

There is nothing to be gained presently as it doesn't matter what
anyone but the release manager thinks.  The new system lays the
groundwork for people to begin feeling as though participation might
be rewarding instead of masochistic.

> If people rarely even look at packages when a maintainer *specifically
> requests* feedback, it seems less likely when the whole thing is
> automated and there is no explicit request to do so.

Given that you've taken the 'anyone can participate' out of context,
I'll ignore this bit.

> 3. Removal or adjustment of "Packages are subject to stalls or
> rejections for non-policy reasons."
> 
> 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, so please don't fall back on this "but you can
vote" line that you keep trotting out.  This is simply a delay that
you've needed to resort to in recent times when you feel that you know
better than everyone else but can't bend people to your way of
thinking...or tire them out.

Secondly, while it's true that we now have a big hammer to wield, it's
not something that a small group of people wish to use every time.  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.

If you don't believe this, please review the list of stalled packages
in (and don't rely on the out of date 00-README that your
documentation indicates is the place to look).

Thirdly, the wiki page you linked to 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?  This is about as useful to the discussion as a
backronym is to knowing what /etc means.

> Additionally, it does not recognize the benefit that policy is not
> and should not be set in stone for all time. If a release manager
> holds a package, for reasons that are not currently policy, but
> perhaps should be, then it is a good thing that discussion take
> place. Similarly, it is actually a good thing if the issue gets
> forced to a vote, because that way, policy can be officially
> adjusted, as the majority vote decides.

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 agree that votes can be useful, but I submit for
the record (again!) that for a group our size, they're far too much
overhead just to overrule the opinion of a single person.

The proposal makes no claims that policy _should_ be set in stone for
all time.  It only states that the tools should enforce policy as it
currently exists.  This will require code changes over time to both
tighten and relax various checks.

The proposal also in no way inhibits new policy from being formed.
Issues worthy of policy modification can and will be discussed.  When
required, votes can decide the outcome.  My preference is for people
to agree to disagree and move on when they're outnumbered as that is
what happens in real life.  _Most_ people already do this.

> 4. Removal of "All code, tools and documentation will available for
> all to see and improve."  This falsely implies that there is "hidden
> code and/or tools". There is not.  All code that is actually
> necessary for the release process is already completely public and
> published.

Published where?  I don't see a complete list of tools anywhere so
this is hard to judge.

> Most other stuff isnt strictly "published", but is readable by any
> maintainer who actually cares, in my home directory on bender. It
> isnt much more than convenient aliases,etc. I have, akin to aliases
> in a .bashrc, etc.

Why isn't this published?  This is about as open as OpenVMS.  Look but
don't touch.  Do you really think that aliases in your shell
environment count as open to the public?

> The release process as a whole has been fully documented also.  If
> anyone cares to dispute this, then please point out specific areas
> or tools that either lack documentation, or are hidden.  I have
> previously requested this, when this claim was made recently, but
> was only met with groundless mumblings that things were still
> somehow "hidden", without any specifics given.

"A catalog update script is called..."  What script?  Where is it?
Your documentation is hand-wavy at best and nowhere near what you
routinely demand of others.  (Including here, as item #1!)  Nobody
(myself included) to my knowledge has requested specific improvements,
but you've not (ever) volunteered this type of improvement yourself.

You recently implemented a cron job to remind you to manually run some
part of the process.  Is this documented?

> 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. The main difference is only that under the current
> system, a package deemed as "bad" will never be released, whereas
> under the "new" system, a package deemed as "bad" will first be
> released publically, but then after some indeterminate length of
> time.. potentially a **month or more**.. eventually be retracted.

I submit that this is not clear.  Especially to newcomers.  Any
attempts at clarifying this have met with the same thing we see here.
Delays.  Demands for fully formed policy that is never good enough.
Discussions that just don't end until the other party tires, etc.

Currently it can take a "**month or more**" to get good packages out
the door.  You've stated on several occasions that QA people
everywhere have the privileges that you exercise; This may be true,
but I submit that you've gone beyond this.  The tail, more often than
not, wags the dog.

> 6. Removal or adjustment of "All participants will have equal
> standing".  It would actually be harmful to opencsw to follow that
> sentiment completely. Specifically, to have two new maintainers sign
> off on each others packages, will inevitably lead to some mistakes
> that could be avoided by the oversight of more experienced
> maintainers.

First, please don't extrapolate the proposal to things that have not
been decided yet.  You're implying that there will be some sort of
sign-off process.  While it's not outside the realm of possibility
that there may come to be a system that resembles this, it is not a
part of the proposal.

(I would not support a system that sets us up for the master/slave
relationship again.)

Second, there is no need to remove or adjust this.  It's _what we
want_ Phil.  OpenCSW should encourage new people to publish packages.
Will they make mistakes?  Sure.  Will they learn as time goes on?
Sure.  The key point is that in the current system, interactions leave
them with a lot of stick and next to no carrot.  (While this isn't a
theoretical deficiency in the current package flow, it's a practical
one.)  By opening the process and giving new people an equal voice, we
intend to drastically change the carrot/stick ratio.

> 7. A technical implementation issue, that is not properly addressed
> in the proposal:
> 
> There is no such thing as a *fully* automated release system: at
> some point, issues come up that require manual intervention. For
> example, package renames, and removals. or fixing bugs in some
> unforseen interaction of the system and a new package.
> 
> The proposal declares that catalog signatures will be generated
> automatically. However, who or what group will be responsible to
> manage the catalog when the automated system is either inadequate,
> or fails?

This is covered quite adequately by Jonathan's proposed amendment.
Again, my thanks to Jonathan for providing constructive feedback.  As
long as Peter F, William and Geoff are ok with the change, this will
land on the proposal before the vote.

> 8. A technical implementation issue not addressed at all in the
> proposal: What about package takeovers? is it going to be allowable
> for any maintainer to take over any package, at any time? or remove
> any package at any time?

Please see answer #1

> 9. A technical implementation issue not addressed at all in the
> proposal:
> 
> "A package may not progress from unstable to current with open
> bugs."

Please see answer #1.

> 10. technical implementation suggestion:
> 
> If the goal is to make it *easier* for people to get involved in the
> QA process, I would suggest that either a different mechanism than
> bug filing be used, OR an alternative interface to the bug system be
> provided.  I personally feel that the existing "exchange emails over
> the pkgsubmissions mailing list" is the smallest pain point in this
> sort of process.  Forcing people to move to (our existing) bug
> system for this kind of discussion, makes it *more* difficult, not
> easier, to be involved in QA, in my opinion. It's possible other bug
> systems would do better; I'm just limiting my comments to our
> existing one.

Things like this will be good discussion if the proposal is adopted.
Nobody loves mantis and we've already discussed jira as a possible
upgrade.

I do however think that Jonathan is correct that a good bug tracking
system is the best place for these discussions.  Some things will need
to move to the list, but having a record of this discussion attached
in a meaningful way (meta data, in a sense) to the package is quite
helpful.

> 11. technical implementation issue:
> 
> "By opening up the QA process such that multiple people can easily
> participate and have equal standing on the matters at hand, we feel
> that overall package quality will improve;"
> 
> 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.  As written, it simply requires less scrutiny.

> At the moment, a release manager is guaranteed to at least glance at
> it. Whereas with the "new process", a package may (and I claim, will
> *usually*) get released with no-one but the maintainer ever looking
> at it.

Once again, I'd note that you can and do just 'run the scripts' too.
If you take 'glance' to mean cut/paste the file name into the cli then
I'd accept your statement.  Other than that the words guaranteed and
glance taken to mean "inspected every package equally" do not apply to
the current process.

> If the goal is truly, "more/better QA", then a proposed remedy for
> this, is to put in mandatory hooks for the "migrate from unstable to
> current" step, to require that at least one other person besides
> maintainer has examined the package.

We have different views of how to achieve more/better QA.  You prefer
the parent/child approach while we'd treat everyone as adults.

You'd take status quo with a few new tools written.  We think the
status quo is not adequate for fostering new maintainers that might
grow to be capable of providing good QA or at the very least not
requiring it constantly.

We also think that QA as administered by feedback from other
maintainers and bug reports would be both more productive and more
encouraging than the current system.  This will lead to more
willingness to address issues that are found.  That leads directly to
improved quality.

The proposal does not say that quality will improve immediately, it
simply says that it will improve.  Maybe it will take time to shake
off the low morale and attract new blood?  Maybe things will spring
back to life quickly?  My crystal ball isn't working.  I do however
feel that quality will, at a minimum, not decline.

I'm a consumer of the packages we release and have no interest in
causing myself more work by allowing catalog quality to deteriorate.
As far as I know, all signers are also catalog consumers and feel the
same way.  (I suspect they all run more boxes than I do and have more
at stake.)

> If on the other hand, the goal is really "to allow packages to be
> released with no one but the maintainer ever looking at it", then
> all claims about better QA should be removed from the proposal, and
> the stated "benefits" of the proposal should be updated to reflect
> that.

Modification of the wording is only required if we feel your
statements are correct.  This is not in fact the goal of the proposal.

Thus concludes my response to your proposed amendments and requested
corrections.  Unless you have actual constructive requests that
improve the proposal without altering its intent, do not expect any
further replies from me on this matter.  One evening devoted to a
single person/response is enough.

When I've collected the remaining ACK/NACK for Jonathan's amendment,
we can move forward with the vote.

Thanks
-Ben
--
Ben Walton
Systems Programmer - CHASS
University of Toronto
C:416.407.5610 | W:416.978.4302