[csw-maintainers] Our core values: providing straightforward experience to the user

[rupert THURNER]

On Wed, Nov 24, 2010 at 00:56, Jake Goerzen <jgoerzen at opencsw.org> wrote:

> On 11/23/2010 4:08 AM, Maciej (Matchek) Blizinski wrote:
>
>> No dia 20 de Novembro de 2010 19:46, Philip Brown<phil at bolthole.com>
>>  escreveu:
>>
>>> On Sat, Nov 20, 2010 at 6:26 AM, Maciej (Matchek) Blizinski
>>> <maciej at opencsw.org>  wrote:
>>>
>>>> (Apologies, I hit "send" too early. Here's a proofread version.)
>>>> ...
>>>>
>>>> For example, package consulting is hugely important.  Dissecting a
>>>> package, analyzing the contents, looking for direct and potential
>>>> problems, and providing feedback, is an immensely valuable activity.
>>>>
>>>>  Choosing the option of "no human release manager", is saying exactly
>>>>> that.
>>>>> (if one presumes that people are choosing that option, with the
>>>>> assumption that quality of packages will not suffer as a result)
>>>>>
>>>> No human release manager means that there is no single person in
>>>> power.  It does not mean that packages aren't examined by a human.
>>>>
>>> (I will point out that this is EXACTLY what Peter proposed: no-one
>>> other than the maintainer would directly examine them before release,
>>>
>> Yes and no.  No one other than the maintainer would _have_ to directly
>> examine packages before putting the package into unstable.  However,
>> the maintainer could ask another maintainer for a review of his package.
>>
>> Once the package gets into experimental and/or unstable, anybody who
>> uses the package and notices a problem with it, can file a bug against
>> the package, saying: "this package does not follow the policy in this
>> place."  If we then use the bug statistics to gate packages between,
>> say, unstable and testing, or testing and stable, everyone can be a
>> release manager.
>>
>>  How will they ever get examined by someone other than the maintainer,
>>> then?
>>> Please propose something that is actually practical, rather than just
>>> ideal.
>>> In the Real World, how will you ensure that packages are examined "by
>>> a human[that is not just the maintainer themselves]" before release to
>>> 'current'?
>>>
>> I think it was about a release to unstable, rather than current.
>> You're probably still thinking in the old model, while many people
>> already think in terms of staged package catalogs.
>>
>> I don't think that the goal of providing high quality packages is
>> contradictory with the idea of human-free release process.
>>
>>  What you wrote, seems to be contradictory.
>>> if there is no human release manager, then there is no human looking
>>> at packages before release.
>>>
>> The term "release" needs to be slightly redefined.  Instead of a
>> quantum leap from "does not exist in the outer world" to "released to
>> everyone", we would have stages that each package undergoes, at each
>> stage reaching a slightly wider audience.
>>
>>  perhaps you meant "no SINGLE release manager", but that's not what you
>>> wrote :-)
>>>
>> Yes, it's about many people participating in staged releases.  I
>> believe that there being a single person with discretionary control
>> over releases is not a good thing.
>>
>>  What about the experimental branch?  Isn't the experimental branch
> exactly what you are getting at?  The package maintainer can "release" here
> directly themselves and the package is available world wide through the
> automatically generated experimental catalog every 5 minutes.  In my opinion
> having release manager with lots of experience and dedication is a good
> thing.
>
>
i'd support this as well. then we have two stages, experimental and
current/unstable. broken packages make users look for alternatives - many of
them do not like to file bugs.

rupert.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opencsw.org/pipermail/maintainers/attachments/20101124/cfac0953/attachment.html>