]] Andreas Tille Hi,
first of all, sorry for taking a while to get back to you on this. > Hi, > > On Sun, Feb 05, 2017 at 12:38:59AM +0100, Tollef Fog Heen wrote: > > > Would it be a sensible compromise to reassign this bug to d-i tagging it > > > RC for buster to make sure a Blends menu will exist in the buster > > > installer. > > > > While I think it's important to get it fixed for buster, I don't think > > it's RC. If the d-i folks and/or the release team disagrees, I'm happy > > for them to decide otherwise, though. > > May be this is the right time to clarify the role of Blends inside > Debian and I'd like to adjust my probably biased opinion. Do you > consider Blends as > > A) Assemblage of low popcon packages of very specific fields > > B) Strategy to establish Debian in different workfields that > could cover a wide range of applications No, I don't think either of those are a good description of what blends are today, nor a sufficient description of what they could, and maybe should be. I think Blends are at least two things: They are a focal point for work on packages in a specific area. I imagine packages focusing on medical applications for instance will encounter some of the same challenges, and having somewhere to hold the more specialised conversations around those challenges is useful. They're also curated selections of packages. Having a blend that is «every single medical package under the sun» does not sound particularly useful if it's pulled in as a single metapackage. > As I said the outer view from users of Debian it is hard to distinguish > between a derivative and a Blend. From my experiences from DebConfs > talks (which I'm holding since 2003) are not attracting many people > which makes me consider that A is a widely spread inner view inside the > Debian developers. I don't see how this follows at all. People generally scratch their own itches. I personally have little interest in, say medical applications which means I'm not going to spend time and effort on that. It doesn't mean that I don't think people who are interested in it shouldn't work on it: I quite think they should. At the same time, making a distribution and getting a release out is about balancing goals, priorities and sometimes making those hard choices. It is to say «no, I'm sorry, this is too late» to somebody who is enthusiastic about a change. The flipside is that we get fairly regular releases out so if you miss a release, it's not the end of the world. […] > To not extend this mail to much I just want to address two points. In > the video[1] starting at minute 3 I'm presenting numbers how many Debian > developers confirmed that they are DDs only for the reason that the > Debian Med project exists. In my summary for the Debian Med sprint I > have updated numbers[2] that the trend continues and the Debian Med > project attracted 1 developer per year and several of them are doing > other things than only Debian Med work now. This means a small topic > like medicine and live science which makes a small fraction of Debian > usage and is honestly speaking in the end irrelevant for the overall > importance of Debian in general was able to gather more than 1% of > the active Debian developers. This is great, and it's a pretty common story: people come to scratch their itch and some then migrate into helping out with other parts of Debian that catch their interest, be it packages, the installer, documentation, web pages, release team, translations or something else. > I could give a lot of other examples and reasons why I think the active > support of Blends inside the Debian infrastructure could have a positive > effekt onto the acceptance of Debian inside these workfields *and* > beyond. Blends have the power to bump the maintainer-package relation > to a team-topic relation and - provided if done right (we also have > somehow orphaned Blends like Debian Junior) - can enhance the quality of > packages covering a whole topic (see for instance Debian Med advent > calendar[3] to squash bugs and many others). Orphaned blends is something we need to figure out how to handle, yes, and I think that we have them shows that teams are not a panacea. Teams require active effort to maintain too > In short: If you voted for A above please dive a bit into the topic to > consider B as an option. When voting B I think it becomes evident that > the bug is RC (at least for Buster). I still don't think it is, not even for buster. If it's RC, it means that we fix the bug or one of remove the component from the release (which I don't think anybody suggests) or that we delay the release until it's fixed. I don't think we should do either of those. Severity is not the same as priority, we can have super-important bugs which have a low severity. I think we should just fix the bug (for Buster) instead. -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are
