Re: Question to Stefano, Steve and Luk about the organisation into packaging teams.
Hi again Patrick! On Tue, Mar 24, 2009 at 10:31:04AM +0100, Patrick Schoenfeld wrote: >On Tue, Mar 24, 2009 at 01:15:00AM +, Steve McIntyre wrote: > >> Of course, there are places where our work does need co-ordination, >> like before a release. And those are the places where we often end up >> needing large teams doing a lot of work just to do that co-ordination. > >Well, coordination is the one thing. But something that is lacking in >Debian at all is serious Quality Assurance /while/ in a release cycle >(we have some basic QA during the freeze period, because the release >team needs to review every package that wants to get in, but that is.. >not much and not enough). As we are dependent on the work of volunteers >we cannot solve this problem for the whole archive, but we should try to >solve it at least for the core tools every user is dependent on, which >is something were teams or a single big team would probably be a step in >the right direction. Sure, teams for the core packages would be good. I still don't agree that a single team for all of those core packages would be good. And fall-backs are often not a good plan either. What I've often seen elsewhere is that naming fall-back options often does not work too well: either the primary team will do the work and the secondary team will not have the necessary knowledge when they do need to act, or the primary team will end up leaving the work to the secondary team too much of the time. Convincing the people maintaining core packages alone to sort out teams is the logical next step. Well, that and finding volunteers to help them in those teams. That's something that's often much harder than you might realise. As you're clearly interested in this idea, are you ready to help with it? :-) Another tack would be to get a team doing QA reviews of the core packages, much as Steve Kemp and others started with security reviews. There's a lot of work there... -- Steve McIntyre, Cambridge, UK.st...@einval.com Support the Campaign for Audiovisual Free Expression: http://www.eff.org/cafe/ -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Question to Stefano, Steve and Luk about the organisation into packaging teams.
On Tue, Mar 24, 2009 at 10:21:23AM +0100, Patrick Schoenfeld wrote:
> Sure. Its no criticism targetted at the PTS maintainers. Its not
> even criticism at all. Its just noteing that it got the attention of
> someone, but it seems it didn't get the attention of the
> project. Which would be quiet important, because those packages
> _are_ very important for our project.
Agreed; BTW, I did not interpret that as criticism at all. So, to
summarize, the PTS was *a* tentative to get the message through which,
as you observed, was not enough to reach the goal (assuming the goal
is agreed upon by the project).
> I think such a new core-team would also be a good chance, to attract
> some fresh blood. So how to proceed from here? It seems that the
> only solution is...
> .. to make the core-team the actual maintenance team and asking the
> existing maintainers to join it. In the end I don't have a problem
> if this team is somewhat bigger.
For what is worth, that's exactly the experience I had with my
participation in the maintenance of popular packages (even though not
as important as the one we are mentioning here).
1) in the beginning there was the maintainer
2) then the maintainer get overloaded and asked for help
3) then a team was formed federating together some of the people who
replied
4) then, with time, the old maintainer faded away and a new structure
(possibly with tasks and leadership) emerged in the new team
That's IME the best possible road from sole and overloaded maintainers
to sane team maintenance. As you observe in another post, the delicate
part is of course "encouraging" (2) when the sole maintainer is
overloaded but not willing to admit it.
Cheers.
--
Stefano Zacchiroli -o- PhD in Computer Science \ PostDoc @ Univ. Paris 7
z...@{upsilon.cc,pps.jussieu.fr,debian.org} -<>- http://upsilon.cc/zack/
Dietro un grande uomo c'è ..| . |. Et ne m'en veux pas si je te tutoie
sempre uno zaino ...| ..: | Je dis tu à tous ceux que j'aime
signature.asc
Description: Digital signature
Re: Question to Stefano, Steve and Luk about the organisation into packaging teams.
On Tue, Mar 24, 2009 at 10:31:34AM +0100, Raphael Hertzog wrote: >On Tue, 24 Mar 2009, Patrick Schoenfeld wrote: >> existing maintainers to join it. In the end I don't have a problem >> if this team is somewhat bigger. What I think is valueable about such a >> team is the effects that come from beeing part of a team and beeing >> responsible. > >Given the workload on many core packages, I think it's not really >reasonable to expect to have a big team responsible of many packages. >I rather like the fact that we have smaller teams each dedicated to >very few core packages. People can move from teams to teams and be part of >multiple teams if needed. > >You can't have quality if you don't have 2-3 volunteers feeling personaly >responsible for a given package. Absolutely. Beyond a certain size, a team is much more likely to fall back to "somebody else will do it". -- Steve McIntyre, Cambridge, UK.st...@einval.com Mature Sporty Personal More Innovation More Adult A Man in Dandism Powered Midship Specialty -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Question to Stefano, Steve and Luk about the organisation into packaging teams.
On Tue, 24 Mar 2009, Patrick Schoenfeld wrote: > > Turning this into a question for you: why the core-team you are > > imagining as a backup should not become the actual maintenance team > > instead of staying in the backup role? > .. to make the core-team the actual maintenance team and asking the > existing maintainers to join it. In the end I don't have a problem > if this team is somewhat bigger. What I think is valueable about such a > team is the effects that come from beeing part of a team and beeing > responsible. Given the workload on many core packages, I think it's not really reasonable to expect to have a big team responsible of many packages. I rather like the fact that we have smaller teams each dedicated to very few core packages. People can move from teams to teams and be part of multiple teams if needed. You can't have quality if you don't have 2-3 volunteers feeling personaly responsible for a given package. Cheers, -- Raphaël Hertzog Contribuez à Debian et gagnez un cahier de l'admin Debian Lenny : http://www.ouaza.com/wp/2009/03/02/contribuer-a-debian-gagner-un-livre/ -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Question to Stefano, Steve and Luk about the organisation into packaging teams.
On Tue, Mar 24, 2009 at 01:15:00AM +, Steve McIntyre wrote: > >What do you think about such a proposal? > > I'd be quite worried about the blocking potential of such a move, > actually. One of the reasons that Debian scales so well is that *most* > of the work we do day-to-day does not depend on the work of a small > core team. That means that we can continue to work independently and > get the major package work done without having to co-ordinate > everything and share decisions all the time. If we *did* end up with > such a core team, then I'd bet money on them always being over-worked. > It wouldn't start that way, but it would get there. Your people with > "enough free time" quickly wouldn't have. :-) To not repeat myself over and over again :-), did you see my mail exchange with Stefano? It explains how I think how should be dealt with it. > Of course, there are places where our work does need co-ordination, > like before a release. And those are the places where we often end up > needing large teams doing a lot of work just to do that co-ordination. Well, coordination is the one thing. But something that is lacking in Debian at all is serious Quality Assurance /while/ in a release cycle (we have some basic QA during the freeze period, because the release team needs to review every package that wants to get in, but that is.. not much and not enough). As we are dependent on the work of volunteers we cannot solve this problem for the whole archive, but we should try to solve it at least for the core tools every user is dependent on, which is something were teams or a single big team would probably be a step in the right direction. > I'm much more convinced about encouraging people to set up individual > teams for core packages, and then finding enough people to help cover > the needs of those packages. More keen NMs are always good here... Well the difference is only the number of persons. Which doesn't need to be a difference at all. But I'm open to that as well, I just think we should make it the default that those package are team-maintained and we should have a fallback where those teams aren't setup on their own by their individual maintainers. Regards, Patrick signature.asc Description: Digital signature
Re: Question to Stefano, Steve and Luk about the organisation into packaging teams.
On Tue, Mar 24, 2009 at 09:46:31AM +0100, Stefano Zacchiroli wrote: > On Mon, Mar 23, 2009 at 08:58:34PM +0100, Patrick Schoenfeld wrote: > > Stefano, actually I agree with its good intention. What I actually > > think is that we are kidding ourselves, because we already see whats > > needed, but don't go an active way of solving something which might > > be an issue. Instead we are acting only passive, with this note, > > with the best hope that someone will come and fix the problem. > > It is true that this way of approaching the issue is passive, but you > should consider from whom that "warning" was coming from: the PTS > maintainers. Their role is maintaining the PTS and they output > warnings in good faith trying to do something useful. In this precise > setting they appeal to no authority or consensus stating that > "important" packages should be team maintained, what else can they do? > (using "they" because this precise suggestion predates my PTS > involvement) Sure. Its no criticism targetted at the PTS maintainers. Its not even criticism at all. Its just noteing that it got the attention of someone, but it seems it didn't get the attention of the project. Which would be quiet important, because those packages _are_ very important for our project. > So the "we" that already see the problem is not, potentially, as broad > as you see it. I surely consider myself as a part of that we, though. ACK. > > No, actually its ok if we have more then one team. Some of these > > packages are already team-maintained and possibly good. What I aimed > > at was a team that backups existing teams and pitches in where > > team-power is missing. A team that is always responsible for > > packages, which are otherwise only in the responsibility of single > > maintainers. Such a team would always be empowered to make uploads > > for these packages, without needing to escalate single issues to the > > CTTE or comply with waiting periods for NMUs. > > Just to be clear on some details. I would be fine with both a single > team or multiple teams. However, I don't think it will be a good idea > to have official maintainers (teams or individual) and them something > else behind the scene stepping in only when something goes wrong or > when on a hurry uploads are needed. Teams work due to the > identification between declared maintainers (teams or individuals) and > the people actually doing the work. So, if there are people doing the > work they ought to be the maintainers/uploaders and vice-versa. Good point. There are two problems I see: If we have a single core team, which is responsible for about 100 packages all alone, I guess we will quickly see those people beeing overloaded. Second, the existing maintainers surely do some valueable work and it would be a shame to take the work they do away from them. I think such a new core-team would also be a good chance, to attract some fresh blood. So how to proceed from here? It seems that the only solution is... > Turning this into a question for you: why the core-team you are > imagining as a backup should not become the actual maintenance team > instead of staying in the backup role? .. to make the core-team the actual maintenance team and asking the existing maintainers to join it. In the end I don't have a problem if this team is somewhat bigger. What I think is valueable about such a team is the effects that come from beeing part of a team and beeing responsible. > If the problem is not setting > aside the current maintainer, such maintainer should at least in the > beginning / interim be part of the new, forthcoming maintenance > team. I witnessed several maintenance transitions like the one I'm > imagining here, and it is IMO the best possible course of actions. Right. Cheers, Patrick -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Question to Stefano, Steve and Luk about the organisation into packaging teams.
On Mon, Mar 23, 2009 at 08:58:34PM +0100, Patrick Schoenfeld wrote:
> Stefano, actually I agree with its good intention. What I actually
> think is that we are kidding ourselves, because we already see whats
> needed, but don't go an active way of solving something which might
> be an issue. Instead we are acting only passive, with this note,
> with the best hope that someone will come and fix the problem.
It is true that this way of approaching the issue is passive, but you
should consider from whom that "warning" was coming from: the PTS
maintainers. Their role is maintaining the PTS and they output
warnings in good faith trying to do something useful. In this precise
setting they appeal to no authority or consensus stating that
"important" packages should be team maintained, what else can they do?
(using "they" because this precise suggestion predates my PTS
involvement)
So the "we" that already see the problem is not, potentially, as broad
as you see it. I surely consider myself as a part of that we, though.
> No, actually its ok if we have more then one team. Some of these
> packages are already team-maintained and possibly good. What I aimed
> at was a team that backups existing teams and pitches in where
> team-power is missing. A team that is always responsible for
> packages, which are otherwise only in the responsibility of single
> maintainers. Such a team would always be empowered to make uploads
> for these packages, without needing to escalate single issues to the
> CTTE or comply with waiting periods for NMUs.
Just to be clear on some details. I would be fine with both a single
team or multiple teams. However, I don't think it will be a good idea
to have official maintainers (teams or individual) and them something
else behind the scene stepping in only when something goes wrong or
when on a hurry uploads are needed. Teams work due to the
identification between declared maintainers (teams or individuals) and
the people actually doing the work. So, if there are people doing the
work they ought to be the maintainers/uploaders and vice-versa.
Turning this into a question for you: why the core-team you are
imagining as a backup should not become the actual maintenance team
instead of staying in the backup role? If the problem is not setting
aside the current maintainer, such maintainer should at least in the
beginning / interim be part of the new, forthcoming maintenance
team. I witnessed several maintenance transitions like the one I'm
imagining here, and it is IMO the best possible course of actions.
Cheers.
--
Stefano Zacchiroli -o- PhD in Computer Science \ PostDoc @ Univ. Paris 7
z...@{upsilon.cc,pps.jussieu.fr,debian.org} -<>- http://upsilon.cc/zack/
Dietro un grande uomo c'è ..| . |. Et ne m'en veux pas si je te tutoie
sempre uno zaino ...| ..: | Je dis tu à tous ceux que j'aime
signature.asc
Description: Digital signature
Re: Question to Stefano, Steve and Luk about the organisation into packaging teams.
Hi Patrick, On Sat, Mar 21, 2009 at 01:43:16PM +0100, Patrick Schoenfeld wrote: > >In Debian we have some packages that are either by default on every >system or are commonly expected to be found on Debian systems. Such >tools could be called the core of our system, because they are most >commonly used on a Debian system. Such packages include coreutils, gzip, >grep, hostname, initscripts, obviously all the tools that make up a >Debian system like dpkg, at, cron and some more. Short said: More or >less all packages with a priority of Standard or higher, although one >would need to think about this scope wrt to the following proposal. > >Some of these packages are very well maintained and others.. well, >bug numbers sometimes speak for themselves. For these packages we have >that cool text on the PTS pages: "The package is of priority standard >or higher, you should really find some co-maintainers." which brought >me on this at all. What I thought about when I read that is: "HaHaHa, >we are kidding on us own, because we recommend something to us, what >should actually be the default (for this type of packages). >Thats why I thought it would eventually be a good idea to form a core >team, meaning a team of a bunch of people (10-20?), with wide-spread >knowledge and known to have enough free time (e.g. people who have > 50 >packages and aren't able to keep up with the bug reports in their own >packages wouldn't qualify) that gets the job to (co-)maintain all these >packages that are very important to us. It doesn't mean that the >existing maintainers are taken away the packages, because they could >still stay the maintainers, but obviously some of these packages are not >easily maintainable by one person. > >What do you think about such a proposal? I'd be quite worried about the blocking potential of such a move, actually. One of the reasons that Debian scales so well is that *most* of the work we do day-to-day does not depend on the work of a small core team. That means that we can continue to work independently and get the major package work done without having to co-ordinate everything and share decisions all the time. If we *did* end up with such a core team, then I'd bet money on them always being over-worked. It wouldn't start that way, but it would get there. Your people with "enough free time" quickly wouldn't have. :-) Of course, there are places where our work does need co-ordination, like before a release. And those are the places where we often end up needing large teams doing a lot of work just to do that co-ordination. I'm much more convinced about encouraging people to set up individual teams for core packages, and then finding enough people to help cover the needs of those packages. More keen NMs are always good here... -- Steve McIntyre, Cambridge, UK.st...@einval.com "I can't ever sleep on planes ... call it irrational if you like, but I'm afraid I'll miss my stop" -- Vivek Dasmohapatra -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Question to Stefano, Steve and Luk about the organisation into packaging teams.
On Mon, Mar 23, 2009 at 05:48:08PM +0100, Stefano Zacchiroli wrote: > [ ACK on the comment that proposals like this one deserve a wider > audience than -vote and the candidates. Given you are asking, here > is my answer, which does not inhibit re-raising the issue elsewhere > of course (hint hint :-)) ] As already stated elsewhere I'm surely opening that topic somewhere with a broader audience, but its a good topic for me to see which opinions the DPL candidates act for. > On Sat, Mar 21, 2009 at 01:43:16PM +0100, Patrick Schoenfeld wrote: > > Some of these packages are very well maintained and others.. well, > > bug numbers sometimes speak for themselves. For these packages we have > > that cool text on the PTS pages: "The package is of priority standard > > or higher, you should really find some co-maintainers." which brought > > me on this at all. What I thought about when I read that is: "HaHaHa, > > we are kidding on us own, because we recommend something to us, what > > should actually be the default (for this type of packages). > > I don't get what you mean here: it should be the default in which > sense? in the ideal world? agreed. Beside that, it is not written > anywhere that it should be the case. The warning is there because (as > I've mentioned elsewhere in this thread) the PTS has been used in the > past to push for QA practices which were considered good by the PTS > maintainers. That warning was implemented (IIRC, I haven't checked the > svn logs) by Raphael and has stayed there because the other people who > maintainer the PTS agrees with its good intention. Stefano, actually I agree with its good intention. What I actually think is that we are kidding ourselves, because we already see whats needed, but don't go an active way of solving something which might be an issue. Instead we are acting only passive, with this note, with the best hope that someone will come and fix the problem. > > What do you think about such a proposal? > > It would make perfectly sense, but I fail to see its specificity. I > think that such important packages should be team maintained, even > only for backup reasons [1]. Is it that relevant for your proposal > that the team is a single one as opposed to multiple one? In practice, > I imagine that the overlap between maintenance team will grow over > time, so you can also see it as a gradual path towards your proposal. No, actually its ok if we have more then one team. Some of these packages are already team-maintained and possibly good. What I aimed at was a team that backups existing teams and pitches in where team-power is missing. A team that is always responsible for packages, which are otherwise only in the responsibility of single maintainers. Such a team would always be empowered to make uploads for these packages, without needing to escalate single issues to the CTTE or comply with waiting periods for NMUs. > Finally, let me observe that nothing in our current rules inhibit that > from happening: it would be enough to get the current maintainer > around an (IRC-)table, and decide to start over by asking for people > interested to join the forthcoming teams. Yes, asking the maintainer weither its okay, if a core-team can assist him with his duties, would be the normal way that should always be followed (even with my proposal). But it goes somewhat farer in that it it would make the members of that core team delagates with a given package set as their responsibility. It still needs volunteers to act in this team, but I think that a team which one can be part of makes volunteer positions actually more interesting as doing work, reporting it in the BTS and hoping some overloaded person will ever look into and considering it. Regards, Patrick signature.asc Description: Digital signature
Re: Question to Stefano, Steve and Luk about the organisation into packaging teams.
[ ACK on the comment that proposals like this one deserve a wider
audience than -vote and the candidates. Given you are asking, here
is my answer, which does not inhibit re-raising the issue elsewhere
of course (hint hint :-)) ]
On Sat, Mar 21, 2009 at 01:43:16PM +0100, Patrick Schoenfeld wrote:
> Some of these packages are very well maintained and others.. well,
> bug numbers sometimes speak for themselves. For these packages we have
> that cool text on the PTS pages: "The package is of priority standard
> or higher, you should really find some co-maintainers." which brought
> me on this at all. What I thought about when I read that is: "HaHaHa,
> we are kidding on us own, because we recommend something to us, what
> should actually be the default (for this type of packages).
I don't get what you mean here: it should be the default in which
sense? in the ideal world? agreed. Beside that, it is not written
anywhere that it should be the case. The warning is there because (as
I've mentioned elsewhere in this thread) the PTS has been used in the
past to push for QA practices which were considered good by the PTS
maintainers. That warning was implemented (IIRC, I haven't checked the
svn logs) by Raphael and has stayed there because the other people who
maintainer the PTS agrees with its good intention.
> Thats why I thought it would eventually be a good idea to form a
> core team, meaning a team of a bunch of people (10-20?), with
> wide-spread knowledge and known to have enough free time
> (e.g. people who have > 50 packages and aren't able to keep up with
> the bug reports in their own packages wouldn't qualify) that gets
> the job to (co-)maintain all these packages that are very important
> to us. It doesn't mean that the existing maintainers are taken away
> the packages, because they could still stay the maintainers, but
> obviously some of these packages are not easily maintainable by one
> person.
>
> What do you think about such a proposal?
It would make perfectly sense, but I fail to see its specificity. I
think that such important packages should be team maintained, even
only for backup reasons [1]. Is it that relevant for your proposal
that the team is a single one as opposed to multiple one? In practice,
I imagine that the overlap between maintenance team will grow over
time, so you can also see it as a gradual path towards your proposal.
Finally, let me observe that nothing in our current rules inhibit that
from happening: it would be enough to get the current maintainer
around an (IRC-)table, and decide to start over by asking for people
interested to join the forthcoming teams.
Cheers.
[1] but in practice for other good reasons, like team reviewing of
patches which are considered sensitive, like it happens on the
devscripts maintenance team for example
--
Stefano Zacchiroli -o- PhD in Computer Science \ PostDoc @ Univ. Paris 7
z...@{upsilon.cc,pps.jussieu.fr,debian.org} -<>- http://upsilon.cc/zack/
Dietro un grande uomo c'è ..| . |. Et ne m'en veux pas si je te tutoie
sempre uno zaino ...| ..: | Je dis tu à tous ceux que j'aime
signature.asc
Description: Digital signature
Re: Question to Stefano, Steve and Luk about the organisation into packaging teams.
On Sat, Mar 21, 2009 at 01:42:11AM +, Steve McIntyre wrote:
> I'm very much a fan of people working together on their packages, but
> I wouldn't necessarily go so far as to make teams the default. If
> P.S. Damn, just read Zack's answer and we don't seem to differ very
> much. Oh well... :-)
... well, expect that you don't consider team maintenance to be the
reasonable default while I do :-)
Cheers.
--
Stefano Zacchiroli -o- PhD in Computer Science \ PostDoc @ Univ. Paris 7
z...@{upsilon.cc,pps.jussieu.fr,debian.org} -<>- http://upsilon.cc/zack/
Dietro un grande uomo c'è ..| . |. Et ne m'en veux pas si je te tutoie
sempre uno zaino ...| ..: | Je dis tu à tous ceux que j'aime
signature.asc
Description: Digital signature
Re: Question to Stefano, Steve and Luk about the organisation into packaging teams.
On Fri, Mar 20, 2009 at 01:00:39PM +0100, Luk Claes wrote:
> >> people. My proposal would be to add a "join a team" entry as one of
> >> the *recommended* step in our join checklists.
>
> I agree that this is a good idea.
Cool.
> > Let me add a second way to implement that default; I've split it
> > in a different mail because it touches a different subject:
> > handling of sub-standard quality packages. We need ways to
> > identify them and to, initially gently and then more forcibly if
> > needed, encourage maintainers to pass over maintenance. How to do
> > that is a different topic, let's assume we have a way to identify
> > such packages.
>
> I think it's important to foremost work together with the maintainer
> on this. The goal should be that the maintainer is more proactive in
> the future and we would not get sub-standard quality packages for
> them that easily anymore.
Yes, but at this abstraction level it is so vague that we cannot
really learn anything from it. How do you plan to ensure that that
will be the case? Neglected packages are in most case a signal of the
maintainer attention having moved elsewhere.
The most likely outcome is to pass over maintenance to somebody else,
which usually happens when the maintainer is still responsive enough
to publicly look for help by creating a maintenance team. Then, IME,
what will inevitably happen is that the new maintenance team will
completely take over the package. When this happens we have no problem
to fix ...
> I don't think it's a good idea to take over packages from existing
> maintainers unless that maintainer agrees with it or is not active
> anymore. Proposing the maintainer to join existing teams maintaining
> similar packages is a good idea though.
... the problem we have to fix is when the maintainer is not reactive
enough to look for help.
There, the QA team stepping in and suggesting to ask for help
(publicly, so that we have it traced) and suggesting the formation of
a maintenance team can be an interesting evolution.
> > Finally, I believe our most important packages (e.g., as defined by
> > their archive Priority or shared libraries with tons of reverse
> > dependencies) should be team-maintained, at least to provide backup
> > maintainers. In fact, the PTS already implements such a warning on a
> > Priority basis (implementation by Raphael, a while ago); similar
> > warnings can and should be added to other tools of our toolchains.
>
> Not a bad idea, though it's only a 'should' and should not be
> interpreted as a 'must' IMHO.
Agreed.
Cheers.
--
Stefano Zacchiroli -o- PhD in Computer Science \ PostDoc @ Univ. Paris 7
z...@{upsilon.cc,pps.jussieu.fr,debian.org} -<>- http://upsilon.cc/zack/
Dietro un grande uomo c'è ..| . |. Et ne m'en veux pas si je te tutoie
sempre uno zaino ...| ..: | Je dis tu à tous ceux que j'aime
signature.asc
Description: Digital signature
Re: Question to Stefano, Steve and Luk about the organisation into packaging teams.
On Sun, Mar 22, 2009 at 08:42:59PM -0700, Steve Langasek wrote: > > Well, some time back I wrote some patches for coreutils. Unfortunately > > they are not yet integrated, but thats not the fault of the maintainer. > > However I think it could help if the project decides that this is a good > > idea > > and (if needed) can overrrule single maintainers. > > There are existing procedures for overruling individual maintainers - i.e., > appealing to the Technical Committee. If you think an override is needed, > you might try the existing process before deciding that we need an entirely > new one? Good point. Nothing to add. Best Regards, Patrick -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Question to Stefano, Steve and Luk about the organisation into packaging teams.
On Sun, Mar 22, 2009 at 11:28:56AM +0100, Patrick Schoenfeld wrote: > > > Well, because it is in line with the questions which they have been > > > asked and its both a good chance to see weither they stand on a similar > > > point > > > as I do and to see weither anyone is interested in the idea > > > at all. Surely I intend to propose it to the larger body once its more > > > then > > > a rough idea. > > I expressly refrained to answer your mail because it targetted the DPL > > candidate but IMO it's one those "false good ideas until you make it a > > reality". I'm all for a team of many people improving the base packages, > > so find those people and start triaging and writing patches _together_ > > with the actual maintainers. > Well, some time back I wrote some patches for coreutils. Unfortunately > they are not yet integrated, but thats not the fault of the maintainer. > However I think it could help if the project decides that this is a good idea > and (if needed) can overrrule single maintainers. There are existing procedures for overruling individual maintainers - i.e., appealing to the Technical Committee. If you think an override is needed, you might try the existing process before deciding that we need an entirely new one? -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Question to Stefano, Steve and Luk about the organisation into packaging teams.
On Sun, 22 Mar 2009, Patrick Schoenfeld wrote: > > I expressly refrained to answer your mail because it targetted the DPL > > candidate but IMO it's one those "false good ideas until you make it a > > reality". I'm all for a team of many people improving the base packages, > > so find those people and start triaging and writing patches _together_ > > with the actual maintainers. > > Well, some time back I wrote some patches for coreutils. Unfortunately > they are not yet integrated, but thats not the fault of the maintainer. I don't know what leads you to say this but yes, real bugs that are not Debian-specific are best fixed upstream or in coordination with upstream. > However I think it could help if the project decides that this is a good idea > and (if needed) can overrrule single maintainers. Because you surely know > that there are people who simply don't accept the fact, that they are > overloaded with the work they beared on themselves. We can certainly do something if we have good maintainers that are willing to do the job if the actual maintainer is actively blocking work, but in most of the cases I have not seen active opposition. > > But don't explain your plan by saying "maintainers of core packages suck" > > (even if they sometimes do) but rather with "we want our core packages to > > be in the best possible shape and we will help the maintainers to achieve > > this goal". > > Thats not what I did. Telling that our core tools have a large number of > bugs that are partially ignored, however, is something one could say, while > not saying that the maintainers of the packages suck. I did not say that you did it, but I warned you to not fall in the trap. That's all. > Which one? One that were started shortly before the Lenny release? > Atleast I replied in a similar thread and said that it would be a good idea. I replied to your -private mail and moved it to -project. http://lists.debian.org/debian-project/2009/03/msg00081.html It's precisely because such a metric is useless that I replied. :) I tried to point you in other ways to responsabilize maintainers that have trouble recognizing that they are overloaded. Cheers, -- Raphaël Hertzog Contribuez à Debian et gagnez un cahier de l'admin Debian Lenny : http://www.ouaza.com/wp/2009/03/02/contribuer-a-debian-gagner-un-livre/ -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Question to Stefano, Steve and Luk about the organisation into packaging teams.
On Sun, Mar 22, 2009 at 10:25:11AM +0100, Raphael Hertzog wrote: > On Sat, 21 Mar 2009, Patrick Schoenfeld wrote: > > On Sat, Mar 21, 2009 at 01:11:58PM -0700, Steve Langasek wrote: > > > On Sat, Mar 21, 2009 at 01:43:16PM +0100, Patrick Schoenfeld wrote: > > > > What do you think about such a proposal? > > > > > > Why are you asking the DPL candidates what they think of this proposal, > > > instead of proposing it to the developers? > > > > Well, because it is in line with the questions which they have been > > asked and its both a good chance to see weither they stand on a similar > > point > > as I do and to see weither anyone is interested in the idea > > at all. Surely I intend to propose it to the larger body once its more then > > a rough idea. > > I expressly refrained to answer your mail because it targetted the DPL > candidate but IMO it's one those "false good ideas until you make it a > reality". I'm all for a team of many people improving the base packages, > so find those people and start triaging and writing patches _together_ > with the actual maintainers. Well, some time back I wrote some patches for coreutils. Unfortunately they are not yet integrated, but thats not the fault of the maintainer. However I think it could help if the project decides that this is a good idea and (if needed) can overrrule single maintainers. Because you surely know that there are people who simply don't accept the fact, that they are overloaded with the work they beared on themselves. > But don't explain your plan by saying "maintainers of core packages suck" > (even if they sometimes do) but rather with "we want our core packages to > be in the best possible shape and we will help the maintainers to achieve > this goal". Thats not what I did. Telling that our core tools have a large number of bugs that are partially ignored, however, is something one could say, while not saying that the maintainers of the packages suck. > PS: You didn't reply to -project about the metric of bugs (25 normal bugs > == 1 RC bug). I hoped we could turn this discussion on something positive > to improve the fate of core packages. Which one? One that were started shortly before the Lenny release? Atleast I replied in a similar thread and said that it would be a good idea. Regards, Patrick signature.asc Description: Digital signature
Re: Question to Stefano, Steve and Luk about the organisation into packaging teams.
On Sat, 21 Mar 2009, Patrick Schoenfeld wrote: > On Sat, Mar 21, 2009 at 01:11:58PM -0700, Steve Langasek wrote: > > On Sat, Mar 21, 2009 at 01:43:16PM +0100, Patrick Schoenfeld wrote: > > > What do you think about such a proposal? > > > > Why are you asking the DPL candidates what they think of this proposal, > > instead of proposing it to the developers? > > Well, because it is in line with the questions which they have been > asked and its both a good chance to see weither they stand on a similar point > as I do and to see weither anyone is interested in the idea > at all. Surely I intend to propose it to the larger body once its more then > a rough idea. I expressly refrained to answer your mail because it targetted the DPL candidate but IMO it's one those "false good ideas until you make it a reality". I'm all for a team of many people improving the base packages, so find those people and start triaging and writing patches _together_ with the actual maintainers. But don't explain your plan by saying "maintainers of core packages suck" (even if they sometimes do) but rather with "we want our core packages to be in the best possible shape and we will help the maintainers to achieve this goal". Cheers, PS: You didn't reply to -project about the metric of bugs (25 normal bugs == 1 RC bug). I hoped we could turn this discussion on something positive to improve the fate of core packages. -- Raphaël Hertzog Contribuez à Debian et gagnez un cahier de l'admin Debian Lenny : http://www.ouaza.com/wp/2009/03/02/contribuer-a-debian-gagner-un-livre/ -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Question to Stefano, Steve and Luk about the organisation into packaging teams.
On Sat, Mar 21, 2009 at 01:11:58PM -0700, Steve Langasek wrote: > On Sat, Mar 21, 2009 at 01:43:16PM +0100, Patrick Schoenfeld wrote: > > What do you think about such a proposal? > > Why are you asking the DPL candidates what they think of this proposal, > instead of proposing it to the developers? Well, because it is in line with the questions which they have been asked and its both a good chance to see weither they stand on a similar point as I do and to see weither anyone is interested in the idea at all. Surely I intend to propose it to the larger body once its more then a rough idea. Regards, Patrick signature.asc Description: Digital signature
Re: Question to Stefano, Steve and Luk about the organisation into packaging teams.
On Sat, Mar 21, 2009 at 01:43:16PM +0100, Patrick Schoenfeld wrote: > Some of these packages are very well maintained and others.. well, > bug numbers sometimes speak for themselves. For these packages we have > that cool text on the PTS pages: "The package is of priority standard > or higher, you should really find some co-maintainers." which brought > me on this at all. What I thought about when I read that is: "HaHaHa, > we are kidding on us own, because we recommend something to us, what > should actually be the default (for this type of packages). > Thats why I thought it would eventually be a good idea to form a core > team, meaning a team of a bunch of people (10-20?), with wide-spread > knowledge and known to have enough free time (e.g. people who have > 50 > packages and aren't able to keep up with the bug reports in their own > packages wouldn't qualify) that gets the job to (co-)maintain all these > packages that are very important to us. It doesn't mean that the > existing maintainers are taken away the packages, because they could > still stay the maintainers, but obviously some of these packages are not > easily maintainable by one person. > What do you think about such a proposal? Why are you asking the DPL candidates what they think of this proposal, instead of proposing it to the developers? -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Question to Stefano, Steve and Luk about the organisation into packaging teams.
Hi, On Sat, Mar 21, 2009 at 01:42:11AM +, Steve McIntyre wrote: > On Wed, Mar 18, 2009 at 01:19:27PM +0900, Charles Plessy wrote: > >Dear Stefano, Steve and Luk, > > Hi again Charles! > > >I like a lot Stefano's statement about collaborative maintainance: > >"Collaborative maintenance should not be mandatory (we do have several very > >efficient one-man-band developers), but should be our default". > > > >First of all, I would be interested to know if it is a point of divergence > >between the candidates. Then, if there is interest for such a discussion, I > >would like to encourage you to develop your ideas on this subject, especially > >on what you can do as a DPL or DPL assistant. > > I'm very much a fan of people working together on their packages, but > I wouldn't necessarily go so far as to make teams the default. If I think for the vast majority of packages in our archive this would simply be overkill. But I'm interested what you think about the following: In Debian we have some packages that are either by default on every system or are commonly expected to be found on Debian systems. Such tools could be called the core of our system, because they are most commonly used on a Debian system. Such packages include coreutils, gzip, grep, hostname, initscripts, obviously all the tools that make up a Debian system like dpkg, at, cron and some more. Short said: More or less all packages with a priority of Standard or higher, although one would need to think about this scope wrt to the following proposal. Some of these packages are very well maintained and others.. well, bug numbers sometimes speak for themselves. For these packages we have that cool text on the PTS pages: "The package is of priority standard or higher, you should really find some co-maintainers." which brought me on this at all. What I thought about when I read that is: "HaHaHa, we are kidding on us own, because we recommend something to us, what should actually be the default (for this type of packages). Thats why I thought it would eventually be a good idea to form a core team, meaning a team of a bunch of people (10-20?), with wide-spread knowledge and known to have enough free time (e.g. people who have > 50 packages and aren't able to keep up with the bug reports in their own packages wouldn't qualify) that gets the job to (co-)maintain all these packages that are very important to us. It doesn't mean that the existing maintainers are taken away the packages, because they could still stay the maintainers, but obviously some of these packages are not easily maintainable by one person. What do you think about such a proposal? Best Regards, Patrick signature.asc Description: Digital signature
Re: Question to Stefano, Steve and Luk about the organisation into packaging teams.
On Wed, Mar 18, 2009 at 01:19:27PM +0900, Charles Plessy wrote: >Dear Stefano, Steve and Luk, Hi again Charles! >I like a lot Stefano's statement about collaborative maintainance: >"Collaborative maintenance should not be mandatory (we do have several very >efficient one-man-band developers), but should be our default". > >First of all, I would be interested to know if it is a point of divergence >between the candidates. Then, if there is interest for such a discussion, I >would like to encourage you to develop your ideas on this subject, especially >on what you can do as a DPL or DPL assistant. I'm very much a fan of people working together on their packages, but I wouldn't necessarily go so far as to make teams the default. If people are happy and able to work effectively on their packages without help, then that's up to them. Of course, for bigger packages and groups of packages then team maintenance is clearly a good plan. The perl team are a great example of how teams can work together, and I'd encourage other people to follow their lead here. I've long been an advocate of NMs (and now DMs) joining Debian and learning / developing their skills by working with existing teams rather than just going and packaging something new because they feel they need to. That just leaves us with lots of packages in the archive that people don't really care about. You can see that I've mentioned this in my election platform in previous years. If we can encourage new people to join teams in this way, we get a better view of the new people too. P.S. Damn, just read Zack's answer and we don't seem to differ very much. Oh well... :-) -- Steve McIntyre, Cambridge, UK.st...@einval.com "It's actually quite entertaining to watch ag129 prop his foot up on the desk so he can get a better aim." [ seen in ucam.chat ] -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Question to Stefano, Steve and Luk about the organisation into packaging teams.
Stefano Zacchiroli wrote: > On Thu, Mar 19, 2009 at 05:39:38PM +0100, Stefano Zacchiroli wrote: >>> "Collaborative maintenance should not be mandatory (we do have >>> several very efficient one-man-band developers), but should be our >>> default". > >> What I would do if the times will come, is to get in touch with NM >> people. My proposal would be to add a "join a team" entry as one of >> the *recommended* step in our join checklists. I agree that this is a good idea. Some documentation is very focused on packaging new software, where existing teams are already having a hard time to keep up maintaining important packages. I think both for the existing maintainers as well as for the NM it's very probably more rewarding to work together on existing packages. > Let me add a second way to implement that default; I've split it in a > different mail because it touches a different subject: handling of > sub-standard quality packages. We need ways to identify them and to, > initially gently and then more forcibly if needed, encourage > maintainers to pass over maintenance. How to do that is a different > topic, let's assume we have a way to identify such packages. I think it's important to foremost work together with the maintainer on this. The goal should be that the maintainer is more proactive in the future and we would not get sub-standard quality packages for them that easily anymore. > In such scenario, the first choice should be to look whether we > already have a team maintaining related packages and get actively in > touch with them to check whether there are people in the team willing > to take over maintenance. The second choice should be an attempt to > create a team for the maintenance of the package, possibly federating > together related packages. FWIW, that's how I got involved in several > of the teams I'm a member of: responding to cries for help together > with other. If all this fails, we should then put the package up for > adoption as we currently do. I don't think it's a good idea to take over packages from existing maintainers unless that maintainer agrees with it or is not active anymore. Proposing the maintainer to join existing teams maintaining similar packages is a good idea though. > Finally, I believe our most important packages (e.g., as defined by > their archive Priority or shared libraries with tons of reverse > dependencies) should be team-maintained, at least to provide backup > maintainers. In fact, the PTS already implements such a warning on a > Priority basis (implementation by Raphael, a while ago); similar > warnings can and should be added to other tools of our toolchains. Not a bad idea, though it's only a 'should' and should not be interpreted as a 'must' IMHO. Cheers Luk -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Question to Stefano, Steve and Luk about the organisation into packaging teams.
On Thu, Mar 19, 2009 at 05:39:38PM +0100, Stefano Zacchiroli wrote:
> > "Collaborative maintenance should not be mandatory (we do have
> > several very efficient one-man-band developers), but should be our
> > default".
> What I would do if the times will come, is to get in touch with NM
> people. My proposal would be to add a "join a team" entry as one of
> the *recommended* step in our join checklists.
Let me add a second way to implement that default; I've split it in a
different mail because it touches a different subject: handling of
sub-standard quality packages. We need ways to identify them and to,
initially gently and then more forcibly if needed, encourage
maintainers to pass over maintenance. How to do that is a different
topic, let's assume we have a way to identify such packages.
In such scenario, the first choice should be to look whether we
already have a team maintaining related packages and get actively in
touch with them to check whether there are people in the team willing
to take over maintenance. The second choice should be an attempt to
create a team for the maintenance of the package, possibly federating
together related packages. FWIW, that's how I got involved in several
of the teams I'm a member of: responding to cries for help together
with other. If all this fails, we should then put the package up for
adoption as we currently do.
Finally, I believe our most important packages (e.g., as defined by
their archive Priority or shared libraries with tons of reverse
dependencies) should be team-maintained, at least to provide backup
maintainers. In fact, the PTS already implements such a warning on a
Priority basis (implementation by Raphael, a while ago); similar
warnings can and should be added to other tools of our toolchains.
Cheers.
--
Stefano Zacchiroli -o- PhD in Computer Science \ PostDoc @ Univ. Paris 7
z...@{upsilon.cc,pps.jussieu.fr,debian.org} -<>- http://upsilon.cc/zack/
Dietro un grande uomo c'è ..| . |. Et ne m'en veux pas si je te tutoie
sempre uno zaino ...| ..: | Je dis tu à tous ceux que j'aime
signature.asc
Description: Digital signature
Re: Question to Stefano, Steve and Luk about the organisation into packaging teams.
On Wed, Mar 18, 2009 at 01:19:27PM +0900, Charles Plessy wrote:
> I like a lot Stefano's statement about collaborative maintainance:
> "Collaborative maintenance should not be mandatory (we do have
> several very efficient one-man-band developers), but should be our
> default".
>
> First of all, I would be interested to know if it is a point of
> divergence between the candidates. Then, if there is interest for
> such a discussion, I would like to encourage you to develop your
> ideas on this subject, especially on what you can do as a DPL or DPL
> assistant.
Of course I'm not diverging with myself :-)
What I would do if the times will come, is to get in touch with NM
people. My proposal would be to add a "join a team" entry as one of
the *recommended* step in our join checklists.
That would be a first way of making the default I've mentioned in my
platform becoming reality. Applicants would not be required to do so,
but most of them will consider the option. The benefits would be
several:
- more sound recommendations when the time comes for DDs to support
DM/DD applications
- more (implicit, de facto) testing of the "social skills" of
applicants, as opposed as technical skills *only*
- give a reason to teams to declare and organize themselves
in structures like wiki.d.o/Teams.
In the end, that page can become an entry point where applicants
look for ways to help that matches their interests. IMO it would be
way better than pointing to the absolutely chaotic WNPP pages, they
just scare newbies away.
I hope that all this explain a bit more my position on the topic.
If not, feel free to ask more detailed questions.
Cheers.
--
Stefano Zacchiroli -o- PhD in Computer Science \ PostDoc @ Univ. Paris 7
z...@{upsilon.cc,pps.jussieu.fr,debian.org} -<>- http://upsilon.cc/zack/
Dietro un grande uomo c'è ..| . |. Et ne m'en veux pas si je te tutoie
sempre uno zaino ...| ..: | Je dis tu à tous ceux que j'aime
signature.asc
Description: Digital signature
