In our current arrangements, the TC is the only body who can rescue a
package from a maintainer who is determined to sit on it.[1]
The TC have never exercised this power, when a maintainer has insisted
that they want to keep maintaining the package.
It is surely obvious that there must have been
On Thu, Dec 01, 2016 at 03:46:05PM +, Ian Jackson wrote:
> There is a recent case where:
> * The maintainer has done nothing to the package for many years,
>other than infrequent (and usually short) emails to NAK
>contributions from others;
> * The package is years out of date compare
Hello,
On Thu, Dec 01, 2016 at 03:46:05PM +, Ian Jackson wrote:
> Regardless of the reasons, this is not good enough.
>
> Maintainership is a leadership position, with serious governance
> authority. Leaders must be accountable. Bad leaders must be
> replaced.
>
> It is clear to me that th
Mattia Rizzolo writes ("Re: Replace the TC power to depose maintainers"):
> We have a very similar case within the MIA team [...]
Thanks, yes, I remember reading about that. I think less-severe but
still very bad situations are probably more common :-/.
> > 2. Provide a new p
Sean Whitton writes ("Re: Replace the TC power to depose maintainers"):
> Although I don't personally know of any such DDs, I agree that random
> selection sounds like a bad idea. DDs who don't want to be involved in
> this sort of work would feel under some obligati
❦ 1 décembre 2016 15:46 GMT, Ian Jackson :
> There is a recent case where:
> * The maintainer has done nothing to the package for many years,
>other than infrequent (and usually short) emails to NAK
>contributions from others;
> * The package is years out of date compared to upstream,
Mattia Rizzolo writes ("Re: Replace the TC power to depose maintainers"):
> We have a very similar case within the MIA team (the willing contributor
> contacted us instead of the TC). The only difference is probably that
> the maintainer sent his NAK to me on IRC instead of
On Thu, Dec 01, 2016 at 06:00:42PM +, Ian Jackson wrote:
> I envisioned a mediation stage, to try to reach consensus, before
> deciding the conflict is irreducible and needs to be settled as such.
>
> Could the MIA team do this ? Would you want to ? It seems like it
> would need many of the
On Thu, Dec 01, 2016 at 03:46:05PM +, Ian Jackson wrote:
> 3. Abolish maintainership entirely.
This is the obviously right solution.
Everything else would be a temporary work-around to inefficiencies and
bugs introduced by the existence of explicit maintainership.
With explicit maintainershi
On Thu, Dec 01, 2016 at 07:20:36PM +0100, Stefano Zacchiroli wrote:
> We should go for "weak code ownership" instead, which *in theory* is
> what we already have (given every DD can NMU any package), but the
> *culture* of strong ownership is so rooted in the project that people
> are still too afr
On Thu, Dec 01, 2016 at 06:26:28PM +, Clint Adams wrote:
> On Thu, Dec 01, 2016 at 07:20:36PM +0100, Stefano Zacchiroli wrote:
> > We should go for "weak code ownership" instead, which *in theory* is
> > what we already have (given every DD can NMU any package), but the
> > *culture* of strong
Stefano Zacchiroli writes ("Re: Replace the TC power to depose maintainers"):
> On Thu, Dec 01, 2016 at 03:46:05PM +, Ian Jackson wrote:
> > 3. Abolish maintainership entirely.
>
> This is the obviously right solution.
I can see why this is attractive. But as I sa
Hi,
I'm just commenting on this single issue (and aspect of it…) here+now…
On Thu, Dec 01, 2016 at 07:20:36PM +0100, Stefano Zacchiroli wrote:
> On Thu, Dec 01, 2016 at 03:46:05PM +, Ian Jackson wrote:
> > 3. Abolish maintainership entirely.
> This is the obviously right solution.
while I ca
Hi,
Quoting Ian Jackson (2016-12-02 12:43:52)
> Stefano Zacchiroli writes ("Re: Replace the TC power to depose maintainers"):
> > On Thu, Dec 01, 2016 at 03:46:05PM +, Ian Jackson wrote:
> > > 3. Abolish maintainership entirely.
> >
> > This is the
Hi,
Quoting Holger Levsen (2016-12-02 13:11:05)
> I'm just commenting on this single issue (and aspect of it…) here+now…
>
> On Thu, Dec 01, 2016 at 07:20:36PM +0100, Stefano Zacchiroli wrote:
> > On Thu, Dec 01, 2016 at 03:46:05PM +, Ian Jackson wrote:
> > > 3. Abolish maintainership entirel
Johannes Schauer writes ("Re: Replace the TC power to depose maintainers"):
> Quoting Ian Jackson (2016-12-02 12:43:52)
> > And it is this very rule which is the problem. If you propose to
> > solve the stop-energy maintainer deathgrip problem by abolishing
> > ma
On Fri, Dec 02, 2016 at 01:40:31PM +0100, Johannes Schauer wrote:
> > motivation. being able to say "I'm the maintainer of $foo" is a *great*
> > motivation for many. Taking this away *might* cause a lot more harm that
> > gain.
> Why would this be taken away?
motivation works in strange ways. an
On Fri, Dec 02, 2016 at 01:32:40PM +0100, Johannes Schauer wrote:
> Quoting Ian Jackson (2016-12-02 12:43:52)
> > Otherwise it really will be chaos, with people uploading contra-reverts of
> > each others' reverts.
>
> Personally, I doubt that this would happen. In a world without maintainership,
On Fri, Dec 02, 2016 at 01:39:30PM +, Holger Levsen wrote:
> On Fri, Dec 02, 2016 at 01:40:31PM +0100, Johannes Schauer wrote:
> > > motivation. being able to say "I'm the maintainer of $foo" is a *great*
> > > motivation for many. Taking this away *might* cause a lot more harm that
> > > gain.
Stefano Zacchiroli writes ("Re: Replace the TC power to depose maintainers"):
> On Thu, Dec 01, 2016 at 03:46:05PM +, Ian Jackson wrote:
> > 3. Abolish maintainership entirely.
>
> This is the obviously right solution.
Hey, I have an idea that maybe you will support,
On 2016-12-02 13:32:40, Johannes Schauer wrote:
> Quoting Ian Jackson (2016-12-02 12:43:52)
> > Otherwise it really will be chaos, with people uploading contra-reverts of
> > each others' reverts.
>
> Personally, I doubt that this would happen. In a world without maintainership,
> I'd expect anybo
On Fri, 02 Dec 2016, Holger Levsen wrote:
> I'm not saying people like you dont exist, nor that your reasoning aint
> sensible. I've just said some people take motivation from being listed
> as maintainer.
We could get rid of "Maintainer" in debian/control and still display
on tracker.debian.org t
On Sat, Dec 3, 2016 at 6:20 AM, Raphael Hertzog wrote:
> We could get rid of "Maintainer" in debian/control and still display
> on tracker.debian.org the name of people who are uploading/committing
> in a dynamic "Maintainer" section.
>
> Actually, this is part of my grand-plan... :-) aka
> http:/
Paul Wise writes ("Re: Replace the TC power to depose maintainers"):
> I'd like to reframe this discussion a little bit...
>
> What exactly is the Maintainer* field for?
>
> Initially it was a way for individuals to declare their commitment to
> perform all tas
Hi
How do I unsubscribe from the debian project mailing list?
On Dec 1, 2016 9:48 PM, "Mattia Rizzolo" wrote:
> On Thu, Dec 01, 2016 at 03:46:05PM +, Ian Jackson wrote:
> > There is a recent case where:
> > * The maintainer has done nothing to the package for many years,
> >other than
On Sat, 2016-12-03 at 10:27 +, Ian Jackson wrote:
> Mainly, it was a way to control who got email about the package.
Why was it called Maintainer instead of something more suitable then?
> I was there at the time; this may even have been my fault. Sorry.
No worries, this is all hindsight t
Hi
How do I unsubscribe from Debian Project mailing list?
Thanks and Regards.
Sheetal Shalini
3rd Year B.Tech CSE
NITK Surathkal
On Sat, Dec 3, 2016 at 4:12 PM, Paul Wise wrote:
> On Sat, 2016-12-03 at 10:27 +, Ian Jackson wrote:
>
> > Mainly, it was a way to control who got email abo
On Fri, Dec 02, 2016 at 03:42:58PM +, Ian Jackson wrote:
> DRAFT GENERAL RESOLUTION STARTS
>
> OPTION A
= "keep the status quo"
> OPTION B
equals:
> 7. We amend the Constitution section 6.1(4) to remove the words
> "requires a 3:1 majority" and "this requires a 3:1 majority".
Sheetal Shalini writes:
> Hi
>
> How do I unsubscribe from Debian Project mailing list?
>
see the instructions on
https://lists.debian.org/debian-project/
Holger Levsen writes ("Re: Replace the TC power to depose maintainers"):
> On Fri, Dec 02, 2016 at 03:42:58PM +, Ian Jackson wrote:
> > DRAFT GENERAL RESOLUTION STARTS
> >
> > OPTION A
>
> = "keep the status quo"
AIUI, no.
Empirically, pr
Mattia Rizzolo:
> On Thu, Dec 01, 2016 at 03:46:05PM +, Ian Jackson wrote:
> > The key question for such a new process is: who will decide ?
> >
> > It is very tempting to model such a thing on our existing
> > constitutional structures. For example, we could create a team like
> > DAM, whose
Ian Jackson writes:
> Holger Levsen writes ("Re: Replace the TC power to depose maintainers"):
>> On Fri, Dec 02, 2016 at 03:42:58PM +, Ian Jackson wrote:
>> > DRAFT GENERAL RESOLUTION STARTS
>> >
>> > OPTION A
>>
>> = "keep
Philip Hands writes ("Re: Replace the TC power to depose maintainers"):
> this NOOP,
I'm very surprised to see you say that you think this is a no-op.
ISTM that in the current argument, the TC has given the position of
the existing maintainer great weight.
Imagine the r
ng as trigger to this very discussion [0], although some TC
members have already expressed opinions (mostly both ways, I feel), the TC
hasn't taken a decision yet. It therefore feels quite premature to launch a
"Replace the TC power to depose maintainers" discussion.
By launching th
Le vendredi, 2 décembre 2016, 15.42:58 h CET Ian Jackson a écrit :
> Hey, I have an idea that maybe you will support, which takes us much
> more in that direction and may reinvigorate our existing processes:
>
> DRAFT GENERAL RESOLUTION STARTS
As a general comment, I am in discomfort with GR pro
Didier 'OdyX' Raboud writes ("Re: Replace the TC power to depose maintainers"):
> I think you're really jumping the gun here. While the TC is not
> known for acting rapidly, I (would like to) think it is becoming
> better. In the "recent case" you'
Ian Jackson writes ("Re: Replace the TC power to depose maintainers"):
> I still don't understand why the TC is so crushingly slow to conter
> maintainer power in Debian. As I say in my other emails, a result of
> the TC's inaction, maintainer power in Debian is near
Le lundi, 5 décembre 2016, 14.41:01 h CET Ian Jackson a écrit :
> The bug was filed on the 19th of October. That was nearly 7 weeks
> ago.
Sure. I'm not saying the TC couldn't be better.
> That is 6+ weeks' more stop-energy. 6+ weeks' more inaction.
I agree with that.
> 6+ weeks during which
Didier 'OdyX' Raboud writes ("Re: Replace the TC power to depose maintainers"):
> Le lundi, 5 décembre 2016, 14.41:01 h CET Ian Jackson a écrit :
> > 6+ weeks during which members of the TC have been prevaricating.
>
> I had to lookup prevaricate in a
Ian Jackson writes:
> Philip Hands writes ("Re: Replace the TC power to depose maintainers"):
>> this NOOP,
>
> I'm very surprised to see you say that you think this is a no-op.
>
> ISTM that in the current argument, the TC has given the position of
&g
Ian Jackson writes:
> Ian Jackson writes ("Re: Replace the TC power to depose maintainers"):
>> I still don't understand why the TC is so crushingly slow to conter
>> maintainer power in Debian. As I say in my other emails, a result of
>> the TC's inact
]] Ian Jackson
> Imagine the roles were replaced. Imagine the actual petitioners (P
> and W, for the same of argument) were the current maintainers, and the
> actual current maintainer (R) were a petitioner saying "please make me
> the maintainer". Would the TC would spend months debating befor
]] Ian Jackson
> That is 6+ weeks' more stop-energy. 6+ weeks' more inaction. 6+
> weeks during which members of the TC have been prevaricating.
What are you accusing the TC of lying about?
--
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are
]] Ian Jackson
> Didier 'OdyX' Raboud writes ("Re: Replace the TC power to depose
> maintainers"):
> > Le lundi, 5 décembre 2016, 14.41:01 h CET Ian Jackson a écrit :
> > > 6+ weeks during which members of the TC have been prevaricating.
> >
Tollef Fog Heen writes:
> ]] Ian Jackson
>
>> That is 6+ weeks' more stop-energy. 6+ weeks' more inaction. 6+
>> weeks during which members of the TC have been prevaricating.
>
> What are you accusing the TC of lying about?
I think that British English has drifted into using that as a synonym
]] Philip Hands
> Tollef Fog Heen writes:
>
> > ]] Ian Jackson
> >
> >> That is 6+ weeks' more stop-energy. 6+ weeks' more inaction. 6+
> >> weeks during which members of the TC have been prevaricating.
> >
> > What are you accusing the TC of lying about?
>
> I think that British English ha
Tollef Fog Heen writes:
> ]] Philip Hands
>
>> Tollef Fog Heen writes:
>>
>> > ]] Ian Jackson
>> >
>> >> That is 6+ weeks' more stop-energy. 6+ weeks' more inaction. 6+
>> >> weeks during which members of the TC have been prevaricating.
>> >
>> > What are you accusing the TC of lying about?
Tollef Fog Heen writes ("Re: Replace the TC power to depose maintainers"):
> They might want to consult a dictionary then,
I.
Chambers English Dictionary (1994 edition, which is what I have):
prevaricate (vi)
to avoid stating the truth or coming directly to the point;
to qui
Tollef Fog Heen writes ("Re: Replace the TC power to depose maintainers"):
> Because I generally find it's generally the wrong tool for the job. If
> I can come up with a good explanation for why somebody should take a
> particular course of action (which I need before
On 2016-12-05 20:57, Philip Hands wrote:
> Tollef Fog Heen writes:
>> ]] Ian Jackson
>>> That is 6+ weeks' more stop-energy. 6+ weeks' more inaction. 6+
>>> weeks during which members of the TC have been prevaricating.
>> What are you accusing the TC of lying about?
> I think that British En
On Monday, December 05, 2016 10:02:02 PM Ian Jackson wrote:
> Tollef Fog Heen writes ("Re: Replace the TC power to depose maintainers"):
> > Because I generally find it's generally the wrong tool for the job. If
> > I can come up with a good explanation
Scott Kitterman writes ("Re: Replace the TC power to depose maintainers"):
> Nonsense. There's no risk for a non-maintainer to come to the TC.
A non-maintainer who comes to the TC:
* Is very likely to find that already unpleasant situation, gets
emotionally worse, at
On Monday, December 05, 2016 11:18:41 PM Ian Jackson wrote:
> Scott Kitterman writes ("Re: Replace the TC power to depose maintainers"):
> > Nonsense. There's no risk for a non-maintainer to come to the TC.
>
> A non-maintainer who comes to the TC:
>
> *
]] Ian Jackson
There's no need to Cc me on replies, I'm subscribed already.
> Tollef Fog Heen writes ("Re: Replace the TC power to depose maintainers"):
> > Because I generally find it's generally the wrong tool for the job. If
> > I can come up with a
Scott Kitterman writes ("Re: Replace the TC power to depose maintainers"):
> Having been involved in one of these things even as a maintainer of
> a package that was not directly the target of the request to the TC
> was extremely trying. [etc.]
Thanks for sharing your experie
Stefano Zacchiroli writes ("Re: Replace the TC power to depose maintainers"):
> We should go for "weak code ownership" instead,
I was thinking about what Scott wrote, and also went back and read
some of the bug log he is referring to. I wonder if there is an
underlying a u
On Thu, 2016-12-01 at 15:46 +, Ian Jackson wrote:
> There is a recent case where:
> * The maintainer has done nothing to the package for many years,
> other than infrequent (and usually short) emails to NAK
> contributions from others;
> * Several times, proposed updates have been prepa
Le mercredi, 7 décembre 2016, 08.49:57 h CET Russell Stuart a écrit :
> Why not have a formal rule that says if a package in Debian is out of
> date for more than one release cycle any DD can package it under a
> different name, after going through the usual ITP procedures coupled
> with a bug repo
On Tue, Dec 06, 2016 at 02:29:13PM +, Ian Jackson wrote:
> Can we come up with some way whereby the maintainership authority is
> always shared, somehow ?
The net result of this would be that anyone who maintains packages in
Debian will do so as part of a team. Likely, people maintaining more
Stefano Zacchiroli writes ("Re: Replace the TC power to depose maintainers"):
> So my question here is: why would someone who has learned to work
> amicably *within* the boundaries of several teams, will behave any
> different *across* those boundaries, when contributing to pac
Didier 'OdyX' Raboud writes ("Re: Replace the TC power to depose maintainers"):
> If one feels the source package isn't kept up-to-date enough, she
> can "just" file an ITP for a new source package name, pointing to
> hir attempts at convincing the
On Wednesday, December 07, 2016 11:21:23 AM Stefano Zacchiroli wrote:
> On Tue, Dec 06, 2016 at 02:29:13PM +, Ian Jackson wrote:
> > Can we come up with some way whereby the maintainership authority is
> > always shared, somehow ?
>
> The net result of this would be that anyone who maintains p
[Scott Kitterman, 2016-12-08]
> I feel a personal sense of responsibility towards the packages where I appear
> as Maintainer or in Uploaders. In my mind, adding myself there represents
> both authority to make decisions and responsibilities.
>
> Take that away and I do believe I'll feel less
On Sat, Dec 03, 2016 at 05:08:06PM +0100, Jérémy Bobbio wrote:
> > > For each such dispute, we should pick a panel of randomly chosen DDs,
> > > and have them decide (with a time limit).
> >
> > No randomness please. Probably all bodies in Debian are either elected
> > or appointed (by previously
On Fri, Dec 02, 2016 at 01:39:30PM +, Holger Levsen wrote:
> On Fri, Dec 02, 2016 at 01:40:31PM +0100, Johannes Schauer wrote:
> > > motivation. being able to say "I'm the maintainer of $foo" is a *great*
> > > motivation for many. Taking this away *might* cause a lot more harm that
> > > gain.
Hi,
* Johannes Schauer [2016-12-02 13:40:31 CET]:
> Quoting Holger Levsen (2016-12-02 13:11:05)
> > I'm just commenting on this single issue (and aspect of it…) here+now…
> >
> > On Thu, Dec 01, 2016 at 07:20:36PM +0100, Stefano Zacchiroli wrote:
> > > On Thu, Dec 01, 2016 at 03:46:05PM +000
Ian Jackson writes:
> I still don't understand why the TC is so crushingly slow to conter
> maintainer power in Debian. As I say in my other emails, a result of
> the TC's inaction, maintainer power in Debian is nearly unassailable.
I wonder which column on your tally sheet you will put this ou
Dear Ian, TC members and everybody,
the discussion about maintainership is interesting, and maybe I will post a
comment later, but I think that the main problem is the speed of the TC to take
its decissions.
And one very important comment that was made in this thread is that the TC
needs wide sup
Le Sun, Dec 11, 2016 at 03:00:22PM +0900, Charles Plessy a écrit :
>
> Dear TC, you have my support, and please feel empowered to require high
> standards from the confronting parties that ask for your decisions, so that
> your task is made easier, for everybody' good.
>
> - The TC members shoul
Rhonda D'Vine writes ("Re: Replace the TC power to depose maintainers"):
> Going towards an abolished maintainership
> area it will make it even less likely such needed communication with the
> people feeling emotionally attached to the package to happen.
This is a ver
Philip Hands writes ("Re: Replace the TC power to depose maintainers"):
> Ian Jackson writes:
> > I still don't understand why the TC is so crushingly slow to conter
> > maintainer power in Debian. As I say in my other emails, a result of
> > the TC'
Charles Plessy writes ("Re: Replace the TC power to depose maintainers"):
> Dear Ian, TC members and everybody,
...
> Dear TC, you have my support, and please feel empowered to require high
> standards from the confronting parties that ask for your decisions, so that
> yo
]] Ian Jackson
> Philip Hands writes ("Re: Replace the TC power to depose maintainers"):
> > Ian Jackson writes:
> > > I still don't understand why the TC is so crushingly slow to conter
> > > maintainer power in Debian. As I say in my other e
Tollef Fog Heen writes ("Re: Replace the TC power to depose maintainers"):
> > Philip Hands writes ("Re: Replace the TC power to depose maintainers"):
> > I think the maintainer saw the writing on the wall, so I count this as
> > a successful intervention b
Since I didn't want to sent too many more emails, I'll make three
short replies in one email...
Stefano Zacchiroli writes ("Re: Replace the TC power to depose maintainers"):
> We should go for "weak code ownership" instead, which *in theory* is
> what we alread
Ian Jackson writes:
> Stefano Zacchiroli writes ("Re: Replace the TC power to depose maintainers"):
>> We should go for "weak code ownership" instead, which *in theory* is
>> what we already have
> Well, no. What we have is a kind of sticky door when t
Russ Allbery writes ("Re: Replace the TC power to depose maintainers [and 1
more messages]"):
> Ian Jackson writes:
> > The TC has never desposed an existing maintainer, and very rarely even
> > overturned an individual decision.
>
> There is a widespread p
We've had the "strong package ownership" concept be a problem in
various ways. Many years ago people were afraid of making NMUs to fix
bugs, even RC bugs, and I started the
https://wiki.debian.org/LowThresholdNmu page. It's got over 300
maintainers now, and NMUs are quite normal, though I suspect z
Dear all
El 05/12/16 a las 19:13, Lars Wirzenius escribió:
> We've had the "strong package ownership" concept be a problem in
> various ways. Many years ago people were afraid of making NMUs to fix
> bugs, even RC bugs, and I started the
> https://wiki.debian.org/LowThresholdNmu page. It's got ove
On Mon, Dec 05, 2016 at 08:02:27PM +0100, Laura Arjona Reina wrote:
> I have just created the page:
>
> https://wiki.debian.org/LowThresholdAdoption
>
> and added myself to the list.
I've added myself to the list.
--
I want to build worthwhile things that might last. --joeyh
signature.asc
De
]] Lars Wirzenius
> I suggest a lighter approach than a GR for eroding the strong package
> ownership further is to start another page, "LowThresholdHijack" or
> something, listing maintainers who are OK if someone hijacks their
> package if the maintainer isn't taking good care of it. Would anyo
Tollef Fog Heen writes ("Re: Replace the TC power to depose maintainers [and 1
more messages]"):
Lars Wirzenius
> > I suggest a lighter approach than a GR for eroding the strong package
> > ownership further is to start another page, "LowThresholdHijack" or
&g
]] Ian Jackson
> Tollef Fog Heen writes ("Re: Replace the TC power to depose maintainers [and
> 1 more messages]"):
> Lars Wirzenius
> > > I suggest a lighter approach than a GR for eroding the strong package
> > > ownership further is to start
On Thu, 2016-12-01 at 19:20:36 +0100, Stefano Zacchiroli wrote:
> On Thu, Dec 01, 2016 at 03:46:05PM +, Ian Jackson wrote:
> > 3. Abolish maintainership entirely.
>
> This is the obviously right solution.
It is not only not obviously right to me, instead it seems obvious
it carries a set of d
On Thu, 08 Dec 2016, Guillem Jover wrote:
> It is not only not obviously right to me, instead it seems obvious
> it carries a set of different problems with it. I feel this carries
> so many assumptions of how the proposers feel about how *they* work
> or might like to work and ignores how *others*
Hi,
Quoting Ian Jackson (2016-12-05 23:04:48)
> Tollef Fog Heen writes ("Re: Replace the TC power to depose maintainers [and
> 1 more messages]"):
> > A similar proposal: Have a way of declaring the package to be under
> > collective maintenance (put it
On Tue, Dec 06, 2016 at 09:18:49AM +0100, Johannes Schauer wrote:
> What I currently find inconvenient about the LowThresholdNmu page is, that it
> is external to the source package. So after having found a package I want to
> fix I have to manually look up on that wiki page whether the maintainer
Johannes Schauer writes ("Formal declaration of weak package ownership in
source packages (was: Replace the TC power to depose maintainers)"):
> I think the thread has derailed here a little bit but I think that
> Lars and Tollef are aware that their proposals are orthogonal to t
Hi,
Quoting Adam Borowski (2016-12-06 09:36:08)
> On Tue, Dec 06, 2016 at 09:18:49AM +0100, Johannes Schauer wrote:
> > What I currently find inconvenient about the LowThresholdNmu page is, that
> > it
> > is external to the source package. So after having found a package I want to
> > fix I have
On Tue, Dec 06, 2016 at 02:55:57PM +0100, Johannes Schauer wrote:
> Quoting Adam Borowski (2016-12-06 09:36:08)
> > On Tue, Dec 06, 2016 at 09:18:49AM +0100, Johannes Schauer wrote:
> > > What I currently find inconvenient about the LowThresholdNmu page is,
> > > that it
> > > is external to the s
On Tue, Dec 06, 2016 at 03:08:54PM +0100, Adam Borowski wrote:
> > https://tracker.debian.org/pkg/multistrap
> I see that https://wiki.debian.org/LowThresholdNmu lists you as
> [[JohannesSchauer|Johannes 'josch' Schauer]] while the maintainer field is
> Johannes Schauer , that obviously breaks a st
Hi,
Quoting Holger Levsen (2016-12-06 15:15:53)
> On Tue, Dec 06, 2016 at 03:08:54PM +0100, Adam Borowski wrote:
> > > https://tracker.debian.org/pkg/multistrap
> > I see that https://wiki.debian.org/LowThresholdNmu lists you as
> > [[JohannesSchauer|Johannes 'josch' Schauer]] while the maintainer
On Tue, Dec 06, 2016 at 03:50:12PM +0100, Johannes Schauer wrote:
> Actually, this is a great argument for why this information should be in a
> deb822 field in the source package itself.
FWIW, I think this is the kind of information that should be kept out
of the source package, since changing it
Hi,
Quoting Lars Wirzenius (2016-12-06 16:06:30)
> On Tue, Dec 06, 2016 at 03:50:12PM +0100, Johannes Schauer wrote:
> > Actually, this is a great argument for why this information should be in a
> > deb822 field in the source package itself.
>
> FWIW, I think this is the kind of information that
On Tue, Dec 06, 2016 at 04:15:22PM +0100, Johannes Schauer wrote:
> why would it be important to change that kind of information for a package in
> stable? The audience interested in this field is interested in uploads to
> unstable, so is it not sufficient if the information is up-to-date there?
On Tue, Dec 06, 2016 at 04:15:22PM +0100, Johannes Schauer wrote:
> why would it be important to change that kind of information for a package in
> stable? The audience interested in this field is interested in uploads to
> unstable, so is it not sufficient if the information is up-to-date there?
Lars Wirzenius writes ("Re: Formal declaration of weak package ownership in
source packages (was: Replace the TC power to depose maintainers)"):
> For example, there's corner cases that get tricky. A package might
> only be in stable, but the maintainer w
* Adam Borowski [161206 10:10]:
> On Tue, Dec 06, 2016 at 09:18:49AM +0100, Johannes Schauer wrote:
> > What I currently find inconvenient about the LowThresholdNmu page is, that
> > it
> > is external to the source package. So after having found a package I want to
> > fix I have to manually loo
On Tue, Dec 06, 2016 at 03:42:57PM +, Ian Jackson wrote:
> > It's a lot simpler to keep this metadata outside source package.
> I endorse this product and/or service.
Here's one way to quickly build a service like this:
- Configure the web server to accept Debian's SSO credentials:
http
Enrico Zini writes ("Re: Formal declaration of weak package ownership in source
packages (was: Replace the TC power to depose maintainers)"):
> On Tue, Dec 06, 2016 at 03:42:57PM +, Ian Jackson wrote:
> > > It's a lot simpler to keep this metadata outside source
1 - 100 of 107 matches
Mail list logo
