public inbox for gentoo-pms@lists.gentoo.org
 help / color / mirror / Atom feed
From: Ciaran McCreesh <ciaran.mccreesh@googlemail.com>
To: Ulrich Mueller <ulm@gentoo.org>
Cc: Brian Harring <ferringb@gmail.com>,
	gentoo-pms@lists.gentoo.org, gentoo-council@lists.gentoo.org
Subject: Re: [gentoo-pms] kdebuild-1 conditionales
Date: Fri, 11 Dec 2009 17:43:39 +0000	[thread overview]
Message-ID: <20091211174339.6489c086@snowmobile> (raw)
In-Reply-To: <19234.33425.281151.673508@a1i15.kph.uni-mainz.de>

[-- Attachment #1: Type: text/plain, Size: 2558 bytes --]

On Fri, 11 Dec 2009 18:34:09 +0100
Ulrich Mueller <ulm@gentoo.org> wrote:
> >>>>> On Fri, 11 Dec 2009, Ciaran McCreesh wrote:
> >> We can considerably shorten this discussion, because it boils down
> >> to the following: PMS is an official Gentoo document, and therefore
> >> it's not upon you to make this decision.
> 
> > Alright. We'll escalate this to the Council then.
> 
> No need for that, as it has already been voted on in the 2008-04-10
> council meeting (repeating it, as you've added gentoo-council to CC):
> 
> | The council voted that kdebuild-1 and other unapproved EAPIs could
> | not be in an approved PMS document. The spec isn't a place for
> | proposals or things that will never be submitted for approval by the
> | council. It's a specification, a reference of what is allowed in the
> | main tree.

And the resolution for that was to make it possible to disable
kdebuild-1. That is not the same as deleting it while there are still
users who have kdebuild-1 packages installed.

I shall remind you, the Council-approved process for PMS changes is to
send them to this list, and if unanimous agreement can't be reached,
then to escalate the issue to the Council.

> > In the mean time, I'll give Christian a day or two to revert every
> > patch he's applied recently that didn't follow the Council-mandated
> > review process, or I can do the revert for him if he doesn't have
> > time himself.
> 
> Don't.

Sorry, but the Council-approved procedure is that patches get sent to
this list and don't get committed until there aren't objections. We
don't commit things until everyone's happy with them.

I have objections to several of those patches, and they haven't been
addressed. If you'd like to address them now, please do so:

* When did it become policy to use the newest EAPI for ebuilds? I
  must've missed that becoming policy -- last I heard, policy was to
  use the oldest EAPI that provides everything you need to write a good
  ebuild.

* Since PMS became 'suitable for use', we've never committed works in
  progress to master. We've always used branches for EAPI definitions
  that aren't complete, and we've never committed EAPIs that haven't
  had their wording approved by the Council to master. Why are we
  changing this policy? Where was this policy change discussed?

* Why is disabling kdebuild-1 by default helpful? Why not take the
  reasonable steps already mentioned first, to ensure that the change
  does not have adverse impact?

-- 
Ciaran McCreesh

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

  reply	other threads:[~2009-12-11 18:14 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-12-10 20:48 [gentoo-pms] kdebuild-1 conditionales Christian Faulhammer
2009-12-10 22:27 ` Ciaran McCreesh
2009-12-11  6:08   ` Ulrich Mueller
2009-12-11 13:56     ` Ciaran McCreesh
2009-12-11 15:02       ` Ulrich Mueller
2009-12-11 17:06         ` Ciaran McCreesh
2009-12-11 17:26           ` Ulrich Mueller
2009-12-13 14:13         ` Ciaran McCreesh
2009-12-11 15:03     ` David Leverton
2009-12-11  8:17   ` Brian Harring
2009-12-11 10:45     ` Maciej Mrozowski
2009-12-11 13:59       ` Ciaran McCreesh
2009-12-11 14:23         ` Christian Faulhammer
2009-12-11 17:07           ` Ciaran McCreesh
2009-12-11 13:57     ` Ciaran McCreesh
2009-12-11 14:44       ` Ulrich Mueller
2009-12-11 17:02         ` Ciaran McCreesh
2009-12-11 17:11           ` Ulrich Mueller
2009-12-11 17:18             ` Ciaran McCreesh
2009-12-11 17:34               ` Ulrich Mueller
2009-12-11 17:43                 ` Ciaran McCreesh [this message]
2009-12-11 18:14                   ` Ulrich Mueller
2009-12-11 18:27                     ` Ciaran McCreesh
2009-12-11 19:42                       ` Brian Harring
2009-12-11 19:53                         ` Ciaran McCreesh
2009-12-11 20:30                           ` Brian Harring
2009-12-11 20:54                             ` Ciaran McCreesh
     [not found]                   ` <200912122245.50521.vapier@gentoo.org>
2009-12-13 19:30                     ` [gentoo-council] " Ciaran McCreesh
     [not found]                       ` <200912132131.13308.vapier@gentoo.org>
2009-12-14 15:14                         ` Ciaran McCreesh
     [not found]                           ` <200912141201.04887.vapier@gentoo.org>
2009-12-14 18:21                             ` Ciaran McCreesh
2009-12-14 20:58                             ` Brian Harring
     [not found]               ` <1260817256.7072.7.camel@hangover>
2009-12-14 19:24                 ` Ciaran McCreesh
2009-12-16 22:50   ` Christian Faulhammer
2009-12-16 23:08     ` Ciaran McCreesh

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=20091211174339.6489c086@snowmobile \
    --to=ciaran.mccreesh@googlemail.com \
    --cc=ferringb@gmail.com \
    --cc=gentoo-council@lists.gentoo.org \
    --cc=gentoo-pms@lists.gentoo.org \
    --cc=ulm@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