[csw-maintainers] introducing csw-upload-pkg

[Dagobert Michelsen]

Hi,

Am 12.05.2011 um 01:55 schrieb Philip Brown:
> On Tue, May 10, 2011 at 9:41 AM, Ben Walton <bwalton at opencsw.org> wrote:
>> Excerpts from Philip Brown's message of Tue May 10 12:01:13 -0400 2011:
>> 
>>> Not every issue is worth voting about. But some are. As such, I
>>> think there should be some kind of official trigger for the
>>> dissenting voice(s) to be able to start a vote on a policy/release
>>> toolchain issue.
>> 
>> This is all well and good, but it's a tangential issue to what we're
>> proposing here.  Replacing a human release manager with csw-upload-pkg
>> does not strictly require changes to other day-to-day activities aside
>> from how packages are pushed for release.  It's a change in workflow.
>> 
>> Policy discussions, resolutions and changes to checkpkg to reflect the
>> former can happen as they have been or we can implement stricter
>> controls (sob/ab, etc).  I'm not against standardizing how changes
>> happen, but it's a side issue.
> 
> What you seem to be saying is,
> 
> "Hey, its time to change the workflow. Lets not bother thinking about
> the *impact* of changing the workflow, lets just go ahead and change
> it! "
> This is a poor "policy workflow", in and of itself.
> 
> Coincidentally, the parts that you dont seem to think are worth
> discussing BEFORE the change, are the parts that put you and maciej
> directly in charge of the workflow AFTER the change.
> AND, coincidentally, you and maciej will be the ones who will control
> any later avenues of complaint or adjustment against the "workflow"
> once it is implemented.
> 
> In legal, and corporate circles, this is what is known as a "conflict
> of interest".

I don't understand all the fuzz about this. The previous workflow looked
like this:

  pkgsubmissions@ -> Release Manager -> current

The proposed new workflow looks like this:

  csw-upload-pkg -> unstable -> QA Team -> current

The policies in csw-upload-pkg are well accepted and all packages pass them
anyway when build with GAR. As the previous Release Manager is propably
a member of the QA Team there is no change in policies: what had to be
discussed previously as guideline for the release manager must now be
discussed as guideline for the QA Team. I fail to see a significant change
here.

Besides all this a proverb comes to my mind:

  "The engineers doubting that something is possible should just
   step aside from the engineers already doing it."



Best regards

  -- Dago