Re: [aur-general] AUR Release 1.5.0
On Tue, Feb 19, 2008 at 08:00:42AM -0800, Thayer Williams wrote:
On Feb 19, 2008 5:49 AM PST, Roman Kyrylych <roman.kyrylych@gmail.com> wrote:
2008/2/19, Bjørn Lindeijer <bjorn@lindeijer.nl>:
On 2/19/08, Simo Leone <simo@archlinux.org> wrote:
This is a really big release, and I do mean big. This release brings a json interface, the brand new arch look, a tu voting back-end, tons of changes under the hood, and the removal of safe flags, among tons of other changes. See the shortlog for the nitty gritty.
Enjoy -S
One small nitpick about the new theme. Did anybody notice that the AUR is using a slightly fancier logo image than the one in the header used by the main website and the bug tracker? I prefer it, but somebody should make sure the same image is used everywhere.
Hah, nice catch! And on DistroWatch we have yet another logo (with colors from older version). I'm cc'ing this to Thayer.
-- Roman Kyrylych (Роман Кирилич)
Thanks for the heads up guys! Unfortunately, I don't have any write access to the web server, which makes my job a bit trickier. I've CC'd Eliott and Simo on this.
Eliott and I discussed the logo use and agreed that the "fancier" version is better suited for desktop use (Crystal icons, wallpapers, etc.)
As for the DistroWatch logo, I don't know who submitted that one. I also see we're using a 2nd-rate version of the kernel framebuffer logo too.
Ok well I replaced the AUR one with the one used on the rest of the sites (the non-fancy one). It's in my working tree which means it'll probably get pushed later this week or next weekend. Also, we should get thayer set up with something or other one of these days. -S
On Feb 19, 2008 6:15 PM, Simo Leone <simo@archlinux.org> wrote:
Also, we should get thayer set up with something or other one of these days.
As I said before, because we are using git, it is actually much more beneficial to have one person with the "reins" to push things out. Most companies work this way - they have a team of "release engineers" (or some other nonsense title) that pull things from a staging box that developers have access to to the production box. Because we only have one production box, it'd be nice if we could not actually treat it as if it were staging - that's how we break things
On Tue, Feb 19, 2008 at 7:42 PM, Aaron Griffin <aaronmgriffin@gmail.com> wrote:
As I said before, because we are using git, it is actually much more beneficial to have one person with the "reins" to push things out. Most companies work this way - they have a team of "release engineers" (or some other nonsense title) that pull things from a staging box that developers have access to to the production box. Because we only have one production box, it'd be nice if we could not actually treat it as if it were staging - that's how we break things
That may be true in a big company with lots of developers or a community with a lot of contributors, but I think with a small number of developers it would probably be more beneficial for them to have commit access to help keep development rolling. At least there's a smaller risk of breaking things when a few have their hands on the same box rather than many hands on the same box.
participants (3)
-
Aaron Griffin
-
Loui
-
Simo Leone