[arch-dev-public] Status Report: 2007-11-05
ArchLinux Status Report, 2007-11-05 =================================== Aaron Griffin (Reviewed by Travis Willard) So, some of you may have noticed there was no Status Report last week. Well, see, I got busy. No one to blame but myself. I _was_ going to get it out on Tuesday, but decided to "roll with it", as it were. So, before we get started, I wanted to get some honest opinions - does doing this every 2 weeks make you guys feel less pestered? One important thing to note: for anyone looking for "something to do", the reason I list a lot of thing here is that I feel we should get them done. If you're looking for things to do, I'd appreciate it if you took a look at this list to see if there's something you can tackle. == Newsworthy Items == * New Logo Competition has begun! The competition for the new Arch logo, spearheaded by Travis, has begun. Full details can be found in this news item: http://archlinux.org/news/359/ * New Newsletter Format Eduardo Romero (kensai) has taken over doing our newsletter, and has changed the format and content. Take a look, and let him know what you think - I, for one, think it's great. Thanks a lot for all the effort Eduardo, and congrats on making a great new new style and layout! == Completed Tasks == * Latest ISO Testing The upcoming 2007.11 ISOs have been in testing for some time now. ftp://ftp.archlinux.org/other/rc-iso/2007.11/ No new show-stoppers have been reported, so I believe we should have new ISOs when Tobias returns from his exams. Yay! * New devtools release This is for all the developers and TUs. We've included a few new features, and two new scripts, in the latest devtools release. Please report any problems or feature requests on the bug tracker. * Xorg 7.3 out of testing Xorg 7.3 has been in testing for about a month now. It's time to move it out there. http://archlinux.org/news/363/ Thanks go out, of course, to Alex for making this happen. * Code projects moved to git All our code projects have officially been moved to our git repos, located at http://projects.archlinux.org/git/ Special thanks to Dan, Simo, and Eliott for carving up CVS and SVN repos to create nice little subsets for specific projects. * cvsup is dead. Long live csup. We've officially replaced cvsup (used by ABS) with csup. There are a handful of reasons, but the biggest one is that cvsup does not compile on x86_64. Thanks to Dan for actually making the move and testing it. * slocate has been replaced by mlocate This has been a long time coming. mlocate is a locate/updatedb implementation that uses a different method of updating the locate database, making it much faster on successive runs. This means your machine isn't going to grind to a halt every night at around midnight, heh. Thanks goes out to James for pushing this one through here, good job. == Pending Tasks, Short Term == * QT4 Move Pierre has proposed a migration plan for moving to QT4. http://archlinux.org/pipermail/arch-dev-public/2007-November/002910.html This appears to be straightforward, so we should get to this soon! Hooray for progress! * Killing off of /opt According to Jan, the last remaining apps we have in /opt (KDE, OpenOffice, and Mozilla/Firefox) can be safely moved out of /opt and into the /usr tree like everything else. Moving binaries and things out of /opt is going to remove a lot of headache we've had in the past. So for anyone who maintains a package that installs to /opt, see if you can get it to install in /usr instead. * Core rebuild Our core rebuild, due to toolchain changes, is currently waiting for testing to empty. For those developers that have packages sitting in testing, please either try to push them up to the real repo, or remove them from testing if they are old. Andy has started cleanup threads for most of these packages. Please check here to see if you own any of these packages: http://archlinux.org/pipermail/arch-dev-public/2007-November/002855.html http://archlinux.org/pipermail/arch-dev-public/2007-November/002856.html * License Updates Travis has created us a _HUGE_ todolist of packages with broken licenses. Please take a look at it and see if you can close out any packages you currently own. http://archlinux.org/todo/43/ Keep in mind that this list contains ONLY packages in the [extra] repo. This means it will not affect the core repo rebuild, but may be affected by the Package Cleanup. * The dividing line: extra and community Another discussion that has gone by the wayside. I'll try to summarize here to see if we can a better idea. The question: when does a package belong in extra? We all agree that we need some sort of "rule" for this. There seems to be two big ideas on how to "answer" this question: a) Split extra into "mantle" and "crust". Mantle contains packages "important to the distro" to be agreed upon by the developers, and crust contains anything else a developer wants to maintain. b) The idea above remains the same, BUT extra is not split at all. The "mantle" packages go to extra, and "crust" packages go to community. So, what do you guys think? Should we vote on these two to get things moving? * Package and Orphan Cleanup Eric has done an amazing job of cleaning up a big wave of packages from extra. All things considered, this is fairly important task, as is affects the "Dividing line" question above, as well as lightening our workload. Eric, what is the next step here - how can we help? * DVD and Additional Package ISO Lists Still not even a peep from people. This is the last time I'm going to include this item on the list. If we don't get any sort of activity or discussion on this, I am going to consider the matter closed. The question: do we want to distribute additional DVDs/CDs full of packages? If so, how do we define what packages are on these things? * Unified chroot build tools The new devtools release has pushed two of these tools out there: mkarchroot, for creating ArchLinux based chroots, and makechrootpkg, for running makepkg inside one of these chroots. Currently, there are a few little bugs floating around, but feel free to report more. The next step is to move to official usage here, so for you developers out there, PLEASE contact me if you have any problems - we should all be building packages in clean chroots to make sure hidden dependencies do not sneak into the packages, and I want to make these tools as easy to use as possible. * DB Scripts Code to git With our SCM backend changing, the DB Scripts rewrite task is no longer a big deal. What we _do need_, however, is our existing code moved out of CVS (and into git, in an ideal world). This way we can use these as examples as we create new scripts for working with our new SCM layout. == Pending Tasks, Long Term == * Perl policy I've moved this one to the long-term section http://bugs.archlinux.org/task/8374 Apparently, perl isn't very widely cared about, so this is mostly all up to me, and we all know my freetime is hard to find these days. So, this is on the "hey this is important" list, but there is no rush. * Getting rid of CVS Last time we visted this, we had two potential implementations. The complexity here has to do with representing one package in many repos at the same time. _This_ is the problem that is solved by CVS tags that we need to redefine elsewhere. Jason gave us an example svn implementation that used the following structure: package-name/ PKGBUILD repos/ core/ testing/ blahblah/ Where each directory under repos/ is a new repository that contains a PKGBUILD and all supplemental files that are routinely "synced" with the master files (in the top level directory). Dan gave us a git implementation that uses a similar structure, but uses git's "lightweight branches" in place of the repos/ directory. This also allows us to create rebuild branches and the like very easily. Here is a usage example: git checkout -b foo_rebuild $EDITOR foo/PKGBUILD $EDITOR pkg1/PKGBUILD $EDITOR pkg2/PKGBUILD git commit -a or git checkout -b testing $EDITOR foobar/PKGBUILD git commit -a The branch names above indicate a new repo, which contain only packages that are changed in the new branch. So, I leave the floor open here - what do you guys think? Which is a better solution? I want to open this up to opinion and vote _real_ soon, as this is something we've talked about for so long it's becoming near mythical. * Pacman 3.1 Release http://bugs.archlinux.org/task/8109 Ah, another stagnating task. We've gotten some great patch contributions from the community, and Dan has been rocking with the pacman changes. We'd love to see more testers out there testing the version from git, and possibly confirming some of the "Requires Testing" bugs on the above, so we can close them out. * Official pacbuild usage We have an official git repo for pacbuild sitting here: http://projects.archlinux.org/git/?p=pacbuild.git;a=summary The news here is small, again. Last I heard, Jason is planning on incorporating the new 'mkarchroot' tool from devtools into pacbuild. Anything else, I am unsure of. Jason, would you mind informing us on what needs to be done to get pacbuild running somewhere? I'd like to do _something_ here before this becomes vaporware. * Modernize our Dashboard Ok, we've made some steps. We now have our web code up here: http://projects.archlinux.org/git/?p=archweb.git;a=summary I plan on filling out the README as far as running your own instance goes.
From there, I'd like people to add any and all dashboard related requests to the "Internal Dev" bug tracker, so we can begin closing them out.
* Architecture Independent Repos Roman has provided us patches for makepkg on the pacman-dev list. That's step one. The next step is to modify our DB scripts to check for the proper suffix, and run itself for both the i686 and x86_64 repos. This one is a rather small change, is anyone interested in doing this? Thomas? * ArchCon 2009: Big Baaad Idea http://archlinux.org/pipermail/arch-dev-public/2007-September/001614.html ArchCon is still floating here at the bottom of the list...but it looks like no one is interested anymore. That's sad. No one wants to come visit lil ol' me?
On Mon, 5 Nov 2007, Aaron Griffin wrote:
ArchLinux Status Report, 2007-11-05 =================================== Aaron Griffin (Reviewed by Travis Willard)
So, some of you may have noticed there was no Status Report last week. Well, see, I got busy. No one to blame but myself. I _was_ going to get it out on Tuesday, but decided to "roll with it", as it were.
So, before we get started, I wanted to get some honest opinions - does doing this every 2 weeks make you guys feel less pestered?
Once per two weeks would be OK. It'll be less work for you and the amount of progress that we do on in a week is not significant enough to necessitate a weekly SR.
* The dividing line: extra and community
Another discussion that has gone by the wayside. I'll try to summarize here to see if we can a better idea.
The question: when does a package belong in extra?
We all agree that we need some sort of "rule" for this. There seems to be two big ideas on how to "answer" this question:
a) Split extra into "mantle" and "crust". Mantle contains packages "important to the distro" to be agreed upon by the developers, and crust contains anything else a developer wants to maintain.
b) The idea above remains the same, BUT extra is not split at all. The "mantle" packages go to extra, and "crust" packages go to community.
So, what do you guys think? Should we vote on these two to get things moving?
Neither a) nor b) answers that question. Option a) simply changes the question "What should go in extra and what should go in community?" to "What should go in mantle and what should go in crust?". We''l ned to define what we maen by important at one point and I see a lot of possible bikeshed painting in getting that definition and in the repo splitup afterward. Option b) is the stau quo. We're simply renaming the repo. Not a big improvement. I might be overlooking something though. BTW, I don't think the names of mantle and crust are appropriate for a general distro like Arch. They would be perfect for a distro targeted to geophysicists or Earth science users though. But that's a minor detail that can be discussed later if we decide to go forward with the renaming/splitup.
* Package and Orphan Cleanup
Eric has done an amazing job of cleaning up a big wave of packages from extra. All things considered, this is fairly important task, as is affects the "Dividing line" question above, as well as lightening our workload.
Eric, what is the next step here - how can we help?
It would be nice if people would take time to go over the orphans to be removed list (https://www.archlinux.org/wiki/Repo%20Cleanup/) and add reason to remove or keep packages or any comment/concerns. There is a lot of packages that I don't know what their use is or wether an alternative exist in the repo. So I won't be able to fill everything out. Depending on how the filling goes, sometime this week, I'll either submit a second sublist on the ML for discussion/revision or submit the rest of removable orphans. Also, as a reminder, there is an important list of orphans that must remain in extra because they are depencies of packages which have a maintainer (2nd large table in wiki). Andy has done a lot of work to figure out what packages depends on these orphans and who are their maintainer. I don't know yet exactly how we'll distribute/assign these orphans as some of you might have already an important workload but ideally everyone should also adopt the orphans that are dependencies of their packages. I encourage you to give a look at that list also. IMPORTANT: If you adopt an orphan or notice that one of these orphans has been adopted, please remove it from the list or let me know so I can remove it. That will remove any unnecessary checking.
== Pending Tasks, Long Term ==
* Perl policy
I've moved this one to the long-term section
http://bugs.archlinux.org/task/8374
Apparently, perl isn't very widely cared about, so this is mostly all up to me, and we all know my freetime is hard to find these days. So, this is on the "hey this is important" list, but there is no rush.
I've done quite a lot of perl related work in community repo so I won't mind helping with that in extra. That'll be after the cleanup though. ;) Eric -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.
2007/11/6, Aaron Griffin <aaronmgriffin@gmail.com>:
ArchLinux Status Report, 2007-11-05
* The dividing line: extra and community
Another discussion that has gone by the wayside. I'll try to summarize here to see if we can a better idea.
The question: when does a package belong in extra?
We all agree that we need some sort of "rule" for this. There seems to be two big ideas on how to "answer" this question:
a) Split extra into "mantle" and "crust". Mantle contains packages "important to the distro" to be agreed upon by the developers, and crust contains anything else a developer wants to maintain.
b) The idea above remains the same, BUT extra is not split at all. The "mantle" packages go to extra, and "crust" packages go to community.
So, what do you guys think? Should we vote on these two to get things moving?
I agree with Eric. I like b) but without renaming. Or another way move Community into Extra and bring TUs as new packagers (we'll get enought people to create teams).
* DVD and Additional Package ISO Lists
Still not even a peep from people. This is the last time I'm going to include this item on the list. If we don't get any sort of activity or discussion on this, I am going to consider the matter closed.
The question: do we want to distribute additional DVDs/CDs full of packages? If so, how do we define what packages are on these things?
My time is very limited this month, but I will try to prepare such list (in fact, a list what we _don't_ want to distribute) next week.
* Unified chroot build tools
The new devtools release has pushed two of these tools out there: mkarchroot, for creating ArchLinux based chroots, and makechrootpkg, for running makepkg inside one of these chroots.
Currently, there are a few little bugs floating around, but feel free to report more.
The next step is to move to official usage here, so for you developers out there, PLEASE contact me if you have any problems - we should all be building packages in clean chroots to make sure hidden dependencies do not sneak into the packages, and I want to make these tools as easy to use as possible.
Besides fixing bugs (the most important of which is that makechrootpkg doesn't work) The very needed feature is the ability to create i686 chroots on x86_64. Could our x86_64 packagers help with this? I'm sure they have some scripts already.
* Getting rid of CVS
Last time we visted this, we had two potential implementations. The complexity here has to do with representing one package in many repos at the same time. _This_ is the problem that is solved by CVS tags that we need to redefine elsewhere.
Jason gave us an example svn implementation that used the following structure:
package-name/ PKGBUILD repos/ core/ testing/ blahblah/
Where each directory under repos/ is a new repository that contains a PKGBUILD and all supplemental files that are routinely "synced" with the master files (in the top level directory).
Dan gave us a git implementation that uses a similar structure, but uses git's "lightweight branches" in place of the repos/ directory. This also allows us to create rebuild branches and the like very easily. Here is a usage example:
git checkout -b foo_rebuild $EDITOR foo/PKGBUILD $EDITOR pkg1/PKGBUILD $EDITOR pkg2/PKGBUILD git commit -a
or
git checkout -b testing $EDITOR foobar/PKGBUILD git commit -a
The branch names above indicate a new repo, which contain only packages that are changed in the new branch.
So, I leave the floor open here - what do you guys think? Which is a better solution? I want to open this up to opinion and vote _real_ soon, as this is something we've talked about for so long it's becoming near mythical.
+1 for jason's SVN proposal. Looks very good to me. -- Roman Kyrylych (Роман Кирилич)
Aaron Griffin wrote:
ArchLinux Status Report, 2007-11-05 =================================== Aaron Griffin (Reviewed by Travis Willard)
So, some of you may have noticed there was no Status Report last week. Well, see, I got busy. No one to blame but myself. I _was_ going to get it out on Tuesday, but decided to "roll with it", as it were.
So, before we get started, I wanted to get some honest opinions - does doing this every 2 weeks make you guys feel less pestered?
After reading Getting Things Done, I actually operate a lot on the week cycle, so I prefer a week. That said, it probably takes you a substantial amount of time to put these together, so I'll take whatever you're willing to do. I find these immensely helpful at keeping items moving. Just in rereading this list in the process of responding, I put two more things on my list to do.
* The dividing line: extra and community
Another discussion that has gone by the wayside. I'll try to summarize here to see if we can a better idea.
The question: when does a package belong in extra?
We all agree that we need some sort of "rule" for this. There seems to be two big ideas on how to "answer" this question:
a) Split extra into "mantle" and "crust". Mantle contains packages "important to the distro" to be agreed upon by the developers, and crust contains anything else a developer wants to maintain.
b) The idea above remains the same, BUT extra is not split at all. The "mantle" packages go to extra, and "crust" packages go to community.
So, what do you guys think? Should we vote on these two to get things moving?
I vote for a), because: 1) I don't think we should make decisions for the TU community. They operate quite well relatively self-sufficiently, and I don't think devs should start putting packages in [community] if they aren't part of that community. 2) It will encourage us to make a choice to commit to some packages as a distro. This is a good thing. I still don't know what packages are okay to put in [extra] and which are not, and I'd like to have a repo I can put any package in that I'm willing to stake my reputation on ([crust]) and later see it voted into fuller support ([mantle]) if there's consensus. - P
On Thu, November 8, 2007 10:12, Paul Mattal wrote:
Aaron Griffin wrote:
ArchLinux Status Report, 2007-11-05 =================================== Aaron Griffin (Reviewed by Travis Willard)
So, some of you may have noticed there was no Status Report last week. Well, see, I got busy. No one to blame but myself. I _was_ going to get it out on Tuesday, but decided to "roll with it", as it were.
So, before we get started, I wanted to get some honest opinions - does doing this every 2 weeks make you guys feel less pestered?
After reading Getting Things Done, I actually operate a lot on the week cycle, so I prefer a week. That said, it probably takes you a substantial amount of time to put these together, so I'll take whatever you're willing to do.
I find these immensely helpful at keeping items moving. Just in rereading this list in the process of responding, I put two more things on my list to do.
* The dividing line: extra and community
Another discussion that has gone by the wayside. I'll try to summarize here to see if we can a better idea.
The question: when does a package belong in extra?
We all agree that we need some sort of "rule" for this. There seems to be two big ideas on how to "answer" this question:
a) Split extra into "mantle" and "crust". Mantle contains packages "important to the distro" to be agreed upon by the developers, and crust contains anything else a developer wants to maintain.
b) The idea above remains the same, BUT extra is not split at all. The "mantle" packages go to extra, and "crust" packages go to community.
So, what do you guys think? Should we vote on these two to get things moving?
I vote for a), because:
1) I don't think we should make decisions for the TU community. They operate quite well relatively self-sufficiently, and I don't think devs should start putting packages in [community] if they aren't part of that community.
2) It will encourage us to make a choice to commit to some packages as a distro. This is a good thing. I still don't know what packages are okay to put in [extra] and which are not, and I'd like to have a repo I can put any package in that I'm willing to stake my reputation on ([crust]) and later see it voted into fuller support ([mantle]) if there's consensus.
I kinda agree. I don't think we need to make any change though. I think the split works well as it is... from my point of view: [extra] - we provide a higher level of 'support' and are typically more important packages than those in [community]. (gnome, soffice, openbox.. more popular things). More support as we have [testing], more integrated developer group, priority on bug tracker, more attention etc. [community] - lesser level of support. _Typically_ less popular/important/more niche (niche packages, special interest, slightly less popular) Exceptions are allowed, as some developers will maintain some "personal" packages in [extra] that may be "better" in [community], as this is more convenient for them. Consider it a perk of being a developer. James
James Rayner wrote:
I vote for a), because:
1) I don't think we should make decisions for the TU community. They operate quite well relatively self-sufficiently, and I don't think devs should start putting packages in [community] if they aren't part of that community.
2) It will encourage us to make a choice to commit to some packages as a distro. This is a good thing. I still don't know what packages are okay to put in [extra] and which are not, and I'd like to have a repo I can put any package in that I'm willing to stake my reputation on ([crust]) and later see it voted into fuller support ([mantle]) if there's consensus.
I kinda agree. I don't think we need to make any change though. I think the split works well as it is... from my point of view:
[extra] - we provide a higher level of 'support' and are typically more important packages than those in [community]. (gnome, soffice, openbox.. more popular things). More support as we have [testing], more integrated developer group, priority on bug tracker, more attention etc.
[community] - lesser level of support. _Typically_ less popular/important/more niche (niche packages, special interest, slightly less popular)
Exceptions are allowed, as some developers will maintain some "personal" packages in [extra] that may be "better" in [community], as this is more convenient for them. Consider it a perk of being a developer.
But you must admit, by doing what you suggest, we aren't doing my #1. We're making decisions about a repo that really doesn't belong to us and risking upsetting the delicate balance between TU and developer communities. Trust me on this one, it's NOT easy to achieve that. I've been through two regimes and a mutiny in TU land. (so have you, I believe!) - P
On Nov 8, 2007 1:52 PM, Paul Mattal <paul@mattal.com> wrote:
James Rayner wrote:
I vote for a), because:
1) I don't think we should make decisions for the TU community. They operate quite well relatively self-sufficiently, and I don't think devs should start putting packages in [community] if they aren't part of that community.
2) It will encourage us to make a choice to commit to some packages as a distro. This is a good thing. I still don't know what packages are okay to put in [extra] and which are not, and I'd like to have a repo I can put any package in that I'm willing to stake my reputation on ([crust]) and later see it voted into fuller support ([mantle]) if there's consensus.
I kinda agree. I don't think we need to make any change though. I think the split works well as it is... from my point of view:
[extra] - we provide a higher level of 'support' and are typically more important packages than those in [community]. (gnome, soffice, openbox.. more popular things). More support as we have [testing], more integrated developer group, priority on bug tracker, more attention etc.
[community] - lesser level of support. _Typically_ less popular/important/more niche (niche packages, special interest, slightly less popular)
Exceptions are allowed, as some developers will maintain some "personal" packages in [extra] that may be "better" in [community], as this is more convenient for them. Consider it a perk of being a developer.
But you must admit, by doing what you suggest, we aren't doing my #1. We're making decisions about a repo that really doesn't belong to us and risking upsetting the delicate balance between TU and developer communities.
Not necessarily. Perhaps we just participate in the community repo as if we were TUs, we don't need to set ourselves up in the "king" roles.
Aaron Griffin wrote:
On Nov 8, 2007 1:52 PM, Paul Mattal <paul@mattal.com> wrote:
James Rayner wrote:
I vote for a), because:
1) I don't think we should make decisions for the TU community. They operate quite well relatively self-sufficiently, and I don't think devs should start putting packages in [community] if they aren't part of that community.
2) It will encourage us to make a choice to commit to some packages as a distro. This is a good thing. I still don't know what packages are okay to put in [extra] and which are not, and I'd like to have a repo I can put any package in that I'm willing to stake my reputation on ([crust]) and later see it voted into fuller support ([mantle]) if there's consensus. I kinda agree. I don't think we need to make any change though. I think the split works well as it is... from my point of view:
[extra] - we provide a higher level of 'support' and are typically more important packages than those in [community]. (gnome, soffice, openbox.. more popular things). More support as we have [testing], more integrated developer group, priority on bug tracker, more attention etc.
[community] - lesser level of support. _Typically_ less popular/important/more niche (niche packages, special interest, slightly less popular)
Exceptions are allowed, as some developers will maintain some "personal" packages in [extra] that may be "better" in [community], as this is more convenient for them. Consider it a perk of being a developer. But you must admit, by doing what you suggest, we aren't doing my #1. We're making decisions about a repo that really doesn't belong to us and risking upsetting the delicate balance between TU and developer communities.
Not necessarily. Perhaps we just participate in the community repo as if we were TUs, we don't need to set ourselves up in the "king" roles.
Okay, but developers wishing to contribute must abide by the rules, then, and be on the mailing list, vote, etc. Keep in mind that we can be removed as TUs at any time, and our access to community revoked, just like any other TU: http://archlinux.org/~simo/TUbylaws.html - P
* The dividing line: extra and community
Another discussion that has gone by the wayside. I'll try to summarize here to see if we can a better idea.
The question: when does a package belong in extra?
We all agree that we need some sort of "rule" for this. There seems to be two big ideas on how to "answer" this question:
a) Split extra into "mantle" and "crust". Mantle contains packages "important to the distro" to be agreed upon by the developers, and crust contains anything else a developer wants to maintain.
b) The idea above remains the same, BUT extra is not split at all. The "mantle" packages go to extra, and "crust" packages go to community.
So, what do you guys think? Should we vote on these two to get things moving?
I vote for a), because:
1) I don't think we should make decisions for the TU community. They operate quite well relatively self-sufficiently, and I don't think devs should start putting packages in [community] if they aren't part of that community.
2) It will encourage us to make a choice to commit to some packages as a distro. This is a good thing. I still don't know what packages are okay to put in [extra] and which are not, and I'd like to have a repo I can put any package in that I'm willing to stake my reputation on ([crust]) and later see it voted into fuller support ([mantle]) if there's consensus.
I kinda agree. I don't think we need to make any change though. I think the split works well as it is... from my point of view:
[extra] - we provide a higher level of 'support' and are typically more important packages than those in [community]. (gnome, soffice, openbox.. more popular things). More support as we have [testing], more integrated developer group, priority on bug tracker, more attention etc.
[community] - lesser level of support. _Typically_ less popular/important/more niche (niche packages, special interest, slightly less popular)
Exceptions are allowed, as some developers will maintain some "personal" packages in [extra] that may be "better" in [community], as this is more convenient for them. Consider it a perk of being a developer.
This nicely encapsulates my feeling on this as well. Thanks!
James
_______________________________________________ arch-dev-public mailing list arch-dev-public@archlinux.org http://archlinux.org/mailman/listinfo/arch-dev-public -- K. Piche <kpiche@rogers.com>
On Mon, 2007-11-05 at 18:51 -0600, Aaron Griffin wrote:
ArchLinux Status Report, 2007-11-05 =================================== Aaron Griffin (Reviewed by Travis Willard)
So, some of you may have noticed there was no Status Report last week. Well, see, I got busy. No one to blame but myself. I _was_ going to get it out on Tuesday, but decided to "roll with it", as it were.
So, before we get started, I wanted to get some honest opinions - does doing this every 2 weeks make you guys feel less pestered?
One important thing to note: for anyone looking for "something to do", the reason I list a lot of thing here is that I feel we should get them done. If you're looking for things to do, I'd appreciate it if you took a look at this list to see if there's something you can tackle.
== Newsworthy Items ==
* New Logo Competition has begun!
The competition for the new Arch logo, spearheaded by Travis, has begun. Full details can be found in this news item:
http://archlinux.org/news/359/
* New Newsletter Format
Eduardo Romero (kensai) has taken over doing our newsletter, and has changed the format and content. Take a look, and let him know what you think - I, for one, think it's great. Thanks a lot for all the effort Eduardo, and congrats on making a great new new style and layout!
== Completed Tasks ==
* Latest ISO Testing
The upcoming 2007.11 ISOs have been in testing for some time now.
ftp://ftp.archlinux.org/other/rc-iso/2007.11/
No new show-stoppers have been reported, so I believe we should have new ISOs when Tobias returns from his exams. Yay!
* New devtools release
This is for all the developers and TUs. We've included a few new features, and two new scripts, in the latest devtools release. Please report any problems or feature requests on the bug tracker.
* Xorg 7.3 out of testing
Xorg 7.3 has been in testing for about a month now. It's time to move it out there.
http://archlinux.org/news/363/
Thanks go out, of course, to Alex for making this happen.
* Code projects moved to git
All our code projects have officially been moved to our git repos, located at
http://projects.archlinux.org/git/
Special thanks to Dan, Simo, and Eliott for carving up CVS and SVN repos to create nice little subsets for specific projects.
* cvsup is dead. Long live csup.
We've officially replaced cvsup (used by ABS) with csup. There are a handful of reasons, but the biggest one is that cvsup does not compile on x86_64.
Thanks to Dan for actually making the move and testing it.
* slocate has been replaced by mlocate
This has been a long time coming. mlocate is a locate/updatedb implementation that uses a different method of updating the locate database, making it much faster on successive runs. This means your machine isn't going to grind to a halt every night at around midnight, heh.
Thanks goes out to James for pushing this one through here, good job.
== Pending Tasks, Short Term ==
* QT4 Move
Pierre has proposed a migration plan for moving to QT4.
http://archlinux.org/pipermail/arch-dev-public/2007-November/002910.html
This appears to be straightforward, so we should get to this soon! Hooray for progress!
* Killing off of /opt
According to Jan, the last remaining apps we have in /opt (KDE, OpenOffice, and Mozilla/Firefox) can be safely moved out of /opt and into the /usr tree like everything else.
Moving binaries and things out of /opt is going to remove a lot of headache we've had in the past. So for anyone who maintains a package that installs to /opt, see if you can get it to install in /usr instead.
* Core rebuild
Our core rebuild, due to toolchain changes, is currently waiting for testing to empty. For those developers that have packages sitting in testing, please either try to push them up to the real repo, or remove them from testing if they are old.
Andy has started cleanup threads for most of these packages. Please check here to see if you own any of these packages:
http://archlinux.org/pipermail/arch-dev-public/2007-November/002855.html http://archlinux.org/pipermail/arch-dev-public/2007-November/002856.html
* License Updates
Travis has created us a _HUGE_ todolist of packages with broken licenses. Please take a look at it and see if you can close out any packages you currently own.
Keep in mind that this list contains ONLY packages in the [extra] repo. This means it will not affect the core repo rebuild, but may be affected by the Package Cleanup.
* The dividing line: extra and community
Another discussion that has gone by the wayside. I'll try to summarize here to see if we can a better idea.
The question: when does a package belong in extra?
We all agree that we need some sort of "rule" for this. There seems to be two big ideas on how to "answer" this question:
a) Split extra into "mantle" and "crust". Mantle contains packages "important to the distro" to be agreed upon by the developers, and crust contains anything else a developer wants to maintain.
b) The idea above remains the same, BUT extra is not split at all. The "mantle" packages go to extra, and "crust" packages go to community.
So, what do you guys think? Should we vote on these two to get things moving?
* Package and Orphan Cleanup
Eric has done an amazing job of cleaning up a big wave of packages from extra. All things considered, this is fairly important task, as is affects the "Dividing line" question above, as well as lightening our workload.
Eric, what is the next step here - how can we help?
* DVD and Additional Package ISO Lists
Still not even a peep from people. This is the last time I'm going to include this item on the list. If we don't get any sort of activity or discussion on this, I am going to consider the matter closed.
The question: do we want to distribute additional DVDs/CDs full of packages? If so, how do we define what packages are on these things?
* Unified chroot build tools
The new devtools release has pushed two of these tools out there: mkarchroot, for creating ArchLinux based chroots, and makechrootpkg, for running makepkg inside one of these chroots.
Currently, there are a few little bugs floating around, but feel free to report more.
The next step is to move to official usage here, so for you developers out there, PLEASE contact me if you have any problems - we should all be building packages in clean chroots to make sure hidden dependencies do not sneak into the packages, and I want to make these tools as easy to use as possible.
* DB Scripts Code to git
With our SCM backend changing, the DB Scripts rewrite task is no longer a big deal. What we _do need_, however, is our existing code moved out of CVS (and into git, in an ideal world). This way we can use these as examples as we create new scripts for working with our new SCM layout.
== Pending Tasks, Long Term ==
* Perl policy
I've moved this one to the long-term section
http://bugs.archlinux.org/task/8374
Apparently, perl isn't very widely cared about, so this is mostly all up to me, and we all know my freetime is hard to find these days. So, this is on the "hey this is important" list, but there is no rush.
I mentioned that I was working on it :) and I'm pretty much done the perl package. I have three different versions of Sys:Syslog: the one included with perl, a separate pkg for testing, and a manual CPAN one. They co-exist nicely. Thanks to Charles Mauch for the initial footwork. I didn't include one patch (enc2xs) since I didn't really know what it was for but I'm sure it'll come up in testing. Older perl pkgs such as Zim still work fine. I'm waiting for perl 5.8.8-9 to go out before I put it in testing. Then the remaining packages can be converted to go in vendor dirs.
* Getting rid of CVS
Last time we visted this, we had two potential implementations. The complexity here has to do with representing one package in many repos at the same time. _This_ is the problem that is solved by CVS tags that we need to redefine elsewhere.
Jason gave us an example svn implementation that used the following structure:
package-name/ PKGBUILD repos/ core/ testing/ blahblah/
Where each directory under repos/ is a new repository that contains a PKGBUILD and all supplemental files that are routinely "synced" with the master files (in the top level directory).
Dan gave us a git implementation that uses a similar structure, but uses git's "lightweight branches" in place of the repos/ directory. This also allows us to create rebuild branches and the like very easily. Here is a usage example:
git checkout -b foo_rebuild $EDITOR foo/PKGBUILD $EDITOR pkg1/PKGBUILD $EDITOR pkg2/PKGBUILD git commit -a
or
git checkout -b testing $EDITOR foobar/PKGBUILD git commit -a
The branch names above indicate a new repo, which contain only packages that are changed in the new branch.
So, I leave the floor open here - what do you guys think? Which is a better solution? I want to open this up to opinion and vote _real_ soon, as this is something we've talked about for so long it's becoming near mythical.
* Pacman 3.1 Release
http://bugs.archlinux.org/task/8109
Ah, another stagnating task. We've gotten some great patch contributions from the community, and Dan has been rocking with the pacman changes.
We'd love to see more testers out there testing the version from git, and possibly confirming some of the "Requires Testing" bugs on the above, so we can close them out.
* Official pacbuild usage
We have an official git repo for pacbuild sitting here: http://projects.archlinux.org/git/?p=pacbuild.git;a=summary
The news here is small, again. Last I heard, Jason is planning on incorporating the new 'mkarchroot' tool from devtools into pacbuild. Anything else, I am unsure of.
Jason, would you mind informing us on what needs to be done to get pacbuild running somewhere? I'd like to do _something_ here before this becomes vaporware.
* Modernize our Dashboard
Ok, we've made some steps. We now have our web code up here: http://projects.archlinux.org/git/?p=archweb.git;a=summary
I plan on filling out the README as far as running your own instance goes.
From there, I'd like people to add any and all dashboard related requests to the "Internal Dev" bug tracker, so we can begin closing them out.
* Architecture Independent Repos
Roman has provided us patches for makepkg on the pacman-dev list. That's step one. The next step is to modify our DB scripts to check for the proper suffix, and run itself for both the i686 and x86_64 repos.
This one is a rather small change, is anyone interested in doing this? Thomas?
* ArchCon 2009: Big Baaad Idea
http://archlinux.org/pipermail/arch-dev-public/2007-September/001614.html
ArchCon is still floating here at the bottom of the list...but it looks like no one is interested anymore. That's sad. No one wants to come visit lil ol' me?
_______________________________________________ arch-dev-public mailing list arch-dev-public@archlinux.org http://archlinux.org/mailman/listinfo/arch-dev-public -- K. Piche <kpiche@rogers.com>
participants (6)
-
Aaron Griffin
-
Eric Belanger
-
James Rayner
-
K. Piche
-
Paul Mattal
-
Roman Kyrylych