Re: [Rd] Looking for new maintainer of orphans R2HTML SemiPar cghseg hexbin lgtdl monreg muhaz operators pamr

2014-09-08 Thread billy am 
If no objections , I would like to volunteer for SemiPar.

Regards
Billy
On 8 Sep 2014 10:55, "Scott Kostyshak"  wrote:

> On Sun, Sep 7, 2014 at 7:03 PM, Uwe Ligges
>  wrote:
> >
> >
> > On 08.09.2014 01:01, Gregory R. Warnes wrote:
> >>
> >> And I’ll pick up hexbin.
> >
> >
> > Err, that one has been adopted a month ago already.
> >
> > open are:
> >
> > SemiPar cghseg monreg
>
> I will take monreg. Coincidentally my recent research is related.
>
> Best,
>
> Scott
>
>
> --
> Scott Kostyshak
> Economics PhD Candidate
> Princeton University
>
> >
> >
> > Best,
> > Uwe Ligges
> >
> >
> >
> >>
> >> -Greg
> >>
> >> On Sep 7, 2014, at 12:17 PM, Romain Francois 
> >> wrote:
> >>
> >>> I'll pick up operators.
> >>>
> >>> Le 7 sept. 2014 à 18:03, Uwe Ligges 
> a
> >>> écrit :
> >>>
> 
> 
>  On 05.09.2014 20:25, Greg Snow wrote:
> >
> > Uwe,
> >
> > Have all of these packages found new maintainers? if not, which ones
> > are still looking to be adopted?
> 
> 
>  Thanks for asking, the ones still looking to be adaopted are:
>  SemiPar cghseg monreg operators
> 
>  Best,
>  Uwe Ligges
> 
> 
> >
> > thanks,
> >
> > On Fri, Aug 8, 2014 at 10:41 AM, Uwe Ligges <
> uwe.lig...@r-project.org>
> > wrote:
> >>
> >> Dear maintainers and R-devel,
> >>
> >> Several orphaned CRAN packages are about to be archived due to
> >> outstanding
> >> QC problems, but have CRAN and BioC packages depending on them which
> >> would
> >> be broken by the archival (and hence need archiving alongside).
> >> Therefore we are looking for new maintainers taking over
> >> maintainership for
> >> one or more of the following packages:
> >>
> >> R2HTML SemiPar cghseg hexbin lgtdl monreg muhaz operators pamr
> >>
> >> Package maintainers whose packages depend on one of these may be
> >> natural
> >> candidates to become new maintainers.
> >> Hence this messages is addressed to all these maintainers via BCC
> and
> >> to
> >> R-devel.
> >>
> >> See
> >>
> >>   
> >>   
> >>   
> >>   
> >>   
> >>   
> >>   
> >>   
> >>   
> >>
> >> for information on the QC issues and the reverse dependencies.
> >>
> >> Best wishes,
> >> Uwe Ligges
> >> (for the CRAN team)
> >>
> >> __
> >> R-devel@r-project.org mailing list
> >> https://stat.ethz.ch/mailman/listinfo/r-devel
> >
> >
> >
> >
> 
>  __
>  R-devel@r-project.org mailing list
>  https://stat.ethz.ch/mailman/listinfo/r-devel
> >>>
> >>>
> >>> __
> >>> R-devel@r-project.org mailing list
> >>> https://stat.ethz.ch/mailman/listinfo/r-devel
> >>
> >>
> >
> > __
> > R-devel@r-project.org mailing list
> > https://stat.ethz.ch/mailman/listinfo/r-devel
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>

[[alternative HTML version deleted]]

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] Does (will) CRAN provide consistent integrity verification

2015-04-16 Thread billy am 
Agreed.  R-project.org and mirrors should be using https.

Billy
On 17 Apr 2015 06:26, "Dan Tenenbaum"  wrote:

>
>
> - Original Message -
> > From: "Matt Younce" 
> > To: r-devel@r-project.org
> > Sent: Thursday, April 16, 2015 9:32:04 AM
> > Subject: [Rd] Does (will) CRAN provide consistent integrity verification
> >
> > Intended Audience:  CRAN administrators, maintainers and R Package
> > Developers.
> > Does anyone know of consistent methods (or plans for near future) to
> > verify integrity of downloaded R package binaries from CRAN?
> > The purpose is to foster a high degree of trust in the validity of
> > downloaded binaries from CRAN.
> > For example Apache projects mostly provide something like MD5, SHA1,
> > SHA256, or signing with GnuPG, etc., as in
> > http://www.apache.org/dev/release-signing.
>
> And all of this is probably irrelevant unless packages can be downloaded
> over HTTPS.
>
> Dan
>
>
> > I have noticed that several R package zip files do contain MD5
> > strings, but not all do, and not as a separate download link.
> >  Besides, MD5 is not the preferred method.
> > What role in the administration of CRAN would be best positioned to
> > guide and assist R package developers (and/or repository
> > administrators) to provide a simple reliable method?
> > Without such features, the alternatives for many risk adverse
> > entities would be to resort to vendor releases of R which can be
> > cost prohibitive.
> > Several recent articles underscore the need is here now, so I am
> > hoping (and probably a growing number are also hoping) there is some
> > way to currently or easily achieve this without resorting to a big
> > dollar vendor.
> > Thanks very much for your help,
> > Matt Younce
> >
> >
> >   [[alternative HTML version deleted]]
> >
> > __
> > R-devel@r-project.org mailing list
> > https://stat.ethz.ch/mailman/listinfo/r-devel
> >
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>

[[alternative HTML version deleted]]

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel