[csw-maintainers] amendments and issues with recent prop

[Jonathan Craig]

On Thu, Jun 23, 2011 at 8:53 PM, Philip Brown <phil at bolthole.com> wrote:
>
> 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.

Yes, we know you are a misunderstood hero.
> 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

First, this isn't an amendment its a complaint.  An amendment would be
to start producing the technical details not lament their absence.
This is a volunteer organization and not a fortune 100 conglomerate
who can afford to pour millions into development of supporting systems
like this.  This aspect of OpenCSW is a sideshow for what the
organization is all about, namely turning out packages for end users.
To suggest that something be fully spec'd out and voted upon is to
declare "let's do nothing" as nobody has that kind of time or interest
(IMHO).  This amounts to a stalling tactic designed to paralyze
progress.


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

What is troubling is that one all powerful being gets to arbitrarily
block someone progress and force them to beg for support and
understanding.  As to participation, it is already stated that a third
party (you if you care to) can file a bug and seek changes prior to
publication.  You may always appeal closed bugs on the list if you
feel a maintainer is abusing their maintainer power.  If a maintainer
is uncooperative and releases poor packages this will be born out in
the bug tracker.  If the current bug tracker is too cumbersome then
maybe we should look at another, such as Jira.

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

Automation doesn't fix policy for all time as it can grow and change
along with our understanding.  What it does is force policies to be
codified and enforced by an inanimate process without the ability to
adjust policy on a whim.

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

This is simply defensive.  I don't care if its fully documented my
experience leads me to believe that an automated approach will be less
frustrating and more deterministic.  I want the comfort of having my
package pass all known tests and flowing through without me wondering
whether I've forgotten something.  The more this relies on human
interaction the less likely it will be that the automated checks will
be put in place to help me turn out more packages quicker with better
quality.

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

Yes, the process begins with a public flogging that feels like a "oh,
you dumb shit you forgot" even when that wasn't the message intended.
When a piece of code tells me I cant submit a package that is
uncommitted, I say, "Oh doh, I knew that" and fix it.  When it gets
posted to everyone for all time, I get frustrated.

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

You can't have both sides of an argument unless your talking to
yourself in a closet.  You are both for full classless participation
in a democratic process and then argue unless its two neophytes
colluding to avoid doing the right thing.  This is hardly a serious
concern and the damage would be limited, IMHO.

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

Closest thing to a constructive request so far.  This is of course
voiced as a complaint instead of a fully formed and documented
solution.  I agree given the dynamics involved a group of SME's will
need to be responsible for arbitrating breakdowns and enhancing the
automation to accommodate future recurrences.

"A group of subject matter experts will be established to support and
maintain the release system.  This group will be subordinate to the
board and responsible for seeing that packaging policy to properly
enforced by the release systems.  In the event an unforeseen issue
disrupts the release process they are empowered to manually augment
the system to enable timely release of packages.  Such manual
intervention will be logged with the understanding that repeated
manual intervention will require enhancements to the release system to
accommodate routine exceptions."

I think most would have thought that something like this was inherent
to any automated solution, but it doesn't hurt to write a little
verbage to outline expectations.

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

Agreed, any release mechanism must have a method to accommodate
package takeovers.  It should do so in a manner consistent with
published policy.  Again, I see the complaint but no solution.  That
is of course unless your implying that a human release manager can
handle this bit of nastiness as they see fit.  Personally, having a
clear process for taking over a package and an automated solution to
enable "proper" takeover is better than doing this in the darkness of
night.

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

This may prove too complicated to code and we might throw our hands in
the air and give up.  Or, someone may see this as an interesting
dilemma and work on a process and some code to handle this kind of
dependency.  It would be nice if the maintainer could code these
dependency into their submit and see that its handled to their wishes.
 That puts the maintainer in the drivers seat, where the
responsibility belongs.

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

Ah, but the bug system keeps the conversation on point.  In a mail
list an email is likely to get hijacked into a different directions
when you begin a philosophical debate over which approach is "best".
That is less likely to happen in the context of  a bug report as the
writer is conscious of the fact that this is all being filed against a
specific instance.  And the original maintainer may not even care
about the philosophical differences they simply need to get a package
published so they can get some other (possibly paid) work done.  Like
me, I build packages that by paying job needs, Not because packaging
applications is "Fun!".

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

Bullshit, it is your conjecture that apathy will rain and reduce
involvement beyond the current level.  If you choose to review and
file bugs on every application that releases then it has the same
level of critique.  If you can get one other person to do the same (oh
and by the way they cant today) then it doubles.

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

I glance at every release already, then I mark the email "read" unless
its a package that holds interest to me.


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

The automated system does allows for more/better QA as indicated
above.  If quality suffers then we can look at this enforcement.  So
far its not a policy of the organization and I doubt you would get
much support for making it policy absent some reoccurring issue.


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

No the goal is to determine the problems and teach an automated system
to apply this to every package, all the time.  Not allow a handful (or
one) person to arbitrarily decide to "look into" a package and place
it on hold until their curiosity is satisfied.

I can afford to call shenanigans on your post as I'm simply a
maintainer of a handful of packages and at worst I'm risking a few
future packages enduring more scrutiny as a result.  I've been witness
to these types of attempts to derail any progress you don't believe
in.  Your collection of amendments boil down to a list of complaints
that point towards status quo.  Do we need a vote that simply and
plainly declares the organizations direction towards automated
systems?  I would think that the support the existing proposal has
would make this fairly clear, but maybe you need more.  If a vote is
required I guess we could do that but do you really think you have an
unvoiced constituency that will keep us on the path of a human centric
release process, or will this essentially be another 7 - 14 day
delaying tactic?