On Sun, May 31, 2015 at 2:34 PM, Ross Gammon <r...@the-gammons.net> wrote:
>>> If someone suggests a new package is brought into the team, and it is >>> accepted, then the team is making a commitment at that point. >> >> How can you determine team commitment if only a single person is >> working on the package? How is this better than having the package not >> team maintained? > > I would say that if only one person has been uploading a package over a > period of years and doing a good job, there is no need for team > commitment because everything is fine. The team commitment comes if that > person needs help at some point (technically or due to lack of time). Thanks for clarifying your position, this is where I clearly disagree. IMO, if there is no need for team commitment, then there is no need for the package to be under team maintenance in the first place. In this case, it really doesn't matter if the package has a dedicated maintainer or a team with a single uploader in the field. What does matter (at least to me) is the reputation of the team: A team that groups a large amount of packages that are maintained by individuals seems less than ideal. I'd like to see pkg-multimedia as a team of people that collaborate, proactively help out, and learn from each other. IME this only works if people actually look at each others work, which in our case means subscribing to the commit mailing list and actually looking at the commits. However, pkg-multimedia has already have grown too big for that, meaning, it is impossible to follow all of the teams work. Therefore, we need to compromise. But I'd still love to think that pkg-multimedia is still a responsive and reliable team that works together! >>> When a package gets behind, it is usually because the uploader(s) is/are >>> a bit busy. The team should notice this on the QA page/dashboard and >>> ping the uploader(s) on the list to see what the problem is. >>> >>> If they are temporarily busy, maybe they would be happy with a "Team >>> Upload" by someone else? >> >> How is that different to a NMU? > > Only the changelog entry is different, and there is a series of commits > in the repo instead of a diff attached to a bug. Oh, I think I see what you are saying: Pushing commits to a git repository is easier than sending it to a bugreport? Hm, I think I can follow that line of thought somehow: Basically, the argument is that having an orphaned package that is team maintained is easier to work on than a package that has a dedicated maintainer because of the rules that the Debian Policy applies to NMUs: You have to file a bug with a patch, figure out with what delay to upload, etc. If that's the point, then this workaround feels to me like admitting defeat to the Debian NMU rules. >> I think Debian already has way too many "QA Teams". I'd rather see >> packaging teams that are responsive and don't just use the team as an >> easy way to divert responsibility. > > Agreed. But I haven't seen examples of that (diversion of > responsibility) yet myself. Oh, I think this can be seen all the time with packages that have a team in the maintainer field, but nobody feels responsible for it. > >>> Can I suggest that for new packages: >>> 1. the one intending to ITP asks if the team are happy to bring in the >>> new package >>> 2. there is an "attempt" to find someone else to also love the package? >> >> It seems to me that the current rule already implements exactly that. >> Can you elaborate how this would look like in practice, and how your >> suggestions is different? > > I think we are mixing 1 & 2 up, and they should be separate steps. That > is, if the team accepts a new package is is best if there is more than > one uploader, but not mandatory. Uh? Are you suggesting to send two emails instead of one? Please clarify, I'm having a hard time with understanding your suggestion here. >>> I would be happy to try and draft a tweak to the policy if there was >>> consensus (including some guidelines). >> >> Maybe we could first clarify why the current rule was "useless". Is it >> that too many packages violate that rule? This can be fixed with two >> means: relaxing the rule, or enforcing it. It appears to me that >> people might argue that it is not strict enough, but I'd suggest that >> we first focus on enforcing the rules. >> > > I don't think anyone thinks it is "useless". Uhm: http://lists.alioth.debian.org/pipermail/pkg-multimedia-maintainers/2015-May/044558.html > Everyone is probably happy > to abide by it if required. I only felt the need to write something > because I have observed IOhannes, Jaromir and Ruben have trouble > introducing new packages recently because no-one quickly jumped in to be > a second uploader. IOhannes stated in his recent ITP that he would push > it to collab-maint if no-one came forward. This is a little sad if it is > an obvious mutimedia application. If IOhannes is the only one working on the package, then collab-maint seems to me the better place to be honest. > I know IOhannes would take good care > of the package wherever it is. And I guess there would be someone in the > team that would help out if required. And I'm sure that having it in pkg-multimedia would not help him with his excellent work on the package unless there is some other team member willing to help out, in which case he satisfied the 2nd uploader rule: Problem solved! :-) > Someone else stated earlier in the thread that allowing the odd package > to have one uploader every now an then also allows room for new > contributors to come in and look for packages to assist with. If all > packages have a "token" second uploader, it looks to a new person like > there is nothing left. Is this really how people look for help needing packages? > I hope that helps clarify things. Thank you, I think your mail helped with clarifying where our disagreement lies. -- regards, Reinhard _______________________________________________ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
