* Niels Thykier (ni...@thykier.net) [131215 12:36]:
> In practise, it has not worked out so well. In my experience, many
> of the Wheezy release goals became "second-rate" goals - we simply
> failed to follow up on those goals as we promised, we would. To me,
> release goals became "that outsta
On 2013-12-02 23:59, Charles Plessy wrote:
> Hi all,
>
Hi,
> am I wrong or among the supporters of the concept of release goals,
> there are no members of the release team themselves ? If yes, then
> it may be more fruitful to explore alternatives.
>
I think there are (or, at least, were) som
This one time, at band camp, Lucas Nussbaum said:
> On 01/12/13 at 23:32 +0100, Joerg Jaspert wrote:
> > I don't really see a problem in that - $someone decides on
> > "technical project goals", whatever they are. And RT can decide that
> > they should be for the next release. Or the one after. Set
Hi all,
am I wrong or among the supporters of the concept of release goals, there are
no members of the release team themselves ? If yes, then it may be more
fruitful to explore alternatives.
The Debian Enhancement Proposals (DEP) have an advantage, as they provide a way
to record whether a give
>> - There are project-wide changes to be done and someone needs to take a
>>decision to do them to adjust some of our common rules to make them
>>easier to do. Lets name them "technical project goals"
>> - There are project-wide changes to be done that should be done in time
>>for
Am 02.12.2013 08:03, schrieb Lucas Nussbaum:
> On 01/12/13 at 23:32 +0100, Joerg Jaspert wrote:
>>
I would presumably put something like:
* Release Team members decide on the release goals for stable releases
>>> I think that a delegation would need to be a bit more specific in
>>> defini
Am 01.12.2013 21:03, schrieb Lucas Nussbaum:
> that fictious goals such as "gcc 4.9 by default in jessie" or "GNOME
> 3.14 in jessie" would totally be in the realm of the release team, but
> are already covered in the delegation.
a) please use real fictious goals.
b) the choice of compiler versi
On 01/12/13 at 23:32 +0100, Joerg Jaspert wrote:
>
> >> I would presumably put something like:
> >> * Release Team members decide on the release goals for stable releases
> > I think that a delegation would need to be a bit more specific in
> > defining what "release goals" are, and what it means
>> I would presumably put something like:
>> * Release Team members decide on the release goals for stable releases
> I think that a delegation would need to be a bit more specific in
> defining what "release goals" are, and what it means to have a goal
> labelled as "release goal". At least for m
On 01/12/13 at 20:38 +, Stephen Gran wrote:
> This one time, at band camp, Lucas Nussbaum said:
> > On 01/12/13 at 17:53 +, Stephen Gran wrote:
> > > Can you explain why you think it would be a good idea to remove the
> > > power to decide their own goals from a team, and why you think it
>
This one time, at band camp, Lucas Nussbaum said:
> On 01/12/13 at 17:53 +, Stephen Gran wrote:
> > This one time, at band camp, Lucas Nussbaum said:
>
> > What goals are set for a given release seem to me to be something
> > squarely in that realm, especially given that there is no 'stick' -
On 01/12/13 at 17:53 +, Stephen Gran wrote:
> This one time, at band camp, Lucas Nussbaum said:
> > The need for review and feedback is another problem. It's often
> > difficult to get feedback on a proposed change inside Debian. But I
> > really don't think that it should be the release team's
On Sun, Dec 1, 2013 at 12:53 PM, Stephen Gran wrote:
> Can you explain why you think it would be a good idea to remove the
> power to decide their own goals from a team, and why you think it would
> be good for Debian to have one team drive another team's goals? This is
> so different to how we us
This one time, at band camp, Lucas Nussbaum said:
> The need for review and feedback is another problem. It's often
> difficult to get feedback on a proposed change inside Debian. But I
> really don't think that it should be the release team's job alone to
> decide which project-wide improvements a
On 30/11/13 at 22:07 -0600, Steve Langasek wrote:
> On Sat, Nov 30, 2013 at 05:40:35PM +0100, Jakub Wilk wrote:
> > * Steve Langasek , 2013-11-29, 12:01:
> > >What do you propose as a mechanism for agreeing to a reduced NMU
> > >delay for archive-wide changes?
>
> > My proposal is to realize that
On Sat, Nov 30, 2013 at 05:40:35PM +0100, Jakub Wilk wrote:
> * Steve Langasek , 2013-11-29, 12:01:
> >What do you propose as a mechanism for agreeing to a reduced NMU
> >delay for archive-wide changes?
> My proposal is to realize that reduced delay for archive-wide
> changes is not needed.
> Ser
* Steve Langasek , 2013-11-29, 12:01:
What do you propose as a mechanism for agreeing to a reduced NMU delay for
archive-wide changes?
My proposal is to realize that reduced delay for archive-wide changes is not
needed.
Seriously, such changes will take months or years anyway, so what does r
On Fri, 29 Nov 2013 12:01:31 -0600, Steve Langasek wrote:
> On Fri, Nov 29, 2013 at 11:02:55AM +0100, Lucas Nussbaum wrote:
>
>> - Release Goals kind-of define Debian's technical agenda. However, one
>> could
>> question whether it's really the role of the release team to decide
>> on this, r
On Fri, Nov 29, 2013 at 11:02:55AM +0100, Lucas Nussbaum wrote:
> On 28/11/13 at 21:04 +0100, Niels Thykier wrote:
> > Release Goals
> > =
> >
> > We discussed release goals in some depth at the recent sprint.
> >
> > The general consensus was that, whilst release goals have been usef
On 28/11/13 at 21:04 +0100, Niels Thykier wrote:
> Release Goals
> =
>
> We discussed release goals in some depth at the recent sprint.
>
> The general consensus was that, whilst release goals have been useful
> in the past to introduce archive-wide changes, we should review
> whether
20 matches
Mail list logo
