[arch-dev-public] Status Report 2007-11-20

[Eric Belanger]

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.