public inbox for gentoo-dev@lists.gentoo.org
 help / color / mirror / Atom feed
From: "Molle Bestefich" <molle.bestefich@gmail.com>
To: gentoo-dev@lists.gentoo.org
Subject: [gentoo-dev] Re: Gentoo: State of the Union
Date: Sun, 7 May 2006 19:51:44 +0200	[thread overview]
Message-ID: <62b0912f0605071051td6231b2h13db08f12bd3188a@mail.gmail.com> (raw)
In-Reply-To: <62b0912f0605040204g3c4df04cg3b5da6171f834076@mail.gmail.com>

> > If you want central control of what's happening in the repository,
> > Subversion seems like the way to go.
>
> Better to fix the design of the repository, so that it can't be
> broken in the first place, than to try putting band-aids in place
> to cover the gaps.

Wow, way out of scope.
Sure, a Portage that's inherently unbreakable would be nice.
And infinitely more difficult to carry out than what I was proposing.

Also, the two (QA inline in commit process vs. Perfect Portage) does
not preclude each other.  While one may be better long term you
can still do the other to improve quality short term.

(Not that you would need to - if you had a QA step in the commit
 process to make sure that ebuild dependencies were never broken,
 why would you want to create a whole new Portage?

I was trying to say that a QA tool in form of a SVN pre-commit hook
seems like a perfect fit.  The entire infrastructure to run an
external application to check a commit before carrying it out,
approve the commit, send appropriate error messages back to the SCM
client and display them to the user etc. is already in place (and
has been for years) in the Subversion server and any of the client
tools.

The amount of work involved between inventing a couple of rules that
committed ebuilds must obey to actually implementing an enforcement
of said rules is _very_ overcomeable with SVN.

I wasn't even proposing that Gentoo actually needs a QA tool inline
in the process, just saying that it can easily be done [with SVN] :-).


PS. I resent calling it a "band-aid".  It'd be a QA tool built on the
very well-thought-out foundation for quality assurance of commits that
SVN pre-commit hooks happens to be.

-- 
gentoo-dev@gentoo.org mailing list



  parent reply	other threads:[~2006-05-07 17:56 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <62b0912f0605021406s49a16eaapd596426ce2226a7c@mail.gmail.com>
2006-05-04  9:04 ` [gentoo-dev] Gentoo: State of the Union Molle Bestefich
2006-05-04 10:44   ` Stuart Herbert
2006-05-04  8:55     ` Thomas Cort
2006-05-04 11:57     ` Chris Gianelloni
2006-05-04 12:17       ` Stuart Herbert
2006-05-04 13:30         ` Paul de Vrieze
2006-05-07 17:51   ` Molle Bestefich [this message]
2006-05-08 19:48     ` [gentoo-dev] " Jan Kundrát
2006-04-28 17:14 [gentoo-dev] " Ryan Phillips
2006-04-29 12:02 ` Dan Armak
2006-04-29 12:21   ` Fernando J. Pereda
2006-04-29 12:54     ` Dan Armak
2006-04-30 20:41       ` [gentoo-dev] " R Hill

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=62b0912f0605071051td6231b2h13db08f12bd3188a@mail.gmail.com \
    --to=molle.bestefich@gmail.com \
    --cc=gentoo-dev@lists.gentoo.org \
    /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