FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > ArchLinux > ArchLinux Development

 
 
LinkBack Thread Tools
 
Old 11-20-2007, 07:05 PM
"Aaron Griffin"
 
Default [arch-dev-public] Status Report 2007-11-20

ArchLinux Status Report, 2007-11-20
===================================
Aaron Griffin (Reviewed by Eliott)

Another couple of weeks, another status report. Things have been calm around
here, oddly enough. A lot of us are getting ready for the holidays, or exams, or
both. Me? I'm just really busy with work these days.

I want to let everyone know that you are always welcome to contact me over
jabber or email for any questions or concerns. I seem to be getting a few emails
recently with lines such as "sorry for emailing you" - I like email. Emails are
fun. So don't be afraid


== Newsworthy Items ==

* New Logo Competition Voting

All the submissions for the Logo Competition are in, and the developers are
currently voting. Hold on to your seats, the final verdict will be incoming
soon.

http://bbs.archlinux.org/viewtopic.php?pid=298688

* Simo takes over AUR development

Paul has taken a step back from being the lead on the AUR project, and Simo is
taking his place. In Paul's own words:

Thanks to all of you for making the AUR come alive over the last few
years! It's been exciting to watch our creation really brought to life
by this vibrant community. I'm excited about beginning a new chapter
with Simo at the helm!

* Bug Tracker open for [community] packages

In the past, we've not allowed bug tracker items for community packages because
it was difficult to manage the bugs.
Now, we've created a section in our bug tracker for community package issues.

http://archlinux.org/news/364/

== Completed Tasks ==

* Xorg 7.3 Brouhaha

This update seems to have caused quite a ruckus among the users. For some people
it worked fine, but others ended up with broken systems.

Sadly, this is somewhat expected on large upgrades like this. I remember a day
when we had breakages like this all the time. Arch has been running so smoothly
recently that most people forget that software actually does break.

http://archlinux.org/news/363/

* Package Cleanup

An extraordinary amount of thanks goes to Eric here. This is a thankless job,
but he has done the legwork and cleaned up a large amount of packages from
extra. This makes everyone's job easier, and our repos cleaner.

There's still more to come, so stay tuned:

http://archlinux.org/pipermail/arch-dev-public/2007-November/003154.html

* [core] repo rebuild

Daniel did a huge amount of work here, rebuilding all of our core packages for
the new gcc/glibc toolchain. This is a common rebuild that a lot of distros do,
yet we typically do not do it that often.

So hats-off to Daniel for doing the rebuild and package move, and special thanks
to Tobias (tpowa), Andreas, Roman, and anyone else I missed for doing the
cleanup work that enabled Daniel to do this.

* New netcfg scripts in [testing]

James has spent some time revamping our network profile support, and generally
cleaning up our network scripts. His changes have been moved to testing now.

Please try them out if you get a chance.
http://archlinux.org/news/362/

* QT4 Move to [testing]

Pierre and others have begun the move to Qt 4 based packages. This includes
backwards compatible support for Qt 3 (in the form of a package named qt3).

These packages should all be moved to testing now. Please try them out and
report any problems you come across.

http://archlinux.org/pipermail/arch-dev-public/2007-November/003242.html.

* GPL License naming

Just so we don't bollocks this up, the following naming scheme will be using for
GPL licenses in PKGBUILDs:

GPL means GPL2 or later
GPL2 means GPL2
GPL3 means GPL3 or later

Note: We have no GPL1 packages, and I doubt anyone could actually find one.

== Pending Tasks, Short Term ==

* Getting rid of /opt

Revisiting this from last time. It looks like we have a lot of packages which
can move out of /opt when we have the time.

The first step is to create a todolist in the dashboard for all packages which
currently install to /opt. Would anyone be willing to create this list?

* License Updates

We still have a large TODO list sitting here, of packages that have broken
licenses. Please take a look at these while packaging, to ensure we have
licenses setup properly.

http://archlinux.org/todo/43/

* ABS Redux

This is actually a multi-part task here. The first part, involves replacing the
cvs dependence in ABS with rsync.

http://archlinux.org/pipermail/arch-dev-public/2007-November/003224.html

This change will allow abs to be independent of the SCM backend we use, and
perhaps more efficient in the long run. I think Dan and Eliott have done some
work here in this regard.

