- Arch-dev-public - lists.archlinux.org

[arch-dev-public] FYI: Split gcc/libgcc
by Thomas Bächler 14 Sep '07

14 Sep '07

Aaron is right about communication, so I am posting this here: While splitting the current/base category into core/base and core/devel, it has been decided to split the gcc package into gcc(tools) and libgcc(libs:libstdc++,libgcc_s,...), so that no package will have to depend on gcc in the future, but rather on libgcc. gcc will depend on libgcc, gcc will go to core/devel and libgcc will go to core/base. Jan hopes he can do the split tonight.

4 4

[arch-dev-public] [core] move oragnisation
by Tobias Powalowski 14 Sep '07

14 Sep '07

Hi this thread is intended to organise this move. I will create a dependency list that needs to move in tomorrow afternoon. Would it be possible to meet each other on IRC tomorrow evening, european time? aaron is 7 hours behind germany. Put your ideas here, how to do it smoothly. the easies way to move the stuff in would be to put all in base. including kernel + modules. will cause probably some issues on ftp installs in setup and kernel installation, which can then be solved with new isos eventually. well i think the rest will be clear tomorrow evening. thanks for participating, im too tired for more now. greetings tpowa -- Tobias Powalowski Archlinux Developer & Package Maintainer (tpowa) http://www.archlinux.org tpowa(a)archlinux.org

6 8

[arch-dev-public] Reactive development [was: Repository cleanup]
by Aaron Griffin 14 Sep '07

14 Sep '07

On 9/12/07, Simo Leone <simo(a)archlinux.org> wrote: > What I'm trying to get across here is that some parts of this dev team > have adopted a reactive development model. By this I mean that the > majority of your devel is driven by whatever issues come up, as they > come up. Do you realize why that's bad? > > Typically projects will go through some solid research and plannning to > avoid this situation. I've heard that when the developer has a solid > understanding of the problem, they often develop more generic tools that > have more unforseen uses in the future than when they develop > reactively. This is why, for instance, pacman is so versatile in that it > alone can be used to solve all these problems (like phil said). Gee, > what a great tool. > > Sorry for the slight OT, it's kind of related. Wow. Simo said exactly what I've been feeling for some time now, much more concisely that I even had formulated the thoughts. This is also a very CRITICAL point, and the root of every problem we've had recently. See, ok. Rant-ish time now. I know a lot of you don't do this for a living. You don't work in software. Me? I've been doing this for over 7 years now professionally. Companies large and small, new companies with new technology, old companies with giant 100MHz mainframes, writing code in over 10 different languages. I've written bugs that made people laugh, and bugs that cost a company thousands of dollars. I've been there and done every stupid bad thing you can imagine (update without a where clause on a production DB anyone?) I've been forced to learn how to go about the process here. That's our problem. We have a disparity here between people who don't know common software development practices, and those who do. Those who know these processes expect everyone to implicitly follow them, and those who don't know them think they're silly. Here's the long-and-short of it. When you have cost a company $10000 due to one bad line of code, you learn to appreciate what a one hour code review can do. You learn to appreciate proper communication channels when two people make "hotfixes" to a live DB that break each other. This is what we're lacking. And sadly, it's a word everyone hates. We're missing "process". It is a _fact_ that as groups grow, they need more control. A group of 5 of us could easily coordinate things, but we're well over 25 (Phil said 30? wow!) and at this point we CAN'T keep doing things without proper process. It's just silly. Communication channels must be kept in check. If you do anything that affects the rest of us, then we should know about it before the users do. This includes important module changes (oh crap guys, I broke your X!), changes to initscripts (isatty is missing, btw), new ISO releases (I burned 3 copies of "Don't Panic" 2 days before the new release, for the record), and just... well... anything. Seriously, communication isn't hard. Hell. I know english may be a barrier, but why don't you write in german or something with "Please Translate:" at the top just so we know something is happening. That said, we have always held that the mailing lists are our proper channel of communication. This is important. Hell, it's critical. Saying "hey guess what!" on IRC doesn't cut it. The mailing list not only informs everyone (not all devs are on IRC) but also has archival history. We need to communicate. We need to follow processes. If you find a bug or a user report, and you're unclear about it - **say something**. The great word being flung around these days is "unilateral" - we're not a group of 30 independent people doing their own things, we're a group of 30 people working together. We need to stop reacting and doing our own thing. If something seems questionable, say something. Say "hey guys what do you think about N?". Just bring it up. Not everyone will respond. That's expected. Sometimes you have no opinion, but at least we KNOW what's happening. Guys, seriously. We're floundering. Something needs to be done, and it's not up to one or two of us. It's up to all of us.

5 4

[arch-dev-public] READ ALL:Please hold commits, [core] repository will be setup soon.
by Tobias Powalowski 13 Sep '07

13 Sep '07

Hi as in the earlier thread stated we want to setup our new [core] repository this weekend, for making this possible please don't check in anything to extra/current the next days until we finished this. thanks greetings tpowa -- Tobias Powalowski Archlinux Developer & Package Maintainer (tpowa) http://www.archlinux.org tpowa(a)archlinux.org

1 0

[arch-dev-public] git cheat sheet.
by eliott 13 Sep '07

13 Sep '07

For all you devs out there. Kind of neat. http://zrusin.blogspot.com/2007/09/git-cheat-sheet.html A potentially very useful git cheat sheet. :)

2 2

[arch-dev-public] opencdk, gnutls and libtasn1 in testing
by Jan de Groot 12 Sep '07

12 Sep '07

A few minutes ago I pushed gnutls 2.0.0, OpenCDK 0.6.4 and libtasn 1.1 to testing. Though all of them have a new major version number, only OpenCDK has had a so-bump. It seems that GNUTLS is the only package that depends directly on opencdk, and running lddd.sh on my system shows no possible rebuilds for this upgrade. Please give these libraries some testing, as they're an important part of your system. Report bugs to flyspray so we can rebuild these broken applications.

1 0

[arch-dev-public] Away 9/9-9/15
by Paul Mattal 09 Sep '07

09 Sep '07

I will be on vacation and relatively offline 9/9 through 9/15. Feel free to feed and care for my packages in my absence. I plan to kick mythtv out of testing on my return, and tackle the new version of eclipse and eclipse-cdt. - P

1 0

[arch-dev-public] Xorg dummy package removal
by Travis Willard 07 Sep '07

07 Sep '07

Hi everyone, As recently pointed out in http://bbs.archlinux.org/viewtopic.php?id=37062&p=1 the xorg dummy package has been removed. While this could have been done a bit more elegantly and with warning, it's been done, and I'm post-emptively giving warning now I guess. Anyone maintaining packages with the dependency on 'xorg' please update your packages. Nothing should EVER depend on 'xorg' - use namcap to find out what the true deps to your package are and add them. Some packages in extra, community, and AUR-unsupported probably need fixes. To preserve convenience of installing Xorg, we're considering doing an xorg group between the packages previously pulled by the xorg metapackage. I'll follow up to this email when that's done. Thanks. -- Travis

4 3

[arch-dev-public] Do we like the same books?
by Aaron Griffin 07 Sep '07

07 Sep '07

I just joined Shelfari to connect with other book lovers. Come see the books I love and see if we have any in common. Then pick my next book so I can keep on reading. Click below to join my group of friends on Shelfari! http://www.shelfari.com/Register.aspx?ActivityId=9198203&InvitationCode=a14… Aaron Griffin Shelfari is a free site that lets you share book ratings and reviews with friends and meet people who have similar tastes in books. It also lets you build an online bookshelf, join book clubs, and get good book recommendations from friends. You should check it out. -------- You have received this email because Aaron Griffin (aaronmgriffin(a)gmail.com) directly invited you to join his/her community on Shelfari. It is against Shelfari's policies to invite people who you don't know directly. Follow this link (http://www.shelfari.com/actions/emailoptout.aspx?email=arch-dev-public@arch…) to prevent future invitations to this address. If you believe you do not know this person, you may view (http://www.shelfari.com/phrakture) his/her Shelfari page or report him/her in our feedback (http://www.shelfari.com/Feedback.aspx) section. Shelfari, 616 1st Ave #300, Seattle, WA 98104

1 0

Re: [arch-dev-public] [arch-dev] Package listing color offset update
by Travis Willard 06 Sep '07

06 Sep '07

> > Good idea, but the colour is wrong IMO. Try the background colour from > > the header row. > > Sure. Find me the hex color code and send it to me, and I will make the > change. I think the colour you're looking for is #EEE4CB. -- Travis

1 1