Re: Release sprint results - team changes, auto-rm and arch status
On 2014-01-11 23:10, Robert Millan wrote: On 11/01/2014 21:32, Niels Thykier wrote: As for #712848, the latest comment sent by Petr suggested that the test might be incorrect when applied to kqueue. I guess you are referring to comment #25 here? Quote: [...] Seems like no one picked it up from there. To be honest, I am not sure where the ball is on that bug right now - as an outsider it is not clear to me if Petr is asking for the GNOME maintainers or the BSD porters to follow/second him. Admittedly, I have very limited knowledge of the code in question, so it may be more obvious to you. Perhaps you could follow up on the bug and prod the GNOME maintainers for a follow up, if you believe the ball is in their court right now. Before we get into that, would it be possible to establish the severity of this bug? Specifically, whether it is Release-Critical or not. It is currently marked as non-RC, and so far we haven't seen any indication that it produces actual breakage (outside the testsuite, that is) [1]. It was filed as serious and then downgraded by Julien on July 9th. Indeed, buildd.d.o lists no build problems at all. So at first glance I would expect the tests to have been disabled/ignored. Assuming this is no a simple error-hiding tactics, then the bug is non-RC. If it hides user-visible errors, then the severity depends on the (consequences of the) errors hidden. However, your comments in this and earlier mails seem to imply that it is RC, or that you think it could be. I had no intention of making such an implication. From what I gathered from various sources, glib and GNOME on kFreeBSD had issues and that is what I am following up on. In our experience as porters, we've found that we get lots of testsuite failures (and not just in GNOME). However, often the tests just fail because they're overzealous, or because they make wrong (unportable) assumptions about the underlying APIs. The assumption here is that the test is indeed overzealous / not relevant to kFreeBSD and have no value as a regression test on kFreeBSD. If that is indeed the case, by all means (have the maintainer) disable the test on kFreeBSD and close the bug. The concern from my point of view, is if a valid test is disabled when it could have been ported. The last thing I want is to have an RC bug appear in testing for a problem the regression test suite from upstream could have caught. I believe #628383 would be a good example of what I'm saying. But the problem is very typical. It's not uncommon for us to submit fixes for testsuite bugs rather than having to fix the bugs the tests are supposed to find. I believe that is perfectly fine to fix portability issues in the tests themselves. Probably Petr and/or Steven can elaborate more on this, since they've been much more actively involved than me in this kind of work. Ok. [1] If the reason it is RC is that it causes FTBFS (and serious buildd grief), I think http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=734290#10 is a good solution in that regard. This particular kind of resolution would concern me. Simply disabling all tests and ignoring all problems would undermine any value of the regression test suite (on non-Linux ports in this case) and allow RC bugs to migrate to testing before they are noticed. With my release hat on, I want as many problems stopped before they reach testing. Having a build-time regression test suites from upstream is certainly valuable in this regard and we currently have no replacement for testing the actual program itself. ~Niels -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/52d25121.5040...@thykier.net
Re: Release sprint results - team changes, auto-rm and arch status
On 12/01/2014 09:24, Niels Thykier wrote: It was filed as serious and then downgraded by Julien on July 9th. Indeed, buildd.d.o lists no build problems at all. So at first glance I would expect the tests to have been disabled/ignored. Assuming this is no a simple error-hiding tactics, then the bug is non-RC. If it hides user-visible errors, then the severity depends on the (consequences of the) errors hidden. I had no intention of making such an implication. From what I gathered from various sources, glib and GNOME on kFreeBSD had issues and that is what I am following up on. I think it'd be helpful for us to have a more precise list of the RC problems, or the releasability criteria in general. Having a clearly defined set of goals makes it much easier for us to allocate our resources efficiently. For example, if some source says that kFreeBSD has issues, I think it would be easiest for us to handle them if such issues were filed in the BTS. This ensures that for each issue, we know: - Its severity - An accurate description of the problem - Instructions on how to reproduce it Lacking that, we can still try to help, but our ability is impaired. For example, I've been trying to assess the state of GNOME in general by trying to find bugs myself. I will report my findings soon, however this is clearly not optimal. My quick kick the tires testing is much less reliable than day-to-day usage in production done by real users. In our experience as porters, we've found that we get lots of testsuite failures (and not just in GNOME). However, often the tests just fail because they're overzealous, or because they make wrong (unportable) assumptions about the underlying APIs. The assumption here is that the test is indeed overzealous / not relevant to kFreeBSD and have no value as a regression test on kFreeBSD. If that is indeed the case, by all means (have the maintainer) disable the test on kFreeBSD and close the bug. Well, unfortunately we don't know for sure yet. Question is: how much priority should we give to this kind of issues? I don't mean to undermine the usefulness of testsuites. I often use them myself (in fact, we've written some for this port, for example see the one in kfreebsd-kernel-headers). However, while as you pointed out, testsuites are very useful to detect regressions, I think you'll agree that they're not that useful when they're just more unportable code that we need to fix. The concern from my point of view, is if a valid test is disabled when it could have been ported. The last thing I want is to have an RC bug appear in testing for a problem the regression test suite from upstream could have caught. Yes, I perfectly understand that. I don't propose to leave testsuites unattended. I'm just saying that when we try to stop everything when one test fails, so far this has had counter-productive results. (I'll ellaborate on this further below, on discussion regarding #734290, which I think is a very good example of what I'm saying) I believe #628383 would be a good example of what I'm saying. But the problem is very typical. It's not uncommon for us to submit fixes for testsuite bugs rather than having to fix the bugs the tests are supposed to find. I believe that is perfectly fine to fix portability issues in the tests themselves. Yes. My point is that if we devote all our time and effort in fixing non-RC problems, then we're diverting our attention from the actual RC problems which need fixing. [1] If the reason it is RC is that it causes FTBFS (and serious buildd grief), I think http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=734290#10 is a good solution in that regard. This particular kind of resolution would concern me. Simply disabling all tests and ignoring all problems would undermine any value of the regression test suite (on non-Linux ports in this case) and allow RC bugs to migrate to testing before they are noticed. Please note that what I'm proposing goes in the opposite direction of what you want to avoid! Currently the testsuite in glib2.0 is completely disabled. I haven't tracked down the reasons why the maintainer disabled it, but it's probably something like: 1- Some test failed, causing FTBFS. Maintainer filed RC bug. 2- We investigated and found that the test is unlikely to have found an actual bug. We give some pointers on how to resolve this. 3- Nobody fixes the test. Maintainer is in a hurry to migrate the package, and disables the testsuite on kfreebsd. My proposal is to: 1- Re-enable the testsuite, without making failures result in FTBFS. 2- Avoid test hangs completely by running them with timeout(1). This preserves the exit status so we aren't losing any information. With my release hat on, I want as many problems stopped before they reach testing. Having a build-time regression test suites from upstream is certainly valuable in this regard and we currently have no
Re: Release sprint results - team changes, auto-rm and arch status
Hi, Robert Millan wrote (12 Jan 2014 12:35:56 GMT) : For example, I've been trying to assess the state of GNOME in general by trying to find bugs myself. I will report my findings soon, however this is clearly not optimal. My quick kick the tires testing is much less reliable than day-to-day usage in production done by real users. I'm somewhat surprised that such real Debian/kFreeBSD users (who I expect to be a bit more tech-savvy than the average Debian user) who use GNOME on a day-to-day basis are not reporting such bugs to the BTS. This makes me curious. Assuming these real users actually exist, what steps can be taken within the Debian/kFreeBSD community to improve this? I've no idea what kind of communication channels the porters have with the corresponding users, so I'm wondering. Cheers, -- intrigeri | GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc | OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/85k3e5e50j@boum.org
Re: Release sprint results - team changes, auto-rm and arch status
On 12/01/2014 13:52, intrigeri wrote: Hi, Robert Millan wrote (12 Jan 2014 12:35:56 GMT) : For example, I've been trying to assess the state of GNOME in general by trying to find bugs myself. I will report my findings soon, however this is clearly not optimal. My quick kick the tires testing is much less reliable than day-to-day usage in production done by real users. I'm somewhat surprised that such real Debian/kFreeBSD users (who I expect to be a bit more tech-savvy than the average Debian user) who use GNOME on a day-to-day basis are not reporting such bugs to the BTS. This makes me curious. Assuming these real users actually exist, what steps can be taken within the Debian/kFreeBSD community to improve this? I've no idea what kind of communication channels the porters have with the corresponding users, so I'm wondering. The BTS should be the only channel, IMHO. Though the mailing lists are often used to report problems, I think this should be avoided whenever possible. When you find a bug, please use the BTS and if it's relevant to kFreeBSD put debian-bsd on CC. This will make our effort much easier. Specifically regarding the ability to test GNOME, I think #733122 is the biggest blocker right now. Once this is fixed, testing GNOME will become much more straightforward for the average user. -- Robert Millan -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/52d2bc23.1080...@debian.org
Re: Release sprint results - team changes, auto-rm and arch status
On 2014-01-05 12:22, Robert Millan wrote: On 05/01/2014 10:30, Niels Thykier wrote: On 2013-12-16 23:32, Robert Millan wrote: On 15/12/2013 13:34, Niels Thykier wrote: It would probably be good if you (i.e. the BSD porters) could start a dialogue with the GNOME maintainers and figure out exactly where GNOME is on kFreeBSD (vs. where it is supposed to be). Once that is sorted out, please send the release team a summary of the status so we have accurate information here. Will do. But this can't be done right away. The reports you mention are too vague (xxx doesn't work, etc) to act upon. We will first need to evaluate the current state of things to have an accurate idea on where we stand regarding GNOME. Hi Robert / BSD porters, Any news on your front on the status of GNOME on kFreeBSD? Hi, So far #733122. Barring that, the GNOME desktop seems to work fine (including empathy, nautilus, etc). Once the patch in #733122 is applied, it will be easier to gather reports from day-to-day users and provide a more complete assessment. Thanks for looking into this. I have asked on #d-gnome about the patch you submitted; hopefully it can be applied soon, so we can get a better view. GDM is a different story (see #733546). The problem goes much deeper though. It's now begun to use SystemD by default, and then falling back to ConsoleKit when that's not available. There are two serious problems with this: - The GDM-ConsoleKit codepath is seldom tested. We don't know if it's actually working. - According to upstream website, ConsoleKit is deprecated and not actively maintained. We can help as porters but we can't maintain abandoned codepaths on our own. I think GDM upstream doesn't want to deal with this problem, so perhaps it is better if we accept that GDM is not a portable program anymore, and make it Linux-only. Do you have an idea of the consequences of making it linux-only? If it is just using (e.g.) xdm instead of and kFreeBSD losing a couple of packages, it will probably not be much of an issue. But then, I assume that GNOME and GDM are not tightly coupled. And then there's #734070 which AFAICT only results in a few harmless errors (still, it'd be nice to have it merged, just in case). Good. :) The other day, I was told on IRC that some of the glib tests had been disabled / ignored on kFreeBSD (see #649196 and #712848). I have not reviewed them in detail, though the former have no follow up at all (but I don't see a CC either, so I guess that is not surprising). #649196 is probably not an issue anymore. We've replaced our thread implementation since. Okay, perhaps you could follow up on the bug with that information and ask if it is still an issue? As for #712848, the latest comment sent by Petr suggested that the test might be incorrect when applied to kqueue. I guess you are referring to comment #25 here? Quote: This test is guarded by: [...] The kqueue support might have the same limit. I do not know whether is better to use kqueue via gamin or kqueue directly in glib2.0. Petr Seems like no one picked it up from there. To be honest, I am not sure where the ball is on that bug right now - as an outsider it is not clear to me if Petr is asking for the GNOME maintainers or the BSD porters to follow/second him. Admittedly, I have very limited knowledge of the code in question, so it may be more obvious to you. Perhaps you could follow up on the bug and prod the GNOME maintainers for a follow up, if you believe the ball is in their court right now. ~Niels -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/52d1aa50.8000...@thykier.net
Re: Release sprint results - team changes, auto-rm and arch status
On 11/01/2014 21:32, Niels Thykier wrote: So far #733122. Barring that, the GNOME desktop seems to work fine (including empathy, nautilus, etc). Once the patch in #733122 is applied, it will be easier to gather reports from day-to-day users and provide a more complete assessment. Thanks for looking into this. I have asked on #d-gnome about the patch you submitted; hopefully it can be applied soon, so we can get a better view. Excellent, thanks. We can help as porters but we can't maintain abandoned codepaths on our own. I think GDM upstream doesn't want to deal with this problem, so perhaps it is better if we accept that GDM is not a portable program anymore, and make it Linux-only. Do you have an idea of the consequences of making it linux-only? If it is just using (e.g.) xdm instead of and kFreeBSD losing a couple of packages, it will probably not be much of an issue. But then, I assume that GNOME and GDM are not tightly coupled. Yes, I think that's the case. I still have to look a bit more carefully though, so please don't take my word on it. I'll followup on this. #649196 is probably not an issue anymore. We've replaced our thread implementation since. Okay, perhaps you could follow up on the bug with that information and ask if it is still an issue? Done. (I'll reply to the remaining bits in a separate mail) -- Robert Millan -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/52d1bd86.60...@debian.org
Re: Release sprint results - team changes, auto-rm and arch status
On 11/01/2014 21:32, Niels Thykier wrote: As for #712848, the latest comment sent by Petr suggested that the test might be incorrect when applied to kqueue. I guess you are referring to comment #25 here? Quote: This test is guarded by: [...] The kqueue support might have the same limit. I do not know whether is better to use kqueue via gamin or kqueue directly in glib2.0. Petr Seems like no one picked it up from there. To be honest, I am not sure where the ball is on that bug right now - as an outsider it is not clear to me if Petr is asking for the GNOME maintainers or the BSD porters to follow/second him. Admittedly, I have very limited knowledge of the code in question, so it may be more obvious to you. Perhaps you could follow up on the bug and prod the GNOME maintainers for a follow up, if you believe the ball is in their court right now. Before we get into that, would it be possible to establish the severity of this bug? Specifically, whether it is Release-Critical or not. It is currently marked as non-RC, and so far we haven't seen any indication that it produces actual breakage (outside the testsuite, that is) [1]. However, your comments in this and earlier mails seem to imply that it is RC, or that you think it could be. In our experience as porters, we've found that we get lots of testsuite failures (and not just in GNOME). However, often the tests just fail because they're overzealous, or because they make wrong (unportable) assumptions about the underlying APIs. I believe #628383 would be a good example of what I'm saying. But the problem is very typical. It's not uncommon for us to submit fixes for testsuite bugs rather than having to fix the bugs the tests are supposed to find. Probably Petr and/or Steven can elaborate more on this, since they've been much more actively involved than me in this kind of work. [1] If the reason it is RC is that it causes FTBFS (and serious buildd grief), I think http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=734290#10 is a good solution in that regard. -- Robert Millan -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/52d1c159.3020...@debian.org
gdm3 (was: Re: Release sprint results - team changes, auto-rm and arch status)
On 11/01/2014 22:54, Robert Millan wrote: Do you have an idea of the consequences of making it linux-only? If it is just using (e.g.) xdm instead of and kFreeBSD losing a couple of packages, it will probably not be much of an issue. But then, I assume that GNOME and GDM are not tightly coupled. Yes, I think that's the case. I still have to look a bit more carefully though, so please don't take my word on it. I'll followup on this. See #735023. Result of my tests is included there. -- Robert Millan -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/52d1cd49.9060...@debian.org
Re: Release sprint results - team changes, auto-rm and arch status
Wiadomość napisana przez Robert Millan w dniu 5 sty 2014, o godz. 19:09: On 05/01/2014 18:47, Edward Tomasz Napierała wrote: We can help as porters but we can't maintain abandoned codepaths on our own. I think GDM upstream doesn't want to deal with this problem, so perhaps it is better if we accept that GDM is not a portable program anymore, and make it Linux-only. Or perhaps write a library that provides systemd APIs GDM requires, implemented as wrappers around other stuff. Who will do this? Do you volunteer? I don't have any immediate plans to do it, no. But never say never :-) And afterwards, who will keep it up to date? SystemD doesn't conform to any standard or specification. The definition of systemd APIs GDM requires is implementation-defined and can change every day, without notice. When this creates new problems, who will debug them? As you noticed, the alternative would be to either maintain stuff no longer used in Linux, or port systemd, which would probably stay specific to Debian/kFreeBSD. A set of wrappers might be simpler. -- If you cut off my head, what would I say? Me and my head, or me and my body? -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/0597f47b-2dfa-475f-aa63-06f3eb8cd...@freebsd.org
Re: Release sprint results - team changes, auto-rm and arch status
On 2013-12-16 23:32, Robert Millan wrote: On 15/12/2013 13:34, Niels Thykier wrote: It would probably be good if you (i.e. the BSD porters) could start a dialogue with the GNOME maintainers and figure out exactly where GNOME is on kFreeBSD (vs. where it is supposed to be). Once that is sorted out, please send the release team a summary of the status so we have accurate information here. Will do. But this can't be done right away. The reports you mention are too vague (xxx doesn't work, etc) to act upon. We will first need to evaluate the current state of things to have an accurate idea on where we stand regarding GNOME. Hi Robert / BSD porters, Any news on your front on the status of GNOME on kFreeBSD? The other day, I was told on IRC that some of the glib tests had been disabled / ignored on kFreeBSD (see #649196 and #712848). I have not reviewed them in detail, though the former have no follow up at all (but I don't see a CC either, so I guess that is not surprising). ~Niels -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/52c9264b.1050...@thykier.net
Re: Release sprint results - team changes, auto-rm and arch status
On 05/01/2014 10:30, Niels Thykier wrote: On 2013-12-16 23:32, Robert Millan wrote: On 15/12/2013 13:34, Niels Thykier wrote: It would probably be good if you (i.e. the BSD porters) could start a dialogue with the GNOME maintainers and figure out exactly where GNOME is on kFreeBSD (vs. where it is supposed to be). Once that is sorted out, please send the release team a summary of the status so we have accurate information here. Will do. But this can't be done right away. The reports you mention are too vague (xxx doesn't work, etc) to act upon. We will first need to evaluate the current state of things to have an accurate idea on where we stand regarding GNOME. Hi Robert / BSD porters, Any news on your front on the status of GNOME on kFreeBSD? So far #733122. Barring that, the GNOME desktop seems to work fine (including empathy, nautilus, etc). Once the patch in #733122 is applied, it will be easier to gather reports from day-to-day users and provide a more complete assessment. GDM is a different story (see #733546). The problem goes much deeper though. It's now begun to use SystemD by default, and then falling back to ConsoleKit when that's not available. There are two serious problems with this: - The GDM-ConsoleKit codepath is seldom tested. We don't know if it's actually working. - According to upstream website, ConsoleKit is deprecated and not actively maintained. We can help as porters but we can't maintain abandoned codepaths on our own. I think GDM upstream doesn't want to deal with this problem, so perhaps it is better if we accept that GDM is not a portable program anymore, and make it Linux-only. And then there's #734070 which AFAICT only results in a few harmless errors (still, it'd be nice to have it merged, just in case). The other day, I was told on IRC that some of the glib tests had been disabled / ignored on kFreeBSD (see #649196 and #712848). I have not reviewed them in detail, though the former have no follow up at all (but I don't see a CC either, so I guess that is not surprising). #649196 is probably not an issue anymore. We've replaced our thread implementation since. As for #712848, the latest comment sent by Petr suggested that the test might be incorrect when applied to kqueue. -- Robert Millan -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/52c9407a.4040...@debian.org
Re: Release sprint results - team changes, auto-rm and arch status
Wiadomość napisana przez Robert Millan w dniu 5 sty 2014, o godz. 12:22: On 05/01/2014 10:30, Niels Thykier wrote: On 2013-12-16 23:32, Robert Millan wrote: On 15/12/2013 13:34, Niels Thykier wrote: It would probably be good if you (i.e. the BSD porters) could start a dialogue with the GNOME maintainers and figure out exactly where GNOME is on kFreeBSD (vs. where it is supposed to be). Once that is sorted out, please send the release team a summary of the status so we have accurate information here. Will do. But this can't be done right away. The reports you mention are too vague (xxx doesn't work, etc) to act upon. We will first need to evaluate the current state of things to have an accurate idea on where we stand regarding GNOME. Hi Robert / BSD porters, Any news on your front on the status of GNOME on kFreeBSD? So far #733122. Barring that, the GNOME desktop seems to work fine (including empathy, nautilus, etc). Once the patch in #733122 is applied, it will be easier to gather reports from day-to-day users and provide a more complete assessment. GDM is a different story (see #733546). The problem goes much deeper though. It's now begun to use SystemD by default, and then falling back to ConsoleKit when that's not available. There are two serious problems with this: - The GDM-ConsoleKit codepath is seldom tested. We don't know if it's actually working. - According to upstream website, ConsoleKit is deprecated and not actively maintained. We can help as porters but we can't maintain abandoned codepaths on our own. I think GDM upstream doesn't want to deal with this problem, so perhaps it is better if we accept that GDM is not a portable program anymore, and make it Linux-only. Or perhaps write a library that provides systemd APIs GDM requires, implemented as wrappers around other stuff. -- If you cut off my head, what would I say? Me and my head, or me and my body? -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/e39a9658-f711-49b8-93e8-c2987155a...@freebsd.org
Re: Release sprint results - team changes, auto-rm and arch status
On 05/01/2014 18:47, Edward Tomasz Napierała wrote: We can help as porters but we can't maintain abandoned codepaths on our own. I think GDM upstream doesn't want to deal with this problem, so perhaps it is better if we accept that GDM is not a portable program anymore, and make it Linux-only. Or perhaps write a library that provides systemd APIs GDM requires, implemented as wrappers around other stuff. Who will do this? Do you volunteer? And afterwards, who will keep it up to date? SystemD doesn't conform to any standard or specification. The definition of systemd APIs GDM requires is implementation-defined and can change every day, without notice. When this creates new problems, who will debug them? -- Robert Millan -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/52c99fc1.1050...@debian.org
Re: Release sprint results - team changes, auto-rm and arch status
On 15/12/2013 13:34, Niels Thykier wrote: It would probably be good if you (i.e. the BSD porters) could start a dialogue with the GNOME maintainers and figure out exactly where GNOME is on kFreeBSD (vs. where it is supposed to be). Once that is sorted out, please send the release team a summary of the status so we have accurate information here. Will do. But this can't be done right away. The reports you mention are too vague (xxx doesn't work, etc) to act upon. We will first need to evaluate the current state of things to have an accurate idea on where we stand regarding GNOME. -- Robert Millan -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/52af7f88.50...@debian.org
Re: Release sprint results - team changes, auto-rm and arch status
On 2013-11-30 11:46, Robert Millan wrote: On 28/11/2013 21:49, Steven Chamberlain wrote: On 28/11/13 20:04, Niels Thykier wrote: kFreeBSD was a technology preview, and has not generated enough user interest to bring in sufficient install base to continue in this state. We will review this situation after 28th January 2014. Architectures still causing us concern at that point will join ia64 in no longer being considered for britney migrations and may be dropped from testing after a further period. I'm unclear on what this means, or what should happen by that date to ensure it is considered sufficient to continue in 'this state' (meaning, a release architecture and considered for Britney migration?). Hi, Sorry for the very late reply to this mail. Uhm I think we both may have misunderstood. Perhaps 'this state' just means 'as technology preview'. I.e. normal QA requirements are no longer waived because of preview status. This is exactly what we meant; we intend to not do technology previews for Jessie. If that is the case, I think the kFreeBSD port is perfectly capable of meeting these requirements. The system is quite robust already, in fact I've used it in production environments several times (including infrastructure for a major corporation which will remain unnamed), with very satisfactory results. We have heard reports of issues with GNOME that are allegedly going on answered or/and are not resolved. These are issues reported to debian-bsd@l.d.o by the GNOME maintainers - the examples I got include [1] and [2]. Disclaimer: I have not had the time to read all examples I got or read the full threads of these examples. Nor did I get these directly from the GNOME maintainers; these are examples provided by members of the release team during the sprint[3]. It would probably be good if you (i.e. the BSD porters) could start a dialogue with the GNOME maintainers and figure out exactly where GNOME is on kFreeBSD (vs. where it is supposed to be). Once that is sorted out, please send the release team a summary of the status so we have accurate information here. ~Niels [1] https://lists.debian.org/debian-bsd/2013/10/msg00144.html [2] https://lists.debian.org/debian-bsd/2013/10/msg00145.html [3] I cannot rule out that they got the examples from the GNOME maintainers. -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/52ada1db.8040...@thykier.net
Re: Release sprint results - team changes, auto-rm and arch status
On 2013-11-29 13:48, Ian Jackson wrote: Niels Thykier writes (Release sprint results - team changes, auto-rm and arch status): Default Urgency === We believe that it should be acceptable for most uploads to unstable to be uploaded with medium urgency, to reduce the delay for testing migrations. Therefore, we have requested [#730343] that the dch tool defaults to medium urgency. It should be clear that uploaders can (and should) override the urgency to low for changes they know are disruptive. For packages not in testing, the migration delay of 10 days will not be changed. [#730343] http://bugs.debian.org/730343 I think debian-changelog-mode.el doesn't dch to generate new entries, but it itself ? So you need to file a bug against dpkg-dev-el. The setting appears to be implemented in debian-changelog-add-version in the obvious (hardcoded) way. Ian. Hi Ian, Thanks for the heads up. Matt seems to have taken care of it (#731105#34). Thank you, Matt. :) ~Niels -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/52ada817.8060...@thykier.net
Re: Re: Release sprint results - team changes, auto-rm and arch status
Gnome guys is not interested in help kFreeBSD because now Gnome is Linux-only. FreeBSD guys is porting Gnome 3.6 yet and Debian has 3.10 incoming. I think is more feasible to bet on a Gnome-derivative DE like MATE and/or Cinnamon because they are portable and they are interested in being portable. Because of that I think is more just Cinnamon/Mate be the next default for Debian. Something like the former CD and DVD of xfce-lxde, I think is possible bring Cinnamon and Mate at the same optical media and still be smaller than Gnome. I think that make more sense than bring Xfce because the Cinnamon and Mate are forks and can replace Gnome perfectly including some packages like Pidgin, Gparted, Icedove and VLC. Mate is coming for jessie. I think until the freeze we have Mate. -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/6162c6613da00442822bfd25f6378...@openmailbox.org
Re: Release sprint results - team changes, auto-rm and arch status
On 15/12/13 12:34, Niels Thykier wrote: Uhm I think we both may have misunderstood. Perhaps 'this state' just means 'as technology preview'. I.e. normal QA requirements are no longer waived because of preview status. This is exactly what we meant; we intend to not do technology previews for Jessie. I assumed kFreeBSD no longer carried the 'technology preview' label for the wheezy release, and that it was subject to normal testing migration and release policy already. 'Technology preview' status allowed a more forgiving policy on unblock requests. I don't think that was ever relevant during the wheezy freeze because whatever bugs we had were already inherently RC? Regards, -- Steven Chamberlain ste...@pyro.eu.org -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/52ade555.4000...@pyro.eu.org
Re: Release sprint results - team changes, auto-rm and arch status
On 28/11/2013 21:49, Steven Chamberlain wrote: On 28/11/13 20:04, Niels Thykier wrote: kFreeBSD was a technology preview, and has not generated enough user interest to bring in sufficient install base to continue in this state. We will review this situation after 28th January 2014. Architectures still causing us concern at that point will join ia64 in no longer being considered for britney migrations and may be dropped from testing after a further period. I'm unclear on what this means, or what should happen by that date to ensure it is considered sufficient to continue in 'this state' (meaning, a release architecture and considered for Britney migration?). Uhm I think we both may have misunderstood. Perhaps 'this state' just means 'as technology preview'. I.e. normal QA requirements are no longer waived because of preview status. If that is the case, I think the kFreeBSD port is perfectly capable of meeting these requirements. The system is quite robust already, in fact I've used it in production environments several times (including infrastructure for a major corporation which will remain unnamed), with very satisfactory results. -- Robert Millan -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/5299c1ed.2010...@debian.org
Re: Release sprint results - team changes, auto-rm and arch status
On 28/11/2013 21:49, Steven Chamberlain wrote: On 28/11/13 20:04, Niels Thykier wrote: kFreeBSD was a technology preview, and has not generated enough user interest to bring in sufficient install base to continue in this state. We will review this situation after 28th January 2014. Architectures still causing us concern at that point will join ia64 in no longer being considered for britney migrations and may be dropped from testing after a further period. I'm not sure what the threshold for sufficient install base is, but if it's lower than 129 then I'm sorry to hear that mipsel and s390(x) are being removed. -- Robert Millan -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/52988904.6030...@debian.org
Re: Release sprint results - team changes, auto-rm and arch status
Niels Thykier writes (Release sprint results - team changes, auto-rm and arch status): Default Urgency === We believe that it should be acceptable for most uploads to unstable to be uploaded with medium urgency, to reduce the delay for testing migrations. Therefore, we have requested [#730343] that the dch tool defaults to medium urgency. It should be clear that uploaders can (and should) override the urgency to low for changes they know are disruptive. For packages not in testing, the migration delay of 10 days will not be changed. [#730343] http://bugs.debian.org/730343 I think debian-changelog-mode.el doesn't dch to generate new entries, but it itself ? So you need to file a bug against dpkg-dev-el. The setting appears to be implemented in debian-changelog-add-version in the obvious (hardcoded) way. Ian. -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/21144.36101.62493.83...@chiark.greenend.org.uk
Re: Release sprint results - team changes, auto-rm and arch status
On 28/11/13 20:04, Niels Thykier wrote: kFreeBSD was a technology preview, and has not generated enough user interest to bring in sufficient install base to continue in this state. We will review this situation after 28th January 2014. Architectures still causing us concern at that point will join ia64 in no longer being considered for britney migrations and may be dropped from testing after a further period. I'm unclear on what this means, or what should happen by that date to ensure it is considered sufficient to continue in 'this state' (meaning, a release architecture and considered for Britney migration?). An obvious place for a porter assess their own compliance might be to look the release team's policy document on this: [ARCH-POL] http://release.debian.org/jessie/arch_policy.html but the only thing I see relating to the above, is Users: ... at least 50 which is currently true of both kfreebsd-amd64 and kfreebsd-i386. as demonstrated by popcon. Regards, -- Steven Chamberlain ste...@pyro.eu.org signature.asc Description: OpenPGP digital signature
