On Mar 17 12:43, Christopher Faylor wrote: > On Sun, Mar 17, 2013 at 10:35:46AM +0100, Corinna Vinschen wrote: > >On Mar 17 02:27, Christopher Faylor wrote: > >> If we're going to do that then I'd like the actual maintainers to start > >> generating packages rather than random other people. Otherwise chaos > >> will ensue. > > > >I didn't know Yaakov is a random person. > > I'll attempt to not follow your lead and respond to this > matter-of-factly rather than hyperbolically: > > In cygwin-apps, we have Marco and Yaakov discussiong cmake packages. > Neither of them is the cmake maintainer. The cmake maintainer isn't > even weighing in, AFAICT. > > In cygwin-developers, we have people discussing dash and perl who are > not the maintainers. There are versions of these programs available > but I don't think the maintainers have had feedback into the packages. > There is also a 64-bit version of binutils, using a different versioning > scheme (a new trend), uploaded by someone who is not the binutils > maintainer.
This is a test release. It's not for the greater public. It's still much too early for that. But we obviously need binutils to be able to build packages natively. These packages are there for testing, not to replace the packages of the original maintainer. Feel free to provide your own packages. > If we're thinking about making something that looks like a release then > I'd like to do the considerate thing and make sure that the people whose > packages you are releasing are ok with what's being done. I, for > example, am not ok with making a version of binutils available which > uses a different versioning scheme. I don't want to have to worry about > that in a future setup.hint file. > > Downloading and extracting tarballs is, IMO, different than making > setup.hint'ed packages available and establishing a new release. If we > make a release I think it should be a beta version of an actual 64-bit > release rather than something that has to be wiped out and restarted > when 64-bit goes live. What exactly speaks against making the life easier of those building and testing packages in this early stage? To run and test the 64bit stuff we need native tools. Most of those native tools exist now in a cygport-built version in the 64bit/release area. We would just like to test and be able to install the packages in a convenient way, nothing else. So, *please*, enable an upset for us working on 64 bit Cygwin, or tell me how to do it myself. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat
