[csw-maintainers] amendments and issues with recent prop

[Philip Brown]

Since the recent thread had gotten filled up with some things that
were only semi-relevant to the direct issue, or in some cases not at
all relevant, I thought it would be useful if I started a fresh
thread.
The following are some proposed amendments to the proposal given at
http://wiki.opencsw.org/automated-release-proposal

Each item below is a separate issue; this email is a collection of
suggested amendments, not an "all or nothing" document.
Some items are related to specific wording of the proposal. Other
items are related to technical issues that need to be addressed.

It is possible that some problems have arisen due to some maintainers
potentially misunderstanding how things *currently* work. Some of the
items below might help spread knowledge around more widely.


Sorry that this is long: however, people complain when I break things
up into smaller emails also, so it's a lose-lose situation no matter
what I do.
Wording problems are grouped in the first section, technical issues
are grouped in the later section.



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

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):

   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.

  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.

  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.

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.


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.

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.

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

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.

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.

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.





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?

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?

9. A technical implementation issue not addressed at all in the proposal:

"A package may not progress from unstable to current with open bugs."

It has been written elsewhere, that this progress will be automated,
after (2 weeks time).
However, what about the problem when two new upgrades are released
together, as follows:
  libA1(.1) upgrades libA1(.0)
  libB1(.1) upgrades libB1(.0), and depends on libA1. It FAILS if run
against the older libA1.0
[ I am using the (.1, .0) syntax above, to indicate minor rev changes
to the hypothetical libraries, where the SONAME does not change. ]

  A bug is filed against libA1(.1)
   The bug is not addressed within 2 weeks. (lets say the bug is filed
on the 13th day)
However, libB1(.1) has no bugs filed. It then gets auto-migrated to
current. Where it will then be non-functional,
and break everything depending on "libB1"

I have used the example of shared libraries here, but the problem is
generic, for any time that two packages are pending migration from
unstable to current at the same time, with one dependent on the other.
It could well be that they are from completely diferent maintainers.
maintainer A, releases libA1 update to unstable. a day or two later,
maintainer B updates libB1 based on that update, and releases libB1 to
unstable. 12 days later, libA1 is blocked from release to current, but
libB1 will sail through 2 days later.

Note that this is particularly important when someone decides to do a
"complicated" upgrade set that has 10, 20, 30 or more packages


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.




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

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.

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.