Re: How to install Debian 8.6.0 dvd 2 & 3 from iso
On Thu, Dec 1, 2016 at 8:12 PM, Chandan raj wrote: > I want to install Debian 8.6.0 dvd 2 and 3 which is in the .iso format > without burning it in dvd.I have installed dvd 1 which contain operating > system.Can I install it after installing Debian operating system. Please contact the Debian user support channels for help: https://www.debian.org/support -- bye, pabs https://wiki.debian.org/PaulWise
Re: Replace the TC power to depose maintainers
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 ownership is so rooted in the project that people > > are still too afraid of using it. Also, we don't have good tools[^] that > > Indeed, and it has apparently even crept into team maintenance such > that team members don't touch "other people's" team-maintained > packages. Fortunately this is true only for few teams (sadly big/"important"). -- regards, Mattia Rizzolo GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`. more about me: https://mapreri.org : :' : Launchpad user: https://launchpad.net/~mapreri `. `'` Debian QA page: https://qa.debian.org/developer.php?login=mattia `- signature.asc Description: PGP signature
Re: Replace the TC power to depose maintainers
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 afraid of using it. Also, we don't have good tools[^] that Indeed, and it has apparently even crept into team maintenance such that team members don't touch "other people's" team-maintained packages. > I'm personally convinced that a strong, symbolic act is needed to > actually make weak code ownership a reality in Debian. Abolishing the > Maintainer field all together[*] might be it. Sounds good to me.
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. Everything else would be a temporary work-around to inefficiencies and bugs introduced by the existence of explicit maintainership. With explicit maintainership Debian is ignoring well-known software engineering best practices, and most notably the fact that "strong code ownership" is bad and invariably gets in the way of effective collaborative development. 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 afraid of using it. Also, we don't have good tools[^] that make it trivial to integrate back changes that have been NMUed by others; again, getting in the way of efficient collaboration. I'm personally convinced that a strong, symbolic act is needed to actually make weak code ownership a reality in Debian. Abolishing the Maintainer field all together[*] might be it. Revolutionary yours, Cheers. [^] well, we have dgit, but AFAICT is not really popular yet [*] together with making sure that any DD can commit to any public repo on alioth -- Stefano Zacchiroli . z...@upsilon.cc . upsilon.cc/zack . . o . . . o . o Computer Science Professor . CTO Software Heritage . . . . . o . . . o o Former Debian Project Leader . OSI Board Director . . . o o o . . . o . « the first rule of tautology club is the first rule of tautology club » signature.asc Description: PGP signature
Re: Replace the TC power to depose maintainers
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 same skills and there would be considerable > overlap with existing MIA activity. > > It would be a role with little hard power but a lot of influence. Ideally, the MIA team could do it. Practically, we're a tad overloaded right now. As you probably know the team has been inactive for some years, and restarted being active only during spring this year; we ended up with a bit of a backlog -- regards, Mattia Rizzolo GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`. more about me: https://mapreri.org : :' : Launchpad user: https://launchpad.net/~mapreri `. `'` Debian QA page: https://qa.debian.org/developer.php?login=mattia `- signature.asc Description: PGP signature
Re: Replace the TC power to depose maintainers
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 in a email, and now
> he is not doing that either). The difference is that on paper we don't
> have the authority to "wrest the package away"; but I can't even mediate
> given that this person is not replying
This makes me ask:
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 same skills and there would be considerable
overlap with existing MIA activity.
It would be a role with little hard power but a lot of influence.
Ian.
An aside about mediation:
Mediation and arbitration are very different things.
Mediation is about seeing if facilitated communication can help bridge
the gap, and bring people together. It can be very helpful. However,
mediation is normally not very "justice"-focused: it tries to avoid
saying who is right and wrong.
It is important not to allow mediation to become a barrier to
arbitration, or some other process which is actually prepared to make
judgements. Since without judgement (which is what we have now), the
powerless will always be oppressed by the powerful.
--
Ian JacksonThese opinions are my own.
If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.
Re: Replace the TC power to depose maintainers
❦ 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, afflicted by >bitrot, and many users are asking for the new version; > * Several times, proposed updates have been prepared by contributors >but blocked by the maintainer; > * There are new maintainers ready and waiting, with a new package >ready for upload to sid for stretch; > * Now that the TC is involved the maintainer has written many emails >explaining their decisions to NAK uploads, but TC members are >clearly unconvinced on a technical level that those decisions were >right. > Even in this extreme situation the TC has not seen fit to wrest the > package away from the mainainer's deathgrip. The process is still ongoing, slow, but still. I would have waited a bit more to see where it is going before complaining of inaction. > 3. Abolish maintainership entirely. IMO, this would be a great option. We could keep an official maintainer or a team to keep someone responsible (but we have many examples where this is not sufficient). But otherwise, anyone should be able to upload any package. Maybe the use of a delayed queue (15 days?) could be mandated for those cases. We could also make the low threshold NMU opt-out instead of opt-in. Any step towards less maintainership would be great. -- The only way to keep your health is to eat what you don't want, drink what you don't like, and do what you'd rather not. -- Mark Twain signature.asc Description: PGP signature
Re: Replace the TC power to depose maintainers
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 obligation to respond, even if
> they know they're not really suited for it or feel that they need to
> focus their time into some of their own maintenance work, such as
> before/during a freeze.
I think there should be a way to opt out. (Unlike with jury service
in a common law criminal trial.)
So when a jury is needed, the robot would pick 10 random DDs and email
them an offer to participate. Each potential juror would get a few
days[1] to accept/decline. The robot would keep emailing more people
until it got a panel of 10 acceptances.
[1] This should be a short period both to keep the whole duration of
the uncertainty and pain short, but also to end up with jurors who are
around right now.
I think it would be best not to tell jurors, before the jury is
empanelled, what package is in dispute. (They might be able to tell
anyway.)
Ian.
--
Ian JacksonThese opinions are my own.
If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.
Re: Replace the TC power to depose maintainers
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 process for deposing a maintainer, or appointing
> >co-maintainers.
>
> Agree.
Great.
> > 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 elected bodies). We all know that there are
> DD with a known bad track at mediations which would be totally unfit for
> such a role.
By the time it has come to selecting a jury, I think the time for
mediation has probably ended. At the very least by invoking a formal
process , the complainants have significantly burned their bridges.
I agree that there are DDs who are totally unfit for a role on such a
jury. But that is why juries are a panel, rather than an individual.
I think we have few enough unsuitable DDs that the risk of a jury
panel containing many unsuitable people is quite low.
There are good reasons for selecting from a much bigger pool, rather
than electing or appointing a standing panel:
I want the panel deciding on such a maintainership to be able to
easily identify with complainants as well as maintainers. That means
they ought to be people who have, the rest of the time, less special
authority. (Although of course already DDdom is quite an
authority...)
I would like to have such cases judged by people who don't bring
baggage of their own previous arbitrations or leadership decisions
(outside of maintainership).
I would like the arbitration panel to be as representative of our
whole developer community as possible.
I would to avoid the arbitrators being self-selected: that will select
for people who are forthright, confident and prepared to fight, who
will sometimes have a very different view of the interactions in the
contributor/maintainer power relationship.
> > By a simple majority, the panel either reaffirms the maintainership of
> > the existing maintainers/uploaders, or transfers formal maintainership
> > to people nominated[2] by the complainants.
>
> This sounds a nicely cut idea to me, except for the randomness above.
How would you choose such a panel ?
I am somewhat uncomfortable with the idea of doing this like the DAM
team. Many of the volunteers we would get would be less than ideal.
The same applies to elections.
Juries are a very good fit for this. Each jury decides a specific
question, relating to specific people, and is then disbanded.
> > [2] Nomination of the new maintainers should be done at this stage.
> > Thus a a frustrated contributor who, if the petition fails, needs
> > goodwill of the curent maintainer, can ask others to front the
> > complaint and argue the case. This helps minimise the justified
> > fear of retaliation.
>
> Fear of retaliation in such a place is IMHO everything but justified.
> Or at least it shouldn't be...
If you are a contributor to a package, you're probably also a user,
and you are probably an advanced user perhaps with unusual use cases.
You rely on the package in Debian supporting your use cases.
If you get into a nasty dispute with the maintainer, this is at the
very least going to become more difficult.
Of course fear of retaliation ought never to be justified. But we
know that people with power will often use that power to defend their
own position. Of course people vary and Debian maintainers have in
part been selected for altruism or idealism. But I don't think Debian
package maintainers are so much better people than anyone else that
this isn't a problem.
To avoid seeing bad actions, we should arrange our social structures
so that bad actions are not invited, or not effective. Simply saying
"people should not do bad things" is hopeless.
Or to put it another way: everyone has the capacity for good and evil.
All of us should structure our society - and specifically, we in
Debian should structure our project - to bring the good out of people,
and to discourage the evil. The best principal way to discourage evil
is not to punish it, but simply to make doing good more effective.
Of course this thread is about what to do in situations where that has
failed. But even having an effective response to such failure itself
makes the failure less likely.
Or to put it another way: accountable leaders are better leaders.
Thanks,
Ian.
--
Ian JacksonThese opinions are my own.
If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.
Re: Replace the TC power to depose maintainers
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 the TC (the structure I set up for this purpose > when I wrote the constitution) is not delivering and probably never > will. Let me add that this can be a big turn-off for potential new contributors who are looking for a niche to fill in Debian. Oh, I use that package, there are some annoying packaging bugs, it could do with some patching and cleaning up -- but there seems to be no way to make it happen. > 3. Abolish maintainership entirely. > > > Of these 1 is what we have now. I think it is entirely unacceptable. > I don't think the project is politically ready for 3. We're certainly not politically ready, but it's worth noting that there are advantages to sole maintainership. A sense of responsibility for a package can motivate people to polish the package to a higher standard because it has their name on it. But this is a side discussion. > 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 job was to take (private) requests for > mediation/intervention, and who would eventually make some kind of > decision. > > But I would like to make a more radical suggestion. We should make > these decision by juries, rather than committee. Thank you for taking the time to come up with this suggestion. On Thu, Dec 01, 2016 at 05:18:32PM +0100, Mattia Rizzolo wrote: > No randomness please. Probably all bodies in Debian are either elected > or appointed (by previously elected bodies). We all know that there are > DD with a known bad track at mediations which would be totally unfit for > such a role. 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 obligation to respond, even if they know they're not really suited for it or feel that they need to focus their time into some of their own maintenance work, such as before/during a freeze. > > [2] Nomination of the new maintainers should be done at this stage. > > Thus a a frustrated contributor who, if the petition fails, needs > > goodwill of the curent maintainer, can ask others to front the > > complaint and argue the case. This helps minimise the justified > > fear of retaliation. > > Fear of retaliation in such a place is IMHO everything but justified. > Or at least it shouldn't be... This is a big issue for non-DDs, who are very often the people who want to take on these abandoned packages. It's not so much retaliation, but the prospect of looking like an usurper or insubordinator, which could make other DDs wary of sponsoring their uploads. -- Sean Whitton signature.asc Description: PGP signature
Re: Replace the TC power to depose maintainers
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 compared to upstream, afflicted by >bitrot, and many users are asking for the new version; > * Several times, proposed updates have been prepared by contributors >but blocked by the maintainer; > * There are new maintainers ready and waiting, with a new package >ready for upload to sid for stretch; > * Now that the TC is involved the maintainer has written many emails >explaining their decisions to NAK uploads, but TC members are >clearly unconvinced on a technical level that those decisions were >right. > Even in this extreme situation the TC has not seen fit to wrest the > package away from the mainainer's deathgrip. 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 in a email, and now he is not doing that either). The difference is that on paper we don't have the authority to "wrest the package away"; but I can't even mediate given that this person is not replying (this is this case reported in d-d: https://lists.debian.org/debian-devel/2016/11/msg00320.html ) > 1. Recognise that Debian will never depose a maintainer, no matter >what. Maintainers are, within their packages, dictators (subject >only to the possibility of TC overrule on individual issues, which >is itself very very rare). The only way to get rid of a bad >maintainer is to wear them down unti they eventually go away. This is silly. We have a issue that really needs resolving. > 2. Provide a new process for deposing a maintainer, or appointing >co-maintainers. Agree. > 3. Abolish maintainership entirely. This would be a mess, as you acknowledged. > 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 job was to take (private) requests for > mediation/intervention, and who would eventually make some kind of > decision. > > But I would like to make a more radical suggestion. We should make > these decision by juries, rather than committee. > > 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 elected bodies). We all know that there are DD with a known bad track at mediations which would be totally unfit for such a role. > In more detail: > > An aggrieved contributor, the complainant, would first contact a > mediation team, privately. There would be some overlap with MIA, I > guess. Hopefully things can be resolved through mediation. In some part this already happens within the MIA team; but so often mediation just fail simply due to lack of communication by one part (i.e. we can't even mediate!) > If the mediation does not result in satisfaction, a DD complainant > would send an email to a robot, giving the names and addresses of > co-complainants. > > The robot would select a random panel of (say) 10 DD. (There would > probably have to be a ping back phase to make sure the chosen weren't > MIA.) There robot would set up two mailing lists: the panel; and the > complaints and existing maintainers together (for the maintainers, > personal addresses, from, Uploaders, for a "team" maintained package). > > The complainants would send an initial summary to both lists; the > maintainers would prepare an initial reply, to both lists. Messages > to the panel list but not the two-sides list, other than from panel > members, would be rejected. If a panel member feels that private > input is required from one side, they can ask for it and forward it > themselves. > > The panel would discuss matters for a period of two weeks. > > The complainants and maintainers would be CC'd on the initial mails. > At the end of two weeks they would vote. > > By a simple majority, the panel either reaffirms the maintainership of > the existing maintainers/uploaders, or transfers formal maintainership > to people nominated[2] by the complainants. This sounds a nicely cut idea to me, except for the randomness above. > [2] Nomination of the new maintainers should be done at this stage. > Thus a a frustrated contributor who, if the petition fails, needs > goodwill of the curent maintainer, can ask others to front the > complaint and argue the case. This helps minimise the justified > fear of retaliation. Fear of retaliation in such a place is IMHO everything but justified. Or at least it shouldn't be... -- regards,
Replace the TC power to depose maintainers
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 several occasions in the history of the project, where someone has been such a poor maintainer that they ought to have been deposed, with someone ready to take up the role. The only possible conclusion is that our process for dealing with bad leadership on the part of maintainers is totally broken. 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, afflicted by bitrot, and many users are asking for the new version; * Several times, proposed updates have been prepared by contributors but blocked by the maintainer; * There are new maintainers ready and waiting, with a new package ready for upload to sid for stretch; * Now that the TC is involved the maintainer has written many emails explaining their decisions to NAK uploads, but TC members are clearly unconvinced on a technical level that those decisions were right. Even in this extreme situation the TC has not seen fit to wrest the package away from the mainainer's deathgrip. I don't know exactly why the TC is so useless at challenging poor maintainership. I think part of it is that our TC is supposedly focused on technical issues. The TC likes to try to solve a technical problem while "keeping everyone happy". This is of no help if real underlying cause of the technical problems is not a technical disagreement, but rather poor management by the maintainer. In that case "keeping everyone happy" means keeping the most stubborn people happy. It means keeping the bad manager in charge, while those who don't want to fight simply go away, discouraged. TC members tend to reframe efforts to solve the leadership problem, as personal attacks. And of course, that is a real difficulty: since maintainership is a personal authority, it is hard to suggest that someone's authority should be weakened without criticising how it has been wielded, and implicitly criticising that person. I also think that TC members are probably biased, by selection. All TC members have extensive experience of maintainership (either within or outside Debian), and/or of core team membership. They have long experience of wielding authority, and of negotiating from a position of authority with peers. They will probably have had recent (and to them salient) experience of being challenged by useless supplicants; whereas their experiences of being blocked or rebuffed by useless maintainers will have been less common, and have less of an overall impact on their participation in Debian. This will tend to make TC members more comfortable with the existing massive power imbalance between maintainers on one hand, and other contributors on the other. And of course for very good reassons, many of the kind of people we put on the TC are very conservative: they tend not to like change, particularly change to social structures. Other difficulties include the requirement for transparency in TC deliberations; and the difficulty of dealing simultaneously with social and technical problems (and the consequent temptation of technically focused people to just fix the software, where answers are clearer, and think or hope that that is enough). 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 the TC (the structure I set up for this purpose when I wrote the constitution) is not delivering and probably never will. There are three obvious options: 1. Recognise that Debian will never depose a maintainer, no matter what. Maintainers are, within their packages, dictators (subject only to the possibility of TC overrule on individual issues, which is itself very very rare). The only way to get rid of a bad maintainer is to wear them down unti they eventually go away. 2. Provide a new process for deposing a maintainer, or appointing co-maintainers. 3. Abolish maintainership entirely. Of these 1 is what we have now. I think it is entirely unacceptable. I don't think the project is politically ready for 3. Also, it would be awkward to see how 3 would work in practice: are competing contributors expected to play core wars in the archive until the TC makes a decision in each case ? What a nightmare. That leaves 2. 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 j
How to install Debian 8.6.0 dvd 2 & 3 from iso
Sir, I want to install Debian 8.6.0 dvd 2 and 3 which is in the .iso format without burning it in dvd.I have installed dvd 1 which contain operating system.Can I install it after installing Debian operating system. Please help me. Thanks.
