To me the voting process seems unweildy.  I propose a freeze the third thursday of every month on .info files (i.e. any new ones are ignored until next month).  One person or team dishes out packages to volunteers in their perceived order of value.  Each package is only tested by one volunteer that week. If it passes they upload the binary or mail it to a project coordinator with a x.509 or pgp (their choice) signature.

An alternative to the voting system is for someone to be the executive decision maker (i.e. maybe  Chris Dolan) to solicit recomendations on a particular package but make the decision himself. 

Doug


On 11/5/05, Chris Dolan <[EMAIL PROTECTED]> wrote:
On Nov 5, 2005, at 4:55 AM, Dave Vasilevsky wrote:

> When it comes to a system to perform the builds on, we don't really
> have anything at this point. A build box should ideally be a very
> clean system, since we don't want any .debs to be accidentally
> polluted. Also, we'd have to be careful it's under the control of
> trusted people, since there's a security risk with distributing
> binaries. Something to think about once we get sufficient work done
> on buildfink.

Here's a brainstorm for a distributed bindist creation solution:

How about an 'upload' flag in fink.conf that developers can turn on.
After a successful build, fink would compute a hash (perhaps MD5) of
a resulting .deb and report that hash to a server.  If that MD5 is
not previously known, the .deb is uploaded.  Otherwise, a "vote" for
that .deb's hash is recorded in the developer's name.  When a .deb
gets enough votes from trusted developers, it's made public as a binary.

Requiring multiple votes with matching hash before adding to bindist
solves these problems:
  1) don't have to trust just one developer to make bindist since
results are checked against others
  2) less worry about a weird setting on a single build box making
bad .debs
  3) don't need dedicated hardware for bindist

[One small worry would be the hash.  There are known ways to create
MD5 collisions.  But given that the .deb is created from a .info, I
think it would be really hard to create a .info that repeatably
created a compromisable .deb.]

What would be needed to implement this?
  - social decisions
    * how many votes needed to trigger an addition of .deb to bindist
    * weighting for developer votes  (e.g. Dave Morrison's vote
counts much more than Chris Dolan's)
  - server
    * list of developers who can vote (same as committer list?)
    * a vote database
    * write-only .deb upload location (write once, no overwrite!)
    * auto update of apt binary list files when sufficient votes arrive
  - client
    * code to support new upload setting
    * code to submit vote and .deb after build
    * more frequent fetch of apt binary lists since they'll be
updated constantly

Chris
--
Chris Dolan, Software Developer, Clotho Advanced Media Inc.
608-294-7900, fax 294-7025, 1435 E Main St, Madison WI 53703

Clotho Advanced Media, Inc. - Creators of MediaLandscape Software
(http://www.media-landscape.com/) and partners in the revolutionary
Croquet project (http://www.opencroquet.org/)



-------------------------------------------------------
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server. Download
it for free - -and be entered to win a 42" plasma tv or your very own
Sony(tm)PSP.  Click here to play: http://sourceforge.net/geronimo.php
_______________________________________________
Fink-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/fink-devel

Reply via email to