Step 2 is actually breaking abs out from the pacman package, as it's very
ArchLinux specific, and pacman/makepkg are not. This can, and should, most
likely be done around the same time as the pacman 3.1 release (see below).

* The dividing line: extra and community

Ah, waning discussion is always fun. I've tried to revitalize this a few times,
but it seems discussion feel short.

So here's a fun little ultimatum for ya:

Since no one seems to care about this topic anymore, if we don't get a vote, or
at least continued discussion here, I'm going to have to make an "executive
decision". That decision will be as follows:

* Packages in [extra] define us as a distro and should not include packages for
personal use. If something is personal and/or only used by small amounts of
people, it should go to community. Not only does this help us with our vision,
it also helps out our mirrors (not all mirrors mirror the community repo).
* People should inform everyone if they're putting a new package into extra,
just in case someone has an issue with it, to prevent silly bloat from too
many personal packages. If someone has a problem with a package going into
extra, a simple vote should suffice (no need to discuss it to death)

The other reigning idea seems to be Damir's idea of the mantle/crust repos. That
is, the same idea as above, except there is another repo in between extra and
community that serves as the developers' dumping grounds for these packages.

So, take a look at your options, and decide what feels best to you - I'd like to
close this task out soon, as there's no real work here - only process.

* Unified chroot build tools

The chroot tools I've put in devtools have gotten little response. Jason has
made some changes, and Roman has provided some patches, if I remember correctly.

I'd like to get more input here, suggestions of things like using linux32 and
dchroot are great (both suggested by Thomas). So feel free to bring it up.

* Getting rid of CVS

Yep, this is moving up the chain from long-term to short-term. Before the next
status report (2 weeks from now) I want to at least begin this task.

In order to do this, we need to first make a decision on where we want to go.
The root of the decision here is how we represent a given package being in
multiple repos at one time.

* Jason has provided us with an svn solution, where sub-directories control
the location of the package (i.e. package-name/repos/extra/PKGBUILD will
place the package into extra)
* Dan has provided us with a git solution that uses named branches to control
the location (i.e. a branch named "testing" has changes to PKGBUILDs
present only in the testing repo)

Both of the solutions above solve the issue. The real question is - what tool do
YOU want to use?


== Pending Tasks, Long Term ==

* Perl policy implementation

Looks like some perl progress has been made. As said last time, there's not a
HUGE amount of perl hubbub on Arch, so this isn't critical. It's important,
sure, so lets keep this one in mind.

http://bugs.archlinux.org/task/8374

* Pacman 3.1 Release

Dan has been doing some amazing work closing out a lot of bugs for this release.
In addition, he has a public repository which contains recent builds of pacman
from git, that should help in testing in debugging. If you feel like helping out
with testing, please use Dan's repo to install 'pacman-git'.

More info here:
http://archlinux.org/pipermail/pacman-dev/2007-November/009825.html

Pending bugs for the release are listed here:
http://bugs.archlinux.org/task/8109

* Official pacbuild usage

Another pipe-dreamy project. I'm not even sure of the state here anymore - Simo,
Jason, any news?

* Modernize our Dashboard

Eliott has been pushing out some very nice changes to our web interface, so
thanks goes out to him. For some of this stuff.
I'd, of course, love to see more web-dev type people working on this. Take a
look at our gitweb:
http://projects.archlinux.org/git/?p=archweb.git;a=summary

At some point, I want to add README text with information on how to run a local
instance.

* Architecture Independent Repos

As stated last time, Roman sent us a patch for pacman 3.1 to incorporate the
no-arch packages. This means that when the 3.1 release comes out, we should be
ready to go here.

So here's your deadline: let's try and get support into our DB scripts before
the pacman 3.1 release. Who's interested?

http://bugs.archlinux.org/task/8555

This one is a rather small change, is anyone interested in doing this? Thomas?

* ArchCon 2009: Big Baaad Idea

/me winks

http://archlinux.org/pipermail/arch-dev-public/2007-September/001614.html

_______________________________________________
arch-dev-public mailing list
arch-dev-public@archlinux.org
http://archlinux.org/mailman/listinfo/arch-dev-public
 
Old 11-22-2007, 04:05 PM
Eric Belanger
 
Default [arch-dev-public] Status Report 2007-11-20

On Tue, 20 Nov 2007, Aaron Griffin wrote:

> * Package Cleanup
>
> An extraordinary amount of thanks goes to Eric here. This is a thankless job,
> but he has done the legwork and cleaned up a large amount of packages from
> extra. This makes everyone's job easier, and our repos cleaner.
>
> There's still more to come, so stay tuned:
>
> http://archlinux.org/pipermail/arch-dev-public/2007-November/003154.html
>

There are still several packages on the second list I posted that have
questions marks on them. I would like to get some more input on them.
Also, if you went through the list but can't really comment on the package
we're unsure about, let us know about that. At least, I'll know that
several other persons have checked the list and agreed on the packages
that can be removed. I'll give a few more days for discussion as the
routing problem has hampered some of us. On Sunday night, to get things
going, I plan on removing some of these packages. Depending on the
new input, I'll be more or less conservative so
it'll be mostly unused libs, broken/dead project, the 'yet another.. '
desktop apps, etc. I could post a list of what I have in mind if you want.

Another task ahead that you didn't mentionned is the orphans that must
remains in extra because they are (make)depends of others maintained
packages. In the wiki, the cleanup page
https://www.archlinux.org/wiki/Repo%20Cleanup/ has a second table that
list them. It also list the packages that depends on them and in some
cases who are the maintainer of these packages. It was pointed out in
another thread that it would be nice and logical if maintainers of
packages that depends on orphans would adopt these orphans. To help in
spreadind out the workload, it would also be nice if devs, who can add a
few package to their workload, adopt some of these orphans even if their
packages don't explicitely depends on them. Most likely, several of us use
packages that depends on these orphans. I plan to do that on my part.
Also, there are still a few core orphans.
PS - I you adopt orphans please remove them from the list.

A bug tracker cleanup should also be done. Several packges have changed
hands so the bugs have to be reassigned to the new maintainer. Unassigned
bugs for ex-orphans should be assigned to the new maintainer too. Bugs for
packages that were removed should be closed and the link to the bug report
posted in AUR so the new/future maintainer knows about these issues. I
guess Roman is the one who will inherit this task but we should help him
by going through our assigned task list and clean it up.



>
> * The dividing line: extra and community
>
> Ah, waning discussion is always fun. I've tried to revitalize this a few times,
> but it seems discussion feel short.
>
> So here's a fun little ultimatum for ya:
>
> Since no one seems to care about this topic anymore, if we don't get a vote, or
> at least continued discussion here, I'm going to have to make an "executive
> decision". That decision will be as follows:
>
> * Packages in [extra] define us as a distro and should not include packages for
> personal use. If something is personal and/or only used by small amounts of
> people, it should go to community. Not only does this help us with our vision,
> it also helps out our mirrors (not all mirrors mirror the community repo).
> * People should inform everyone if they're putting a new package into extra,
> just in case someone has an issue with it, to prevent silly bloat from too
> many personal packages. If someone has a problem with a package going into
> extra, a simple vote should suffice (no need to discuss it to death)

+1 from me. I assume that there is no exceptions. For example, if a
packages has to be added because it's a new dependency of a package
already in extra, permission to add it should still be asked on the ML.
What about the case where a new package replace an old one, like the
fglrx-> catalyst switch? I would say permission should still be asked
because it gets us informed about such changes and it's trivial so noone
will object.


> * Unified chroot build tools
>
> The chroot tools I've put in devtools have gotten little response. Jason has
> made some changes, and Roman has provided some patches, if I remember correctly.
>
> I'd like to get more input here, suggestions of things like using linux32 and
> dchroot are great (both suggested by Thomas). So feel free to bring it up.
>

It would be nice to have a little how-to. I'm currently in the process of
setting up clean chroot for both current and testing (plus i686 chroot on
x86_64) but I don't really know if it is just a question of using the 2
tools in devtools with the correct options or if they need to be used in a
script. If someone could write an how-to with examples of scripts that
are being used, it would make the use of these tools more appealling.


Eric

--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.


_______________________________________________
arch-dev-public mailing list
arch-dev-public@archlinux.org
http://archlinux.org/mailman/listinfo/arch-dev-public
 

Thread Tools




All times are GMT. The time now is 07:24 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org