Re: Linux Downloads page change
От | Magnus Hagander |
---|---|
Тема | Re: Linux Downloads page change |
Дата | |
Msg-id | CABUevEzNBPAqtFh=Mp+F-gn-3GHmKeuJOQY=28ubHUfMkQ51tA@mail.gmail.com обсуждение исходный текст |
Ответ на | Linux Downloads page change (Scott Mead <scottm@openscg.com>) |
Список | pgsql-www |
Pah, got denied-post on -www for that email due to it being too large. Sorry about that - repost, with a link instead - the referenced image can be found at http://www.hagander.net/tmp/s_2012-07-09-01-3c6e87.png. //Magnus On Mon, Jul 9, 2012 at 11:30 AM, Magnus Hagander <magnus@hagander.net> wrote: > On Mon, Jul 9, 2012 at 11:09 AM, Dave Page <dpage@pgadmin.org> wrote: >> On Mon, Jul 9, 2012 at 9:42 AM, Magnus Hagander <magnus@hagander.net> wrote: >>> On Mon, Jul 9, 2012 at 10:31 AM, Dave Page <dpage@pgadmin.org> wrote: >>>> On Sun, Jul 8, 2012 at 9:56 PM, Devrim GÜNDÜZ <devrim@gunduz.org> wrote: >>>>> On Sat, 2012-07-07 at 23:05 -0400, Scott Mead wrote: >>>>>> >>>>>> > That reminds me... Why do we give link to some binary RPMs, where >>>>>> SRPMs >>>>>> > are not available? >>>>>> >>>>>> Those RPMs are built using the certified binaries that the community >>>>>> distributes already, but simplifies installation in deeply >>>>>> firewalled / headless server environments. They also allow for >>>>>> side-by-side installs of major versions ( pg_upgrade compatible ) and >>>>>> have since their inception. >>>>> >>>>> That is not an answer to my question. Why don't you distribute the SRPM? >>>>> How can someone make sure that the RPMs do not include some more extra >>>>> code? >>>> >>>> I assume the SRPM isn't provided because the binaries that are >>>> packaged are actually the ones that EDB build (and I wouldn't be >>>> surprised if they're generated with BitRock InstallBuilder, so there >>>> wouldn't be an SRPM anyway). >>> >>> BitRock can generate RPMs these days? Neat! >> >> It's been able to do RPMs and DEBs as long as I've been using it. I >> tried generating them from our builds, but there's too much >> interactivity at different points in the installers, and neither the >> RPM or DEB formats can handle it. > > Cool. I had no idea :) But yah, particularly the RPMs are pretty picky > about interactivity (for good reasons from their perspective, of > course, but nevertheless quite picky) > > >>>> That aside though, the code must be 100% open source to be listed on >>>> those download pages; Scottie, where can people find the spec files, >>>> BitRock XML files or whatever? >>> >>> While I agree with that requirement in general, we should apply it >>> fairly. AFAICT the latest release of the EDB installers that had >>> sourcecode with it was 9.0.2 - I have a hard time seeing that nothing >>> would've changed since... None of the changes that have been discussed >>> on the lists here in the past couple of months are anywhere to be >>> seen.. So should we remove the EDB installers from the page as well? >> >> The EDB installers are open source, and have been since they were >> first published. You can get the code for all branches from >> http://git.postgresql.org/gitweb/?p=edb-installers.git;a=summary, and >> that includes not just the installer files, but the entire build >> framework. The most recent commit is to the 9.2 branch, from Friday. > > Attached is a screenshot showing what this page looked like when I > sent that email. So someone pushed all those changes *after* I sent > that email, in what looks like an attempt to dispute that statement. > While we don't have log extracts showing the exact times (should > probably fix that in the pggit code), there is certainly a push shown > around 9AM UTC this morning... (and it shows that between this push > and the previous *of any activity at all* on that repository, there > have been another 5189 operations on git.postgresql.org - around 3500 > pushes, though that includes pushes from the mirror of the main > postgresql git repo, so it's a little bit inflated. but it pretty > clearly matches up to the "no activity in 18 months" that the web > interface showed) > > I know they're *intended* to be opensource. But the normal status is > they're lagging behind a year or more, so I'm not sure I consider it > open... My experience shows that whenever I'm looking for something, > it's not up to date, and it's only pushed when I point it out. It may > well be that it's pushed at other times as wel of course - but you > can't really claim it's pushed regularly. > >> I'm not sure why you would think I'd push for a different rule for >> OpenSCG than EDB - I've always made a point of trying to apply the >> same standards to all our corporate contributors - as a core team >> member and a senior member of staff at EDB not only is it the right >> thing to do, but it's the only way I can function in both roles. I'm a >> little offended that you would suggest otherwise. > > I normally wouldn't think you would, but it certainly sounded like > that, given exactly what that repository looked like this morning - > and has looked like pretty much every time I've looked at it recently. > Which was "the installers were once dumped as opensource to make it > look good, but we don't really care about them being open". > > And frankly, I'm a little offended by whomever made that push into the > repository to dispute my statement, without claiming responsibility > for doing so. To me, it's rather obvious it was done as a direct > response to my email. Given the perfect timing. Whoever did it. > > So what *is* the intended policy for that repo? It's clearly not the > primary repo for the edb installers but just a mirror. Which has > received a total of 50 pushes *since the creation of the new > git.postgresql.org*, years ago. So it's clearly not mirrored in > anything near real time. So when *does* it get pushed, aside from when > somebody complains? > > -- > Magnus Hagander > Me: http://www.hagander.net/ > Work: http://www.redpill-linpro.com/
В списке pgsql-www по дате отправления: