Le Mon, Mar 29, 2010 at 11:03:00AM +0800, Paul Wise a écrit :
>
> I find that attitude problematic. When electing a DPL we get a package
> deal. Some of each candidates ideas are liked by some/many, others
> disliked by some/many. It would be a shame to throw out good ideas
> with bad ones.
Le Mo
> (And to answer to the comment ‘you do not need to be DPL for doing this’, that
> is true, but if I make a bad score at this election, I will conclude that
> there
> are not many persons interested in what I propose anyway, and will save
> everybody's
> time by not discussing them further in th
On Mon, Mar 29, 2010 at 9:50 AM, Charles Plessy wrote:
> (And to answer to the comment ‘you do not need to be DPL for doing this’, that
> is true, but if I make a bad score at this election, I will conclude that
> there
> are not many persons interested in what I propose anyway, and will save
>
Le Sun, Mar 28, 2010 at 12:51:31PM +0200, Bernhard R. Link a écrit :
>
> So is this "let" supposed to mean "allow" or to mean "force"?
Hi Bernd,
it means, the one who wants the package is responsible for it. If upstream and
the maintainer are not interested in supporting a package on an architec
Le Sat, Mar 27, 2010 at 01:15:47PM +0100, Stefano Zacchiroli a écrit :
>
> I don't understand what "cloud computing" has to do with your idea of
> using package priorities to release differently different sub-systems
> within Debian. I'm well aware that we are currently lagging behind in
> the rac
* Charles Plessy [100327 06:17]:
> I think that the ‘RPM hell’ that you used to comment my propositions is more
> related to a situation when independant distributions are using the same
> package format, than when a distribution offers multiple repositories that
> obey
> to a policy that keeps t
Le Sat, Mar 27, 2010 at 04:13:11PM +0800, Paul Wise a écrit :
>
> Does popcon not already provide a way to order packages based on
> importance? rc-alert has both options for sorting bugs by both local &
> global popcon score.
Hi Paul,
Popcon is definitely a potent indicator, but has its flaws a
On Sat, Mar 27, 2010 at 03:17:03PM +0900, Charles Plessy wrote:
> In my experience, trivial RC bugs on not-so important packages attract
> volunteers because it is very rewarding to close RC bugs.
> So in my opinion, not all RC bugs are equal, and a better priority
> system would be useful to help
On Sat, Mar 27, 2010 at 2:17 PM, Charles Plessy wrote:
> Regarding my proposal, that is internal to Debian, I do not think that it is
> impossible. What I propose is a way for package maintainers to signal that
> their package is peripheral in the Debian system, in an opt-in manner. Debian
> is r
Hello Bernhard and everybody,
I think that the ‘RPM hell’ that you used to comment my propositions is more
related to a situation when independant distributions are using the same
package format, than when a distribution offers multiple repositories that obey
to a policy that keeps the whole syste
* Charles Plessy (ple...@debian.org) [100317 01:52]:
> I propose that we reshape the sections and priorities of our archive, so that
> it is easy to remove from Testing any RC bug that is not in a core pakcage,
> and is old and not tagged RFH.
We already do that, provided the RC bug is old enough.
Le Mon, Mar 15, 2010 at 08:09:19AM +0100, Lucas Nussbaum a écrit :
>
> During the last debconf, the freeze of squeeze was first announced to
> take place in December, then this decision was cancelled, and now we are
> in March.
> - How do you analyze what happened during last summer? What went wro
On Wed, Mar 17, 2010 at 12:56 AM, Gunnar Wolf wrote:
> Hmm, you got me thinking here on why this happened, as I share your
> impression. Maybe it was because the project as a whole put more care
> into the release process after the massive pain it was to release
> Sarge, a three-year-long pain we
On Tue, Mar 16, 2010 at 09:56:56PM -0600, Gunnar Wolf wrote:
> Hmm, you got me thinking here on why this happened, as I share your
> impression. Maybe it was because the project as a whole put more care
> into the release process after the massive pain it was to release
> Sarge, a three-year-long p
On Tue, Mar 16, 2010 at 09:56:56PM -0600, Gunnar Wolf wrote:
> Wouter Verhelst dijo [Tue, Mar 16, 2010 at 12:57:13AM +0100]:
> > In my opinion, the best release we ever had (that I was a part of, at
> > least) was the Etch release process; shortly after Sarge had been
> > released, the release mana
* Charles Plessy [100317 01:52]:
> I propose that we reshape the sections and priorities of our archive, so that
> it is easy to remove from Testing any RC bug that is not in a core pakcage,
> and is old and not tagged RFH.
How is that different from the current procedure?
> In parallel, I propo
Wouter Verhelst dijo [Tue, Mar 16, 2010 at 12:57:13AM +0100]:
> In my opinion, the best release we ever had (that I was a part of, at
> least) was the Etch release process; shortly after Sarge had been
> released, the release managers had started to regularly update the
> project as a whole on wher
Le Sun, Mar 14, 2010 at 02:44:15PM -0700, Russ Allbery a écrit :
>
> Releasing is regularly the hardest thing that Debian does, not just
> technically but also socially. Apart from the standard issues of setting
> deadlines, RC bug counts being high, and similar difficult technical
> issues, the
Reading Wouter's post in this thread just now I realize I made a fairly
stupid mistake when writing my mail.
Frans Pop wrote:
> This seems to be what the RT has been focussing on after Sarge. [...]
s/Sarge/Etch/
> During the Sarge release these two sides were in balance. After that, for
> Sarge
On Mon, Mar 15, 2010 at 08:09:19AM +0100, Lucas Nussbaum wrote:
> On 14/03/10 at 14:44 -0700, Russ Allbery wrote:
> > This is for all candidates.
> >
> > Releasing is regularly the hardest thing that Debian does, not just
> > technically but also socially. Apart from the standard issues of settin
On Sun, Mar 14, 2010 at 02:44:15PM -0700, Russ Allbery wrote:
> This is for all candidates.
>
> Releasing is regularly the hardest thing that Debian does, not just
> technically but also socially. Apart from the standard issues of setting
> deadlines, RC bug counts being high, and similar difficu
On Sun, Mar 14, 2010 at 02:44:15PM -0700, Russ Allbery wrote:
> Releasing is regularly the hardest thing that Debian does, not just
> technically but also socially.
To some extent, I believe it is normal. Releases are our main
"products", they define our purpose. The people which are putting their
Hi Frans,
Let me first start by stating that I'm sadly concerned about the tone
of your mail.
Nobody claims that the release process has been done perfectly, there
have been mistakes, but we are all human and we can all make mistakes.
It's alright to point those mistakes out so that people can c
Margarita Manterola wrote:
> I think that most of the frustration comes from the fact that the
> release team is lacking manpower. The job of the release team is very
> stressful and very rarely do the RM and RA feel that their work is
> appreciated.
I disagree. I think the main problem is that t
On Mon, Mar 15, 2010 at 4:09 AM, Lucas Nussbaum
wrote:
> During the last debconf, the freeze of squeeze was first announced to
> take place in December, then this decision was cancelled, and now we are
> in March.
> - How do you analyze what happened during last summer? What went wrong?
What wen
On Sun, Mar 14, 2010 at 6:44 PM, Russ Allbery wrote:
> Releasing is regularly the hardest thing that Debian does, not just
> technically but also socially. Apart from the standard issues of setting
> deadlines, RC bug counts being high, and similar difficult technical
> issues, the process seems
On 14/03/10 at 14:44 -0700, Russ Allbery wrote:
> This is for all candidates.
>
> Releasing is regularly the hardest thing that Debian does, not just
> technically but also socially. Apart from the standard issues of setting
> deadlines, RC bug counts being high, and similar difficult technical
>
This is for all candidates.
Releasing is regularly the hardest thing that Debian does, not just
technically but also socially. Apart from the standard issues of setting
deadlines, RC bug counts being high, and similar difficult technical
issues, the process seems to eat volunteers. There's usual
28 matches
Mail list logo
