Re: [Bioc-devel] xps build problem on toluca2
I will follow your advice and post on bioc-devel. Christian On 01/27/17 19:17, Obenchain, Valerie wrote: Yes, I will be taking over the build responsibilities with help from Herve. We don't want to give the impression that users need to contact us personally to install system dependencies. All dependencies should be listed in 'SystemRequirements' field of DESCRIPTION. xps does have root listed so it will eventually be installed on toluca2. I would encourage you to post on bioc-devel if the package were failing on an official builder due to missing dependencies. The problem may be more wide spread and it's helpful to have more than one person looking at it. Valerie On 01/27/2017 09:53 AM, cstrato wrote: Dear Valerie, Thank you for your extensive reply. I understand that it does not affect any users. It was only a reminder. Usually, I have contacted Dan personally, but I did not know whom to write. I assume that you are now responsible for the setup. If this is the case I will in the future contact you. Best regards, Christian On 01/27/17 15:46, Obenchain, Valerie wrote: Hi Christian, toluca2 is in the process of being set up and oaxaca is still the official Mac devel builder. There are a number of dependencies that need to be addressed on the new machine and we are working through them. It is important to understand that the error on toluca2 does not affect you or your users in any way. Binaries are propagated from oaxaca, not toluca2. Also, there are still no Mac binaries on CRAN for R 3.4. This means Bioc devel users on Mac need to install from source so they aren't concerned with the binaries at all. It may be confusing seeing build results for both Mac devel builders - internally we are tracking toluca2 but the one you need to watch is oaxaca. I don't think we announced this and maybe we should have to clarify what was going on. We will post on the mailing lists when toluca2 officially replaces oaxaca and at that point you'll only see toluca2 on the build report. Valerie On 01/26/2017 10:08 AM, cstrato wrote: Dear all, Since Dan, who was always very helpful and took care of the special requirements of my package 'xps', is no longer part of the BioC group, and I do not know who is currently responsible for the BioC servers, I am writing to you to inform you of the problem building 'xps' on the new Mac server 'toluca2': http://bioconductor.org/checkResults/devel/bioc-LATEST/xps/toluca2-buildsrc.html Could you please install ROOT on toluca2 to prevent the build error of 'xps'. Since both, toluca2 and oaxaca, are running Mac OS X Mavericks, it should be no problem to transfer ROOT and the corresponding settings to toluca2. Thank you in advance. Best regards, Christian _._._._._._._._._._._._._._._._._._ C.h.r.i.s.t.i.a.n S.t.r.a.t.o.w.a V.i.e.n.n.a A.u.s.t.r.i.a e.m.a.i.l:cstrato at aon.at _._._._._._._._._._._._._._._._._._ ___ Bioc-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/bioc-devel This email message may contain legally privileged and/or confidential information. If you are not the intended recipient(s), or the employee or agent responsible for the delivery of this message to the intended recipient(s), you are hereby notified that any disclosure, copying, distribution, or use of this email message is prohibited. If you have received this message in error, please notify the sender immediately by e-mail and delete this email message from your computer. Thank you. This email message may contain legally privileged and/or confidential information. If you are not the intended recipient(s), or the employee or agent responsible for the delivery of this message to the intended recipient(s), you are hereby notified that any disclosure, copying, distribution, or use of this email message is prohibited. If you have received this message in error, please notify the sender immediately by e-mail and delete this email message from your computer. Thank you. ___ Bioc-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/bioc-devel
Re: [Bioc-devel] xps build problem on toluca2
Yes, I will be taking over the build responsibilities with help from Herve. We don't want to give the impression that users need to contact us personally to install system dependencies. All dependencies should be listed in 'SystemRequirements' field of DESCRIPTION. xps does have root listed so it will eventually be installed on toluca2. I would encourage you to post on bioc-devel if the package were failing on an official builder due to missing dependencies. The problem may be more wide spread and it's helpful to have more than one person looking at it. Valerie On 01/27/2017 09:53 AM, cstrato wrote: > Dear Valerie, > > Thank you for your extensive reply. > > I understand that it does not affect any users. It was only a reminder. > > Usually, I have contacted Dan personally, but I did not know whom to > write. I assume that you are now responsible for the setup. If this is > the case I will in the future contact you. > > Best regards, > Christian > > > On 01/27/17 15:46, Obenchain, Valerie wrote: >> Hi Christian, >> >> toluca2 is in the process of being set up and oaxaca is still the >> official Mac devel builder. There are a number of dependencies that need >> to be addressed on the new machine and we are working through them. >> >> It is important to understand that the error on toluca2 does not affect >> you or your users in any way. Binaries are propagated from oaxaca, not >> toluca2. Also, there are still no Mac binaries on CRAN for R 3.4. This >> means Bioc devel users on Mac need to install from source so they aren't >> concerned with the binaries at all. >> >> It may be confusing seeing build results for both Mac devel builders - >> internally we are tracking toluca2 but the one you need to watch is >> oaxaca. I don't think we announced this and maybe we should have to >> clarify what was going on. We will post on the mailing lists when >> toluca2 officially replaces oaxaca and at that point you'll only see >> toluca2 on the build report. >> >> Valerie >> >> >> On 01/26/2017 10:08 AM, cstrato wrote: >>> Dear all, >>> >>> Since Dan, who was always very helpful and took care of the special >>> requirements of my package 'xps', is no longer part of the BioC group, >>> and I do not know who is currently responsible for the BioC servers, I >>> am writing to you to inform you of the problem building 'xps' on the new >>> Mac server 'toluca2': >>> http://bioconductor.org/checkResults/devel/bioc-LATEST/xps/toluca2-buildsrc.html >>> >>> Could you please install ROOT on toluca2 to prevent the build error of >>> 'xps'. >>> >>> Since both, toluca2 and oaxaca, are running Mac OS X Mavericks, it >>> should be no problem to transfer ROOT and the corresponding settings to >>> toluca2. >>> >>> Thank you in advance. >>> Best regards, >>> Christian >>> _._._._._._._._._._._._._._._._._._ >>> C.h.r.i.s.t.i.a.n S.t.r.a.t.o.w.a >>> V.i.e.n.n.a A.u.s.t.r.i.a >>> e.m.a.i.l:cstrato at aon.at >>> _._._._._._._._._._._._._._._._._._ >>> >>> ___ >>> Bioc-devel@r-project.org mailing list >>> https://stat.ethz.ch/mailman/listinfo/bioc-devel >>> >> >> >> This email message may contain legally privileged and/or confidential >> information. If you are not the intended recipient(s), or the employee or >> agent responsible for the delivery of this message to the intended >> recipient(s), you are hereby notified that any disclosure, copying, >> distribution, or use of this email message is prohibited. If you have >> received this message in error, please notify the sender immediately by >> e-mail and delete this email message from your computer. Thank you. >> This email message may contain legally privileged and/or confidential information. If you are not the intended recipient(s), or the employee or agent responsible for the delivery of this message to the intended recipient(s), you are hereby notified that any disclosure, copying, distribution, or use of this email message is prohibited. If you have received this message in error, please notify the sender immediately by e-mail and delete this email message from your computer. Thank you. ___ Bioc-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/bioc-devel
Re: [Bioc-devel] xps build problem on toluca2
Dear Valerie, Thank you for your extensive reply. I understand that it does not affect any users. It was only a reminder. Usually, I have contacted Dan personally, but I did not know whom to write. I assume that you are now responsible for the setup. If this is the case I will in the future contact you. Best regards, Christian On 01/27/17 15:46, Obenchain, Valerie wrote: Hi Christian, toluca2 is in the process of being set up and oaxaca is still the official Mac devel builder. There are a number of dependencies that need to be addressed on the new machine and we are working through them. It is important to understand that the error on toluca2 does not affect you or your users in any way. Binaries are propagated from oaxaca, not toluca2. Also, there are still no Mac binaries on CRAN for R 3.4. This means Bioc devel users on Mac need to install from source so they aren't concerned with the binaries at all. It may be confusing seeing build results for both Mac devel builders - internally we are tracking toluca2 but the one you need to watch is oaxaca. I don't think we announced this and maybe we should have to clarify what was going on. We will post on the mailing lists when toluca2 officially replaces oaxaca and at that point you'll only see toluca2 on the build report. Valerie On 01/26/2017 10:08 AM, cstrato wrote: Dear all, Since Dan, who was always very helpful and took care of the special requirements of my package 'xps', is no longer part of the BioC group, and I do not know who is currently responsible for the BioC servers, I am writing to you to inform you of the problem building 'xps' on the new Mac server 'toluca2': http://bioconductor.org/checkResults/devel/bioc-LATEST/xps/toluca2-buildsrc.html Could you please install ROOT on toluca2 to prevent the build error of 'xps'. Since both, toluca2 and oaxaca, are running Mac OS X Mavericks, it should be no problem to transfer ROOT and the corresponding settings to toluca2. Thank you in advance. Best regards, Christian _._._._._._._._._._._._._._._._._._ C.h.r.i.s.t.i.a.n S.t.r.a.t.o.w.a V.i.e.n.n.a A.u.s.t.r.i.a e.m.a.i.l:cstrato at aon.at _._._._._._._._._._._._._._._._._._ ___ Bioc-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/bioc-devel This email message may contain legally privileged and/or confidential information. If you are not the intended recipient(s), or the employee or agent responsible for the delivery of this message to the intended recipient(s), you are hereby notified that any disclosure, copying, distribution, or use of this email message is prohibited. If you have received this message in error, please notify the sender immediately by e-mail and delete this email message from your computer. Thank you. ___ Bioc-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/bioc-devel
Re: [Bioc-devel] xps build problem on toluca2
Hi Christian, toluca2 is in the process of being set up and oaxaca is still the official Mac devel builder. There are a number of dependencies that need to be addressed on the new machine and we are working through them. It is important to understand that the error on toluca2 does not affect you or your users in any way. Binaries are propagated from oaxaca, not toluca2. Also, there are still no Mac binaries on CRAN for R 3.4. This means Bioc devel users on Mac need to install from source so they aren't concerned with the binaries at all. It may be confusing seeing build results for both Mac devel builders - internally we are tracking toluca2 but the one you need to watch is oaxaca. I don't think we announced this and maybe we should have to clarify what was going on. We will post on the mailing lists when toluca2 officially replaces oaxaca and at that point you'll only see toluca2 on the build report. Valerie On 01/26/2017 10:08 AM, cstrato wrote: > Dear all, > > Since Dan, who was always very helpful and took care of the special > requirements of my package 'xps', is no longer part of the BioC group, > and I do not know who is currently responsible for the BioC servers, I > am writing to you to inform you of the problem building 'xps' on the new > Mac server 'toluca2': > http://bioconductor.org/checkResults/devel/bioc-LATEST/xps/toluca2-buildsrc.html > > Could you please install ROOT on toluca2 to prevent the build error of > 'xps'. > > Since both, toluca2 and oaxaca, are running Mac OS X Mavericks, it > should be no problem to transfer ROOT and the corresponding settings to > toluca2. > > Thank you in advance. > Best regards, > Christian > _._._._._._._._._._._._._._._._._._ > C.h.r.i.s.t.i.a.n S.t.r.a.t.o.w.a > V.i.e.n.n.a A.u.s.t.r.i.a > e.m.a.i.l:cstrato at aon.at > _._._._._._._._._._._._._._._._._._ > > ___ > Bioc-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/bioc-devel > This email message may contain legally privileged and/or confidential information. If you are not the intended recipient(s), or the employee or agent responsible for the delivery of this message to the intended recipient(s), you are hereby notified that any disclosure, copying, distribution, or use of this email message is prohibited. If you have received this message in error, please notify the sender immediately by e-mail and delete this email message from your computer. Thank you. ___ Bioc-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/bioc-devel
Re: [Bioc-devel] Code quality and bug reports
On 01/27/2017 03:30 AM, Lluís Revilla wrote: Dear Valerie, When I talked about maintenance status I thought something on the line of this badges at http://www.repostatus.org/ : Maybe only the last three status are relevant to Bioconductor : - Active: The project has reached a stable, usable state and is being actively developed. - Inactive: The project has reached a stable, usable state but is no longer being actively developed; support/maintenance will be provided as time allows. - Unsupported: The project has reached a stable, usable state but the author(s) have ceased all work on it. A new maintainer may be desired. I'm supportive of a clearer set of labels to replace the current 'posts' shield. We should not equate (new) development activity with level of support: there are other badges for that; one doesn't want development for development's sake; etc. We have to be very careful that the tags (and current discussion) provide positive reinforcement to conscientious developers / community members, rather than serving to bully or otherwise intimidate developers (sometimes silence is a constructive response, and an effective use of time). Iterating a little - Active (green): frequent support questions and answers - Mature (green): some support questions and answers - Inactive (orange): some support questions unanswered - Unsupported (red): (more than a few?) support questions not answered - Unknown (blue): no support questions Comments are ignored in the above scheme. Activity on packages with URL: or BugReports: fields in their DESCRIPTION file is ignored. 'frequent', 'some', and 'few' could be defined based on available data. Martin Tweaking a bit the description it could be used to classify the support given to a package. Given these categories and the information there is in the repositories and in support site I suggest the following: Giving the Active badge when there are commits (not done by the Bioconductor project) in 6 months. Excluding the Bioconductor team is done to prevent having packages as Active which are not, because the only change is the version number or minor changes done by the Bioconductor team (Also, is not the responsibility of the Bioconductor team to maintain the packages, is it?). Or when at least once every six months the package maintainer answers or comments a question (tagged with the package tag) in the support site if there is any.As an example edgeR would be Active, it has commits from the maintainers in the last 6 months. If a question tagged with a package tag is unanswered and the maintainer hasn't answered/commented in the last 6 months or there isn't any commit in the last 6 months the package (by the maintainer or other than the Bioconductor team) could be set to Inactive. CorMut would be Inactive and close to the Unsupported status. If there is any unanswered question tagged with a package tag and the maintainer hasn't answered/commented in the last year and there isn't any commit from the maintainer in the last 2 years, I would give the Unsupported tag to that package. topGO would be in that category. Once Unsupported status is reached the team could try to contact the maintainer to let him/her know that the maintainer position could be taken by somebody else willing to. Of course, if he/she makes commits or answers/comment questions in the support site to make the status of the package back to Active he/she could keep the maintainer status. This system could be along with the current End of Life Policy, or not, but gives an opportunity to the community of users to maintain a package they deem useful. It is a bit more complex but would guide much better on what packages are well supported and not only used. and those used but not supported could be saved from Deprecation. HTH, Lluís On 18 January 2017 at 17:52, Obenchain, Valerie < valerie.obench...@roswellpark.org> wrote: Hi, On 01/14/2017 03:01 AM, Lluís Revilla wrote: Dear Valerie and all, If I understood the page you kindly linked correctly, a package is deprecated: 1) When it fails to build and check (unless it is fixed). 2) When the maintainer asks for it. 3) If the maintainer is unresponsive (I assume when a mail is not delivered) and(/or?) doesn't answers questions about the package (How is this tracked? Which is the threshold for unanswered questions, 1 year? ) We contact maintainers when a package fails on the build system. There isn't a set rule on the number of times contacted with no response because there are so many exceptions, e.g., transferred maintainer ship, away from email due to travel, etc. I'd say the average number of contacts is 3 before getting the final 2 week notice. In some packages, it seems the maintainers receive the mails, and the packages build and past the daily checks of Bioconductor, but there are bugs and issues with those packages that are left unanswered and unsolved in support.bioconductor.org. Those package
Re: [Bioc-devel] Code quality and bug reports
Dear Valerie, When I talked about maintenance status I thought something on the line of this badges at http://www.repostatus.org/ : Maybe only the last three status are relevant to Bioconductor : - Active: The project has reached a stable, usable state and is being actively developed. - Inactive: The project has reached a stable, usable state but is no longer being actively developed; support/maintenance will be provided as time allows. - Unsupported: The project has reached a stable, usable state but the author(s) have ceased all work on it. A new maintainer may be desired. Tweaking a bit the description it could be used to classify the support given to a package. Given these categories and the information there is in the repositories and in support site I suggest the following: Giving the Active badge when there are commits (not done by the Bioconductor project) in 6 months. Excluding the Bioconductor team is done to prevent having packages as Active which are not, because the only change is the version number or minor changes done by the Bioconductor team (Also, is not the responsibility of the Bioconductor team to maintain the packages, is it?). Or when at least once every six months the package maintainer answers or comments a question (tagged with the package tag) in the support site if there is any.As an example edgeR would be Active, it has commits from the maintainers in the last 6 months. If a question tagged with a package tag is unanswered and the maintainer hasn't answered/commented in the last 6 months or there isn't any commit in the last 6 months the package (by the maintainer or other than the Bioconductor team) could be set to Inactive. CorMut would be Inactive and close to the Unsupported status. If there is any unanswered question tagged with a package tag and the maintainer hasn't answered/commented in the last year and there isn't any commit from the maintainer in the last 2 years, I would give the Unsupported tag to that package. topGO would be in that category. Once Unsupported status is reached the team could try to contact the maintainer to let him/her know that the maintainer position could be taken by somebody else willing to. Of course, if he/she makes commits or answers/comment questions in the support site to make the status of the package back to Active he/she could keep the maintainer status. This system could be along with the current End of Life Policy, or not, but gives an opportunity to the community of users to maintain a package they deem useful. It is a bit more complex but would guide much better on what packages are well supported and not only used. and those used but not supported could be saved from Deprecation. HTH, Lluís On 18 January 2017 at 17:52, Obenchain, Valerie < valerie.obench...@roswellpark.org> wrote: > Hi, > > On 01/14/2017 03:01 AM, Lluís Revilla wrote: > > Dear Valerie and all, > > > > If I understood the page you kindly linked correctly, a package is > deprecated: > > 1) When it fails to build and check (unless it is fixed). > > 2) When the maintainer asks for it. > > 3) If the maintainer is unresponsive (I assume when a mail is not > > delivered) and(/or?) doesn't answers questions about the package (How > > is this tracked? Which is the threshold for unanswered questions, 1 > > year? ) > We contact maintainers when a package fails on the build system. There > isn't a set rule on the number of times contacted with no response > because there are so many exceptions, e.g., transferred maintainer ship, > away from email due to travel, etc. I'd say the average number of > contacts is 3 before getting the final 2 week notice. > > > > > In some packages, it seems the maintainers receive the mails, and the > > packages build and past the daily checks of Bioconductor, but there > > are bugs and issues with those packages that are left unanswered and > > unsolved in support.bioconductor.org. Those packages that are still > > functional and used but don't receive maintenance are then kept ? How > > should the community help to solve those issues? > A primary motivation for implementing badges on the landing pages was to > provide the "maintenance status" you mention below. The badge stats give > an idea of how active the maintainer is (posts, commits, coverage) as > well as the level of use by others (downloads). The 'posts' badge shows > support site activity over that past 6 months in terms of 4 fields: > tagged questions / average answers per question / average comments per > question / accepted answers. > > The CorMut package has no tagged questions: > > http://www.bioconductor.org/packages/3.5/bioc/html/CorMut.html > > If Guangchuang had asked questions on the support site instead of > posting comments in a gist there would be a number of tagged questions > with no answers. This would give other users some data to go on - an > unresponsive maintainer of a package with no unit tests. In contrast, a > package like edgeR has an averag
