Am Freitag, den 04.08.2017, 22:46 +0200 schrieb Bill Allombert:
> On Fri, Aug 04, 2017 at 11:59:40AM -0700, Don Armstrong wrote:
> > > An O: bug means that it is confirmed that the package is
> > > orphaned, and
> > > gives permission to everyone to adopt the package immediately.
> >
> > So just f
Processing commands for cont...@bugs.debian.org:
> block 798476 with 870788
Bug #798476 [debian-policy] debian-policy: don't require Uploaders
798476 was not blocked by any bugs.
798476 was not blocking any bugs.
Added blocking bug(s) of 798476: 870788
> thanks
Stopping processing here.
Please co
Hello,
On Fri, Aug 04 2017, Adrian Bunk wrote:
> Autogenerating Uploaders like GNOME does [1] would be an alternative
> approach.
>
> [1]
> https://sources.debian.net/src/gnome-pkg-tools/0.19.9/1/rules/uploaders.mk/
I don't understand this suggestion. If it can be automatically
generated, just
Package: tracker.debian.org
Severity: wishlist
On Thu, Aug 03 2017, Holger Levsen wrote:
> Then, Tobias has a point, knowing which team members uploaded a package is
> useful. So I have a simple proposal to achieve that: make tracker.d.o
> show the last 10 uploaders for a given package (based on
Hi,
Ansgar Burchardt wrote:
> as a more radical change one could also ask the question where to
> maintain the maintainer information. Currently we handle this in the
> source package via the Maintainer and Uploaders field, and via team
> memberships.
>
> This has several limitations: for teams,
Adrian Bunk writes:
> In a more general note, I am a bit puzzled that it is so controversial
> that machine-readable team membership information is important and
> should continue to be available.
One of the major points of disagreement in this thread is that you think
this information is curren
On Fri, 04 Aug 2017, Adrian Bunk wrote:
> And in the other direction what you describe would leave no way for a
> person to make it visible that he has left the team.
It is rarely my experience that people leave teams in clean, definitive
breaks. If they did, packages wouldn't have to be orphaned
On Fri, Aug 04, 2017 at 10:46:19PM +0200, Bill Allombert wrote:
> On Fri, Aug 04, 2017 at 11:59:40AM -0700, Don Armstrong wrote:
> > > An O: bug means that it is confirmed that the package is orphaned, and
> > > gives permission to everyone to adopt the package immediately.
> >
> > So just file an
On Fri, Aug 04, 2017 at 11:59:40AM -0700, Don Armstrong wrote:
> > An O: bug means that it is confirmed that the package is orphaned, and
> > gives permission to everyone to adopt the package immediately.
>
> So just file an an Intent-To-Orphan bug. [This why I suggested to file
> the bug against
On Fri, Aug 04, 2017 at 11:59:40AM -0700, Don Armstrong wrote:
> On Fri, 04 Aug 2017, Adrian Bunk wrote:
>...
> > Uploaders is not the only option for doing that, but any change should
> > include provising more reliable information - not less reliable
> > information.
>
> In practice, Uploaders o
Processing control commands:
> tag -1 +pending
Bug #839172 [debian-policy] TC decision regarding #741573 menu policy not
reflected yet
Added tag(s) pending.
--
839172: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=839172
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
control: tag -1 +pending
Hello Didier,
On Fri, Aug 04, 2017 at 11:22:28AM +0200, Didier 'OdyX' Raboud wrote:
> I now gathered some old memories and remembered that there was indeed a bug
> about this that got stalled: #707851 (which was the TC bug). See from message
> #475 (September 2015), whe
Sean Whitton writes:
> diff --git a/policy.xml b/policy.xml
> index 3daa532..934a85b 100644
> --- a/policy.xml
> +++ b/policy.xml
> @@ -8990,14 +8990,8 @@ Reloading description
> configuration...done.
> receive extra contributions such as translations.
>
>
> -Pac
On Thu, Aug 03, 2017 at 03:38:47PM -0700, Russ Allbery wrote:
> Previously, we've always kept tombstone sections that just say "this
> section has been deleted" so that the sections aren't renumbered.
> Otherwise, we have to update the section numbers in upgrading-checklist
> (and possibly invalida
On Thu, Aug 03, 2017 at 03:43:56PM +, Mike Gabriel wrote:
> I am not saying that the build target must not be empty. I can be empty but
> the build-a ... build-n dependecies have to be moved away from the binary
> target and have to be made dependencies of the build target (which can only
> hav
Hello Mike,
On Thu, Aug 03, 2017 at 03:09:30PM +, Mike Gabriel wrote:
> How would differentiate between a blank in a file name and a blank as a
> separator?
If you needed blanks in filenames, you'd use a line-based list.
--
Sean Whitton
signature.asc
Description: PGP signature
On Fri, 04 Aug 2017, Adrian Bunk wrote:
> And it would not work when the latest maintainer upload was by a team
> member who retired or was declared MIA earlier.
That can be found out by recursing until you find a non-MIA individual
who has uploaded since the previous stable release, or something
On Fri, Aug 04, 2017 at 08:25:57AM -0700, Don Armstrong wrote:
> On Fri, 04 Aug 2017, Adrian Bunk wrote:
> > Regressing on being able to orphan all packages of a known-MIA/retired
> > maintainer would be very bad.
> >
> > Think of it as a 3 step process:
>
> [...]
>
> > 3. for every package where
On Fri, 04 Aug 2017, Adrian Bunk wrote:
> Regressing on being able to orphan all packages of a known-MIA/retired
> maintainer would be very bad.
>
> Think of it as a 3 step process:
[...]
> 3. for every package where the maintainer is in Maintainer or Uploaders
>the MIA team either orphans th
On Fri, Aug 4, 2017 at 6:10 AM, Ansgar Burchardt wrote:
> So I have been wondering several times whether we should move the
> maintainer information elsewhere. For example, tracker.d.o could be
> extended to record maintainer information. It could also understand
> the concept of "teams" listing
Hi,
as a more radical change one could also ask the question where to
maintain the maintainer information. Currently we handle this in the
source package via the Maintainer and Uploaders field, and via team
memberships.
This has several limitations: for teams, Uploaders will often be
useless (yo
On Thu, Aug 03, 2017 at 06:48:27PM -0700, Russ Allbery wrote:
>...
> One approach as Holger points out: look for
> packages where all the recent uploads have been by the MIA member, which
> doesn't require the Uploaders field at all.
As I already tried to explain, this is an easy part that could b
Le jeudi, 3 août 2017, 08.53:09 h CEST Didier 'OdyX' Raboud a écrit :
> Le mardi, 1 août 2017, 11.01:10 h CEST Sean Whitton a écrit :
> > On Thu, Sep 29, 2016 at 02:55:31PM -0400, Sam Hartman wrote:
> > > We also approved the decision that packages should not include both a
> > > menu file and a de
23 matches
Mail list logo
