public inbox for cygwin@cygwin.com
 help / color / mirror / Atom feed
From: "Robert Collins" <robert.collins@itdomain.com.au>
To: "Corinna Vinschen" <cygwin@cygwin.com>
Subject: Re: no more package moratorium?
Date: Sun, 11 Nov 2001 08:26:00 -0000	[thread overview]
Message-ID: <049601c16d58$d8565250$0200a8c0@lifelesswks> (raw)
In-Reply-To: <20011114124323.C24614@cygbert.vinschen.de>

----- Original Message -----
From: "Corinna Vinschen" <cygwin@cygwin.com>
>
> > It does raise an interesting point: who, when, and how, do new
packages
> > get approved?
>
> That's a problem when getting lots of new packages.  The forum for
> discussion and the approval process is cygwin-apps.  However, it's
> not the forum to send loads of tar archives so we will have to find
> some standarized way as, just as an example:

Tarballs - package quality - are orthogonal to the discussion I was
raising. I've trimmed those aspects out in replying.

> - Potential contributor announces on cygwin-apps that s/he wants
>   to contribute package `foo' with a short description what the
>   package does.

I agree. They must also *At this point* agree to maintain the package do
upgrades feed patches to the vendor etc, and that they will announce
publicly if they decide to stop maintaining the package with as much
warning as possible. Packages with no maintainers are pulled after 3
months.

> - cygwin-developers discusses if the package should become part of
>   the distro and chooses a person from cygwin-developers as approver.

Nope. I don't think this is appropriate. cygwin-developers is for
developers of cygwin1.dll. Last I heard, Linus has no input into what
Redhat put into the (say) the RawHide distro, so why should the
cygwin1.dll developers care what goes into 'cygwin the net
distribution'.

I think we should either get a consensus from all the package
maintainers, or perhaps, wait 3 days for objections. If no objections,
then the package is allowed in. If there are objections, discuss until
resolved. To prevent deadlock, a single individual objecting will not
cause a package to be rejected, the objections must be agreed with by
other package maintainers.

Some sort of voting thing might be nice (mentioning to show I've thought
about it) but for now it seems too hard for too little benefit. I do
like the idea of a sponsor, so

once a package is decided to be allowed in, if its the first package
from the maintainer (ie a new maintainer) then an existing maintainer
must sponsor the package, and vet package quality -
textmode/patches/postinstall scripts etc.

> - When the approver thinks the package is ok,  the contributor
>   is (obligatory!) asked if s/he's willing to maintain the package
>   in future and if s/he's willing to announce officially when
>   s/he's not anymore willing to maintain the package.

Good points. modified slightly

> - When the contributor/maintainer announces to drop maintainership,
>   we will ask for another person willing to maintain the package
>   further.  If we don't find another person within, say, three months,
>   the package will be removed from the distro.

As you can see above, this does not cover getting the tarball into the
net distro: as I said, thats orthogonal.

I think the process for that part should be something like

sponsor (for new maintainers) or maintainer (2nd package or new version
of existing) places the packages files at a URL.
They tell someone from <list of maintainers with write access>.
<someone> uploads to cygwin.com.

If there is _any_ doubt about the package quality, upload it as
experimental. Wait 3 weeks, and if there are no bugs reported, then edit
setup.hint to make that new versiom current.

Thoughts on this?

Rob


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

  reply	other threads:[~2001-11-14 22:06 UTC|newest]

Thread overview: 41+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-11-02 12:06 Gareth Pearce
2001-11-02 12:19 ` Robert Collins
2001-11-11  8:26   ` Robert Collins
2001-11-11  8:26   ` Corinna Vinschen
2001-11-11  8:26     ` Robert Collins [this message]
2001-11-11  8:26       ` Robert Collins
2001-11-11  8:26       ` Stipe Tolj
2001-11-11  8:26       ` Christopher Faylor
2001-11-11  8:26         ` Stipe Tolj
2001-11-11  8:26         ` Robert Collins
2001-11-11  8:26         ` Jesper Eskilson
2001-11-11  8:26           ` Christopher Faylor
2001-11-11  8:26             ` Stipe Tolj
2001-11-11  8:26     ` Jan Nieuwenhuizen
2001-11-11  8:26       ` Stipe Tolj
2001-11-11  8:26         ` Robert Collins
2001-11-11  8:26           ` Stipe Tolj
2001-11-11  8:26             ` Robert Collins
2001-11-11  8:26               ` Stipe Tolj
2001-11-11  8:26                 ` Robert Collins
2001-11-11  8:26                   ` Stipe Tolj
2001-11-11  8:26                   ` Christopher Faylor
     [not found]       ` <m3k7wr50fa.fsf@appel.lilypond.org>
2001-11-11  8:26         ` tetex-beta nitpicking [WAS: Re: no more package moratorium?] Markus Hoenicka
2001-11-11  8:26           ` Jan Nieuwenhuizen
2001-11-11  8:26             ` Robert Collins
2001-11-11  8:26           ` Charles Wilson
2001-11-11  8:26             ` Markus Hoenicka
2001-11-11  8:26           ` Jan Nieuwenhuizen
2001-11-11  8:26             ` Charles Wilson
2001-11-11  8:26               ` Jan Nieuwenhuizen
2001-11-11  8:26             ` Markus Hoenicka
2001-11-11  8:26               ` Robert Collins
2001-11-11  8:26                 ` Markus Hoenicka
2001-11-11  8:26                   ` Jerome BENOIT
2001-11-11  8:26                     ` Robert Collins
2001-11-11  8:26       ` no more package moratorium? Markus Hoenicka
2001-11-11  8:26         ` Stipe Tolj
2001-11-11  8:26           ` Charles Wilson
2001-11-11  8:26             ` Christopher Faylor
2001-11-11  8:26 ` Gareth Pearce
2001-11-11  8:26 E

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='049601c16d58$d8565250$0200a8c0@lifelesswks' \
    --to=robert.collins@itdomain.com.au \
    --cc=cygwin@cygwin.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).