Re: All candidates: Development and technical issues and challenges
On 18/03/13 at 19:41 -0400, anarcat wrote:
> On 2013-03-11, Moray Allan wrote:
> > When to release: I would also note that we should continue to be
> > flexible about "-ignore" tags where appropriate. In some cases
> > leaving a package in the release with RC bugs is more useful to users
> > than removing it altogether. Indeed, we always release with quite a
> > large number of non-RC bugs, some of which make the packages in
> > question unusable for large groups of users. At any point in the
> > freeze we should ask not only about the state of the frozen release,
> > but how it compares to the previous release. Maybe it doesn't even
> > need to be a single date -- we could badge the new release as ready
> > for the desktop before we close it off as final and suggest that
> > people upgrade their servers.
>
> I think this is a great point, and I would like to push it a little
> further.
>
> "When to release" seems really important. As things stand right now, we
> have about 70 packages (assuming one package per RC bug) blocking the
> release of 38000 packages[1]. That is 0.2% of the archive. It's really
> small. About 0.1% if we look at the ones that don't have a fix yet (49).
>
> Shouldn't we be releasing 'as is' at some point and just accept that
> some bugs will be fixed in a stable release later?
That's what we do. We use 'wheezy-ignore' for some bugs.
But I think that it would be inappropriate to comment further on the
release team's work. I think they are doing a great job.
> Shouldn't we "release early, release often"?
I think that the length of current Debian release cycles are a good
compromise. I'd rather have us explore doing a rolling release in
addition to our stable releases.
> I agree that releasing with, say, 1000 RC bugs is crazy, but maybe
> waiting forever for the last 100 packages is also nonsense.
>
> Maybe we could discriminate on the package's priorities. For example,
> about a third of the 49 packages *really* blocking the release (not
> waiting for a transition) are from "extra"[2]. Only 5 bugs affect
> required, important or standard packages. We could focus on those and
> tell the "extra packages" to hurry up or be shipped with packages that
> will need to be fixed in a point release... or simply removed.
That's something I already commented on in
https://lists.debian.org/debian-vote/2013/03/msg00020.html:
Another possible area of improvement is the focusing on the more
important RC bugs. One way to achieve that would be to remove as many
leaf/not-so-popular packages as possible at the start of the freeze.
If they get fixed, they could get back in. But then, if those
packages are not so important, it's better to focus the (scarse)
manpower on bugs affecting packages that we cannot live without.
Another way to achieve the same thing would be to improve existing
tools, such as http://udd.debian.org/bugs.cgi (which I developed) to
indicate bugs that are release blockers, or bugs that affect leaf
packages that could be removed.
> Maybe that's something that's already done by the release team too, in
> which case I am happy. :)
>
> A.
>
> [1] 38569, to be more exact, kudos to UDD:
>
> SELECT COUNT(DISTINCT(package)) FROM packages WHERE release = 'wheezy';
>
> [2] I had trouble with my SQL there, I could only list the packages:
>
> SELECT distinct(packages.package), packages.priority, bugs.id FROM bugs
> LEFT JOIN packages ON bugs.package = packages.package
> WHERE severity >= 'serious'
> AND NOT (id IN (SELECT id FROM bugs_merged_with WHERE id > merged_with))
> AND id IN (SELECT id FROM bugs_rt_affects_testing)
> AND id NOT IN (SELECT id FROM bugs_rt_affects_unstable)
> ORDER BY packages.priority;
SELECT count(distinct(packages.package)) FROM bugs
LEFT JOIN packages ON bugs.package = packages.package
WHERE severity >= 'serious'
AND NOT (id IN (SELECT id FROM bugs_merged_with WHERE id >
merged_with))
AND id IN (SELECT id FROM bugs_rt_affects_testing)
AND id NOT IN (SELECT id FROM bugs_rt_affects_unstable);
That would work, but then you have a problem with bugs filed against
source packages (what's the priority for a source package?).
Lucas
Reply to: