Hi all,
On Mon, May 27, 2013 at 02:14:17PM +0200, Andreas Tille wrote:
> On Sun, May 26, 2013 at 03:10:07PM +0200, Holger Levsen wrote:
> > On Samstag, 25. Mai 2013, Petter Reinholdtsen wrote:
> > > Actually, I believe there is. The Debian Edu blend contain the
> > > education-main-server task an
Hi,
On Sun, May 26, 2013 at 03:10:07PM +0200, Holger Levsen wrote:
> Hi,
>
> On Samstag, 25. Mai 2013, Petter Reinholdtsen wrote:
> > Actually, I believe there is. The Debian Edu blend contain the
> > education-main-server task and metapackage, which include a Kerberos
> > KDC. It also contain
Hi,
On Samstag, 25. Mai 2013, Petter Reinholdtsen wrote:
> Actually, I believe there is. The Debian Edu blend contain the
> education-main-server task and metapackage, which include a Kerberos
> KDC. It also contain the LDAP server as KDC backend storage and
> user/group/etc lookup.
there is al
[Russ Allbery]
> I would need to do some research, since I'm not personally familiar
> with everything that's in a blend or a task at the moment. Just off
> the top of my head, though, to pick an area of personal expertise, I
> don't think there's an existing blend or task for a Kerberos KDC or,
On Mittwoch, 22. Mai 2013, Jakub Wilk wrote:
> FWIW, most of the packages don't need anything more than a chroot.
Interesting, thanks.
signature.asc
Description: This is a digitally signed message part.
* Holger Levsen , 2013-05-22, 13:26:
it is not fully related to your original question, but do you think
that piuparts could support running Autopkgtests as well ?
I think we need another setup for this. Autopkgtests may destroy their
environment (and might need more than a chroot) so they canno
Hi,
On Mittwoch, 22. Mai 2013, Charles Plessy wrote:
> it is not fully related to your original question, but do you think that
> piuparts could support running Autopkgtests as well ?
I think we need another setup for this. Autopkgtests may destroy their
environment (and might need more than a c
Le Tue, May 21, 2013 at 11:48:57AM +0200, Andreas Beckmann a écrit :
> @all maintainers: How would you like to run piuparts s.t. it easily
> integrates into your workflow and allows improving Debian's quality?
> This is something we could improve right now. Integrating piuparts into
> the ftp-maste
Le mardi, 21 mai 2013 12.35:47, Ondřej Surý a écrit :
> On Tue, May 21, 2013 at 12:05 PM, Holger Levsen
wrote:
> > have an option to run piuparts automatically by debuild, after or before
> > lintian.
>
> Also integrate it with git-pbuilder/pbuilder/cowbuilder to run
> piuparts inside the create
On Tue, May 21, 2013 at 12:05 PM, Holger Levsen wrote:
> Hi,
>
> On Dienstag, 21. Mai 2013, Andreas Beckmann wrote:
>> @all maintainers: How would you like to run piuparts s.t. it easily
>> integrates into your workflow and allows improving Debian's quality?
>
> have an option to run piuparts auto
@all maintainers: How would you like to run piuparts s.t. it easily
integrates into your workflow and allows improving Debian's quality?
This is something we could improve right now. Integrating piuparts into
the ftp-master/buildd side will take a much longer way.
On 2013-05-19 18:39, Ondřej Surý
Hi,
On Dienstag, 21. Mai 2013, Andreas Beckmann wrote:
> @all maintainers: How would you like to run piuparts s.t. it easily
> integrates into your workflow and allows improving Debian's quality?
have an option to run piuparts automatically by debuild, after or before
lintian.
cheers,
On Mon, May 20, 2013 at 12:39 AM, Ondřej Surý wrote:
> So apart from the more hands on some packages with high priority, it
> would really help me to have some automated tests which would be run
> before uploading to testing.
>
> One thing which immediatelly comes to the mind is the install & upgr
On Sun, May 12, 2013 at 1:46 PM, Thomas Goirand wrote:
> On 05/12/2013 02:03 AM, Antonio Terceiro wrote:
>> You can't assume that just because something works today, it will work
>> forever.
>
> True, though it's been at least 2 release cycle (maybe 3?) that this
> set of packages were maintained
On Thu, May 16, 2013 at 5:52 AM, Neil McGovern wrote:
> On Thu, May 16, 2013 at 12:29:11AM +0200, Kurt Roeckx wrote:
>> Some upstreams have a testing branch of there software and a
>> release branch. It's sometimes useful to have people test the
>> version in from the testing branch, and having it
On Thu, May 16, 2013 at 08:03:33AM +0100, Lars Wirzenius wrote:
>
> I'd use a PPA-style package repository of some sort, and then advertise
> it to people might want to try that version of the package.
Then it makes more sense to upload it to experimental to me.
Kurt
--
To UNSUBSCRIBE, email
On Jo, 16 mai 13, 10:52:05, Neil McGovern wrote:
> On Thu, May 16, 2013 at 12:29:11AM +0200, Kurt Roeckx wrote:
> > Some upstreams have a testing branch of there software and a
> > release branch. It's sometimes useful to have people test the
> > version in from the testing branch, and having it a
On Thu, May 16, 2013 at 12:29:11AM +0200, Kurt Roeckx wrote:
> Some upstreams have a testing branch of there software and a
> release branch. It's sometimes useful to have people test the
> version in from the testing branch, and having it available in
> Debian makes it easier for people to test i
On Thu, May 16, 2013 at 12:29:11AM +0200, Kurt Roeckx wrote:
> One thing I'm wondering about, and you don't seem to talk about is
> what versions end up in a release.
>
> Some upstreams have a testing branch of there software and a
> release branch. It's sometimes useful to have people test the
>
On Thu, May 09, 2013 at 08:49:51PM +0100, Lars Wirzenius wrote:
>
> Releases are important
> --
>
> Releases are important to many, perhaps most, of our users. Hackers
> and hardcore powerusers don't necessarily care about them, of course,
> but most others do. A released vers
On Sun, May 12, 2013 at 14:48:36 -0400, Michael Gilbert wrote:
> But those shouldn't affect testing yet, right? All of that stuff
> needs staging in unstable first. Are bug filers not tagging their
> reports correctly? If so, that's quite misleading, and actually
> should be quite easy although
On Sun, May 12, 2013 at 4:42 PM, Russ Allbery wrote:
> Michael Gilbert writes:
>
>> Or the project could end up in a perpetual freeze. Every time the
>> floodgates are opened, another 1,000 bugs could get reported due to all
>> of the new transitions, and another freeze will need to happen to get
Michael Gilbert writes:
> Or the project could end up in a perpetual freeze. Every time the
> floodgates are opened, another 1,000 bugs could get reported due to all
> of the new transitions, and another freeze will need to happen to get
> those down.
I would like to see us try it and see if th
On Sun, May 12, 2013 at 4:00 PM, Russ Allbery wrote:
> Michael Gilbert writes:
>> On Sun, May 12, 2013 at 2:17 PM, Russ Allbery wrote:
>
>>> Right. Which is why we should immediately (for definitions of
>>> immediately that involve the release team taking a much-deserved break,
>>> but not for def
Michael Gilbert writes:
> On Sun, May 12, 2013 at 2:17 PM, Russ Allbery wrote:
>> Right. Which is why we should immediately (for definitions of
>> immediately that involve the release team taking a much-deserved break,
>> but not for definitions of immediately that mean "six months from now")
>>
On Sun, May 12, 2013 at 2:17 PM, Russ Allbery wrote:
> Michael Gilbert writes:
>
>> I disagree that there is something fundamentally wrong with how
>> development is done. The primary problems with this cycle were that
>> there were something like 400 or 500 extra rc bugs due to a concerted
>> eff
Michael Gilbert writes:
> I disagree that there is something fundamentally wrong with how
> development is done. The primary problems with this cycle were that
> there were something like 400 or 500 extra rc bugs due to a concerted
> effort to report all serious issues found via piuparts, and th
On Thu, May 9, 2013 at 3:49 PM, Lars Wirzenius wrote:
> The wheezy freeze has been much too long. At ten months, it's four
> months longer than what we've gotten used to in several previous
> releases. Had we managed to keep the freeze at six months, it would
> still have been too long. I believe t
On 05/12/2013 02:03 AM, Antonio Terceiro wrote:
> You can't assume that just because something works today, it will work
> forever.
True, though it's been at least 2 release cycle (maybe 3?) that this
set of packages were maintained quite well. I don't remember
seeing complains or bad bugs. Do you
On 05/11/2013 06:53 PM, Tollef Fog Heen wrote:
> ]] Johannes Schauer
>
>> Maybe the puppet question can just be solved by introducing an openstack
>> task?
> puppet isn't important because it's used by/part of openstack (which I
> don't think it is?)
Puppet isn't used by OpenStack. Though it's us
On 11/05/13 at 11:37 +0200, Johannes Schauer wrote:
> Hi,
>
> Quoting Paul Wise (2013-05-11 10:40:18)
> > Lucas created a script that displays a list of "important" packages, puppet
> > isn't on that either:
> >
> > http://udd.debian.org/cgi-bin/important_packages.cgi
>
> Not surprising as the a
On Sun, 12 May 2013 17:43:57 +0800
Paul Wise wrote:
> On Sun, May 12, 2013 at 5:22 PM, Neil Williams wrote:
>
> > The problem we should be trying to solve is "people are not getting the
> > work done, let's break down the problems and make working on them
> > easier or the solutions more obvious
On Sun, May 12, 2013 at 5:22 PM, Neil Williams wrote:
> The problem we should be trying to solve is "people are not getting the
> work done, let's break down the problems and make working on them
> easier or the solutions more obvious".
Sounds good to me.
> Modulo dropping packages from Debian w
On Sat, 11 May 2013 10:31:09 +0800
Paul Wise wrote:
> On Fri, May 10, 2013 at 11:24 PM, Russ Allbery wrote:
>
> > The point isn't what individual developers do, particularly developers who
> > are extremely well-engaged with the project. The point is to find ways to
> > do this at another level
Le 2013-05-10 17:24, Russ Allbery a écrit :
But by and large they only do this on a large scale during the freeze,
at
which point, in a way, it's too late. We've already built a huge
backlog
of work, and everyone is anxious to release. I think we should be
doing
this continuously during the
On Sat, May 11, 2013 at 06:32:21PM +0800, Thomas Goirand wrote:
> Hi Lars,
>
> I do like a lot the idea of running things like piuparts and such at
> upload time.
> If you have time to work this out with the FTP masters, that would be a very
> good idea IMO, and I warmly welcome you to do that. Ho
]] Johannes Schauer
> Maybe the puppet question can just be solved by introducing an openstack task?
puppet isn't important because it's used by/part of openstack (which I
don't think it is?) It's important because it's a tool lots of
sysadmins use to automate their infrastructures. Also, it's
Hi Lars,
I do like a lot the idea of running things like piuparts and such at
upload time.
If you have time to work this out with the FTP masters, that would be a very
good idea IMO, and I warmly welcome you to do that. However...
On 05/10/2013 03:49 AM, Lars Wirzenius wrote:
> Tests for running
Hi,
Quoting Paul Wise (2013-05-11 10:40:18)
> Lucas created a script that displays a list of "important" packages, puppet
> isn't on that either:
>
> http://udd.debian.org/cgi-bin/important_packages.cgi
Not surprising as the algorithm (from what can be read in the comments)
executes what we call
On Jo, 09 mai 13, 20:49:51, Lars Wirzenius wrote:
>
> The fundamental change is to start keeping our "testing" branch
> as close to releasable as possible, at all times.
It's probably obvious for debian-devel readers, but I think it is worth
saying it out loud: this would also give us CUT/rolli
On Sat, May 11, 2013 at 4:28 PM, Tollef Fog Heen wrote:
> (Where can I look up what tasks or blends use a given package?)
For the blends part, we plan to add that to the PTS (#703402). I
should extend that to tasks too I think.
Until then, use your favourite rdepends viewer, the aptitude curses
]] Paul Wise
> Agreed. Do you have any example use-cases that should block releases
> but aren't in blends or tasks? Perhaps we need to start some new
> blends or add new tasks.
(Where can I look up what tasks or blends use a given package?)
I don't know if, say, puppet is in a task or a blend,
Hi
On Fri, May 10, 2013 at 07:42:21PM -0700, Russ Allbery wrote:
> Paul Wise writes:
> > Agreed. Do you have any example use-cases that should block releases but
> > aren't in blends or tasks? Perhaps we need to start some new blends or
> > add new tasks.
>
> I would need to do some research, si
On Thu, May 09, 2013 at 08:49:51PM +0100, Lars Wirzenius wrote:
> * Remove RC buggy packages sooner rather than later. An RC buggy
> package should be removed at soon as possible: when the bug
> is identified, allow a bit of time for the bug to be verified
> (was it actually an RC bug?), but
On Sat, May 11, 2013 at 10:42 AM, Russ Allbery wrote:
> I would need to do some research, since I'm not personally familiar with
> everything that's in a blend or a task at the moment. Just off the top of
> my head, though, to pick an area of personal expertise, I don't think
> there's an existin
Paul Wise writes:
> On Fri, May 10, 2013 at 11:24 PM, Russ Allbery wrote:
>> The point isn't what individual developers do, particularly developers
>> who are extremely well-engaged with the project. The point is to find
>> ways to do this at another level up. Obviously, given the number of RC
On Fri, May 10, 2013 at 11:24 PM, Russ Allbery wrote:
> The point isn't what individual developers do, particularly developers who
> are extremely well-engaged with the project. The point is to find ways to
> do this at another level up. Obviously, given the number of RC bugs that
> we had to fi
Paul Wise writes:
> On Fri, May 10, 2013 at 3:49 AM, Lars Wirzenius wrote:
>> * Keep testing free of RC bugs.
> I keep packages I (co-)maintain free of RC bugs.
The point isn't what individual developers do, particularly developers who
are extremely well-engaged with the project. The point is
On Fri, May 10, 2013 at 3:49 AM, Lars Wirzenius wrote:
> * An attitude change: we decide that releases are important, and that
> they're the job of the entire project, not just the release team.
I already believe that. I would find it quite surprising if people
actually believe that releases ar
Vincent Bernat writes:
> ❦ 9 mai 2013 21:49 CEST, Lars Wirzenius :
>> A package that is not included in one or more of the reference
>> installations is a package we want to include in the release, but we
>> will not delay the release for its sake. We should have a low threshold
>> for removin
❦ 9 mai 2013 21:49 CEST, Lars Wirzenius :
> * Remove RC buggy packages sooner rather than later. An RC buggy
> package should be removed at soon as possible: when the bug
> is identified, allow a bit of time for the bug to be verified
> (was it actually an RC bug?), but after that, remove
51 matches
Mail list logo
