[gentoo-dev] Project summaries

[gentoo-dev] Project summaries

[Christian Faulhammer]

[-- Attachment #1: Type: text/plain, Size: 1959 bytes --]

Hi,

any project lead/member can post an answer to this mail for a status
report:

Gentoo Lisp in general:
We are working on all our problems, but some sub-projects are a bit
understaffed (e.g. Common Lisp, because pchrist is away for a year),
while Scheme is in good shape but has only one active developer at the
moment.  We get along, but help is always needed.  All our overlays
are well maintained and an active playground whose changes make it into
the tree eventually.  Project members can tell more about their field,
I guess.
http://www.gentoo.org/proj/en/lisp/index.xml

Gentoo GNU Emacs:
We are two people (ulm and myself), which handle the low bug load.  In
the last two years we revamped the tree and created some interesting
things for Emacs users and eased our development work.  We are mostly
in maintenance-mode because our plans are done in general:

* A developer guide how to maintain GNU Emacs and packages
* Documentation of the eclasses
* Eselect module to use one of the up to four GNU Emacs versions
  installed in parallel
* app-emacs/gentoo-syntax for ebuild writers
* small tools (emacs-updater) to ease use of Emacs
* Push a policy on packages that is flexible and easy to use
* Create test plans for packages, so architecture teams know how to
  test the package (some are still missing)
* Keyword (x86 and amd64 are mandatory) and stabilisation

We still miss:
* A user-guide, where a draft from a user is available, but needs some
  polishing.
* ulm can tell more
http://www.gentoo.org/proj/en/lisp/emacs/index.xml

XEmacs:
graaff is the lone wolf here and because upstream development of XEmacs
is not really on fire, he has not too much to do, I think.  He
introduced eclasses in a similar way as the GNU Emacs team.

V-Li

-- 
Christian Faulhammer, Gentoo Lisp project
<URL:http://www.gentoo.org/proj/en/lisp/>, #gentoo-lisp on FreeNode

<URL:http://gentoo.faulhammer.org/>

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] Project summaries - Alpha Arch Team

[Tobias Klausmann]

Hi! 

So where are we at with alpha currently?

Xorg-1.5
--------
As some of you know, xorg-1.5 abandoned the "classic" way of
interfacing with PCI and AGP cards in favor of using
libpciaccess. That, in turn expects support from the kernel in
the form of /sys/devices/<bus>/<id>/<func>/resourceN files. 

Unfortunately, alpha until recently hat no support for those PCI
resources (which is partly due to the way alpha IO space is
structured and partly due to a crucial extension not being
available on old Alphas (older than EV5). 

As such, we weren't able to keyword or stabilize Xorg-1.5 until
recently, when 2.6.30-rc* saw support finally being added.
Naturally, packages depending on >=xorg-1.5 had to be held off,
too. 

The -rc kernels are keyworded ~alpha so people can test. So far,
-rc3 and rc4 are looking good, so we will keyword xorg and deps
soon (I'm aiming for this weekend) and if all goes well, we will
have it stable, soon.

Note that this will mean that people with EV4-Alphas will *not*
be able to use Xorg-1.5 just now. I feel that those machines are
so slow that very few will run X11 anyway, if there are Gentoo
installations on those to start with.

Glibc/Toolchain
---------------

Glibc has had a bug for ages (regarding ceil() and friends, bug
number 264335) which should really be fixed. Upstream is umm..
their usual selves about it. On top, a patch for fdatasync() (bug
264336) is available which upstream... well, you get it.

Workload
--------

Currently, the alpha arch team consists of me (the nominal lead)
and armin76 who helps a lot with getting stable request answered
in a timely manner. 

Also, we're in the process of recruiting mattst88 as an arch
tester. He's currently deep in exam-land at university, so the
process is on hold for now. 

Users/Community
---------------

Aside from those on the team and one or two other devs, I've had
little to no direct feedback from Gentoo alpha users. I try to
write about Alpha regularly on my blog (available on the planet)
and I'm easily reachable as Blackb|rd on Freenode (#gentoo-alpha,
naturally). 

I've been toying with the idea of offering something akin to
Debians popularity contest tool. Some people are rather
uncomfortable with data gathering tools that send stuff to some
strangers, so I don't know how well it would work. I list this
idea here, since I have just about no idea what actual alpha
hardware is used with Gentoo out there. Knowing which packages
are actually *used* (instead of just being stabilized for the
heck of it) would be nice. Added benefit of that would be that
users helping with testing would reduce workload. 



In essence: we're busy and I'd love to get more feedback what
people (both users and devs) think we could do better, or
more/less of. 

Regards,
Tobias,
who turned 42 in octal today


-- 
The only problem with troubleshooting is that sometimes,
trouble shoots back.

Re: [gentoo-dev] Project summaries

[Peter Alfredsen]

On Wed, 6 May 2009 08:49:53 +0200
Christian Faulhammer <fauli@gentoo.org> wrote:

> Hi,
> 
> any project lead/member can post an answer to this mail for a status
> report:

Gentoo .NET progress

Currently doing good. Nothing much to report. Everything is shiny
and well-oiled. SVN ebuilds of trunk and branches were recently 
committed to the main tree, which will help when people report bugs.
Generally trying to maintain as little distance between the main tree
and the overlay as possible, so user feedback can be utilized most
efficiently. ~arch is really the testing branch for Mono packages, IOW,
but I try to fix bugs real quick when they're reported so most of you
never notice they were there.

Cool new apps which everyone should be using:

Tasque		for managing your everyday scheduling needs.
Monsoon		shiny bittorrent client
Bareftp		easy and accessible ftp client

Cool old apps which everyone should be using:
Tomboy		notetaking application
Banshee		the best media-player out there
Beagle		desktop search
Gnome-Do	LOOK! SHINY!

And of course mod_mono, for your ASP.NET needs.

What we need:
People who care about portable.NET enough to make it great.
People who use the ASP.NET features. I can probably debug it for you,
but if there's a bug in mod_mono, I won't discover it before you do.

Notable successes:
Bumping Mono-2.4 before Novell :-)
Shaving bugs assigned to dotnet@gentoo.org down to a reasonable level.
Attracting users to Gentoo through our .NET offering.

Future projects:
revdep-rebuild support for mono!
AOT support
Getting Mono tests to not fail in Sandbox.
Reducing the bus-factor. I have too much of this stuff in my head. I
should write docs... Later.

Re: [gentoo-dev] Project summaries

[Tomáš Chvátal]

[-- Attachment #1: Type: text/plain, Size: 343 bytes --]

> Future projects:
> revdep-rebuild support for mono!
> AOT support
> Getting Mono tests to not fail in Sandbox.
> Reducing the bus-factor. I have too much of this stuff in my head. I
> should write docs... Later.
Add to your todo:
Making mono working on KDE4. It has bindings, but i dont have guts for testing 
nor making it work ;]

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] Project summaries - Alpha Arch Team

[Robert Buchholz]

[-- Attachment #1: Type: text/plain, Size: 1078 bytes --]

On Wednesday 06 May 2009, Tobias Klausmann wrote:
> I've been toying with the idea of offering something akin to
> Debians popularity contest tool. Some people are rather
> uncomfortable with data gathering tools that send stuff to some
> strangers, so I don't know how well it would work. I list this
> idea here, since I have just about no idea what actual alpha
> hardware is used with Gentoo out there. Knowing which packages
> are actually *used* (instead of just being stabilized for the
> heck of it) would be nice. Added benefit of that would be that
> users helping with testing would reduce workload.

Hi Tobias,

a late Happy Birthday from my side first.

Note that we have a Summer of Code student this year who is working on a 
project to gather both hardware and software statistics from Gentoo 
users. If you have any special requirements for your platform, I am 
sure he has open ears. No need to invent two wheels at the same time.

I'm putting Sebastian in CC directly, if you are looking for the project 
mentor, that is me.


Robert

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [gentoo-dev] Project summaries - Alpha Arch Team

[Sebastian Pipping]

Robert Buchholz wrote:
> Note that we have a Summer of Code student this year who is working on a 
> project to gather both hardware and software statistics from Gentoo 
> users. If you have any special requirements for your platform, I am 
> sure he has open ears. No need to invent two wheels at the same time.

Yes, I'm all ears :-)



Sebastian

Re: [gentoo-dev] Project summaries - Java & Recruiters

[Petteri Räty]

[-- Attachment #1: Type: text/plain, Size: 575 bytes --]

Christian Faulhammer wrote:
> Hi,
> 
> any project lead/member can post an answer to this mail for a status
> report:
> 

Java:
- Too much stuff in overlays
- Beat caster with a stick
- Need more people to maintain our hundreds of packages
- Critical pkgs do have designated maintainers
- Beat all members with a stick so that they remember to show up for
monthly meetings

Recruiters:
- pva and keytoaster can handle the current load
- more people doesn't hurt but no active need to recruit more
- the quizzes could use an overhaul

Regards,
Petteri


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 261 bytes --]

Re: [gentoo-dev] Project summaries - KDE team sumary

[Jorge Manuel B. S. Vicetto]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


Christian Faulhammer wrote:
> > Hi,
> >
> > any project lead/member can post an answer to this mail for a status
> > report:
> >

Hi.

Gentoo KDE team status report.

Current:

 - We have a Lead again (me). It happened on FOSDEM, so it might have
been related to some "substance abuse"  ;-)
 - We have a strong team again full of new "blood" and are back in the
game - we can take more people, but we're able to keep up with the
work.
 - Resumed our regular meeting schedule - 3rd Thursday of the month at
19H00 UTC on #gentoo-kde channel of the freenode IRC network.
 - KDE-3.5.9 (stable) and 3.5.10 (testing) in the tree.
 - KDE-4.2.3 (testing) in the tree.
 - KDE-4.3 snapshots in the kde-testing overlay.
 - KDE-4.3 live (4.2.9999) in the kde-testing overlay.
 - KDE live (9999) in the kde-testing overlay.


Soon:

 - We're in the final stages to get updated KDE3 eclasses (currently in
kde-crazy overlay) into the tree. These eclasses move all misc apps
under the /usr/kde/3.5 prefix (to fix the colisions with KDE4 apps and
to fix prefix issues for KDE-3 apps).
 - After we move the eclasses we'll ask to get KDE-3.5.10 marked stable.
This means the end of the support for mono ebuilds. Anyone using them
will have to switch to the split ebuilds.
 - After getting this done, we can finally get KDE-4.X marked stable. We
hope to get all this done in the next 2 months.


How to help:

Although we have a fully staffed team now, we can always take more help.
If anyone is interested in the Gentoo KDE project and wants more info,
start by checking our page [1] and our overlays [2] [3]. We try to keep
some Docs in the kde-testing overlay [4] including some docs on how to
contribute and what needs to be done. Also, we still have a *few* open
bugs [5].


 {1[ - http://www.gentoo.org/proj/en/desktop/kde/
 [2] - http://git.overlays.gentoo.org/gitweb/?p=proj/kde.git;a=summary
 [3] - http://git.overlays.gentoo.org/gitweb/?p=proj/kde-crazy.git;a=summary
 [4] -
http://git.overlays.gentoo.org/gitweb/?p=proj/kde.git;a=tree;f=Documentation;h=92d10c3f9de2a22c5755a6fe746dfd5e75d7e044;hb=master
 [5] - http://tinyurl.com/kdebugs1


P.S. - Working with the Gentoo KDE team and getting access to the
overlays is one way to get involved with Gentoo and might set you up in
the road to become a Gentoo Dev - we have quite a few people around to
proof it  ;-)


- -- Regards, Jorge Vicetto (jmbsvicetto) - jmbsvicetto at gentoo dot org
Gentoo- forums / Userrel / Devrel / SPARC / KDE
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkoG/jwACgkQcAWygvVEyAJzaACeP9u1zPQDf35ftPBYzIk2S7Ay
SCUAnjiU8D8qMVh/atyd31gZc5gwLZSs
=OE8O
-----END PGP SIGNATURE-----

Re: [gentoo-dev] Project summaries

[Rémi Cardona]

Le 06/05/2009 08:49, Christian Faulhammer a écrit :
> Hi,
>
> any project lead/member can post an answer to this mail for a status
> report:

X11 Herd Status Update

Short term or recently done :
  - 1.5.3-r5 went stable (I'm sure y'all noticed)
  - there will be another 1.5 stable server within a few weeks
  - 1.6.x will go into ~arch pretty soon
  - alpha is pretty much the only arch that doesn't have 1.5 keyword but 
thanks to frequent poking, things should change pretty soon
  - 1.3 and 1.4 will get p.masked as soon as alpha and arm stabilize 1.5.3,
  - 1.3 will get treecleaned during the summer, 1.4 maybe a bit later...
  - the X11 overlay now has support for the nouveau driver and Gallium 
(thanks to a few external but essential contributors)

Medium term :
  - libxcb 1.2 will be moved to portage once we figure out a sane way to 
handle the disappearance of libxcb-x11.so. For those who haven't heard 
or seen what happens during the upgrade, let's just say that the upgrade 
from expat 1.95 to 2.0 was a walk in the park compared to this.
  - continue cleaning up useless libs and protos

Longer term :
  - major Docs overhaul, what we have now is a complete mess. Any help 
with this is greatly appreciated. See [1] for a short todo list.
  - try to keep up with upstream X, even if it means upsetting some 
users. Actually forcing folks to upgrade to 1.5 has been very 
beneficial, a lot of bugs were uncovered and reported upstream.


Intel Driver Status Update

  - 2.6.3 is the current stable
  - 2.7.0 is still p.masked, 2.7.1 will likely go in ~arch when it's out
  - The next stable driver will probably be 2.8 once xorg-server 1.6 is 
in portage and deemed stable enough.
  - The upcoming 2.8 branch will have a lot less code and options (no 
more DRI1, XAA, EXA, ...), making it easier to maintain and to use.

Cheers,

Rémi

Re: [gentoo-dev] Project summaries - KDE team sumary

[Markos Chandras]

[-- Attachment #1: Type: text/plain, Size: 1942 bytes --]

On Sunday 10 May 2009 19:18:04 Jorge Manuel B. S. Vicetto wrote:
> Christian Faulhammer wrote:
> > > Hi,
> > >
> > > any project lead/member can post an answer to this mail for a status
> > > report:
>
> Hi.
>
> Gentoo KDE team status report.
>
>[..]
> -- Regards, Jorge Vicetto (jmbsvicetto) - jmbsvicetto at gentoo dot org
> Gentoo- forums / Userrel / Devrel / SPARC / KDE
Hello there :)

Qt Herd, as part of KDE project, status report:

***Overlay status (qting-edge)***

Even though we are 2 developers and 1 contributor , we manage to keep this 
overlay in a pretty good shape. In this overlay we maintain 3 different qt 
versions

*4.9999 which is the master branch from nokias' git repository
*4.5.9999[qt-copy] which is the Qt maintained by KDE developers
*4.5.9999[-qt-copy] which is the 4.5 branch from nokias' git repository. 

Plus we maintain many Qt4 live packages

***Portage tree status***

We did quite good job in pushing Qt-4.5 packages really quick. We have a 
stabilization process for 4.5.1 packages[1] as well.  We maintain many qt4 
packages and we add more and more every day (ye, because we are quite crazy 
about Qt4 \o/) .
In general I can say that Ben(yngwin) and me can handle the load pretty good 
so far. At least this is what the number of qt bugs reveals :P

On the other hand the future doesn't look that good :(

Both of us we ll have extremely limited time after July . Ben is moving to 
China and I ll join the army for a year. So we really really really like to 
make sure that Qt4 will be in safe hands :).  However, there are 2 upcoming 
developers who, hopefully, will be full developers withing the next month so 
we can train them about qt4 split packages and qt4 eclasses. 

Ben if you think that I missed something let me know :)
-- 
Markos Chandras (hwoarang)
Gentoo Linux Developer [KDE/Qt/Sound/Sunrise]
Web: http://hwoarang.silverarrow.org

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] Project summaries

[Hans de Graaff]

[-- Attachment #1: Type: text/plain, Size: 641 bytes --]

On Wed, 2009-05-06 at 08:49 +0200, Christian Faulhammer wrote:
> any project lead/member can post an answer to this mail for a status
> report:

> XEmacs:
> graaff is the lone wolf here and because upstream development of XEmacs
> is not really on fire, he has not too much to do, I think.  He
> introduced eclasses in a similar way as the GNU Emacs team.

Actually there is work to do on XEmacs, but my work on the ruby project
seems to take precedence all the time. :-)

Plans for XEmacs:
- bring tree in sync with upstream released elisp packages
- bring xemacs 21.5.x to the tree from the overlay

Kind regards,

Hans

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] Project summaries

[Hans de Graaff]

[-- Attachment #1: Type: text/plain, Size: 1412 bytes --]

On Wed, 2009-05-06 at 08:49 +0200, Christian Faulhammer wrote:
> any project lead/member can post an answer to this mail for a status
> report:

The Ruby project summary:

We've had two new project members recently: a3li and gengor. In addition
we also have a number of new people who help out on occasion with our
overlay.

More ruby versions are now available:
- Ruby 1.9.x is in the tree. It's masked for now pending more testing
and pending getting the tree more ready for it.
- Ruby Enterprise Edition is available in our overlay.
- We also have the latest ruby 1.8.6 and 1.8.7 versions in our tree.

We are in the process of cleaning up the eclasses and getting them ready
to support multiple ruby versions as well. 

We have a Summer of Code project which will deliver a tool to treat Ruby
Gems as first-class citizens in Gentoo, including such things as
patching and testing. We hope that this will improve the quality and
quantity of ruby code that we can offer.

Future plans:

- Complete ruby 1.9.x migration and unmask it.
- Get Ruby Enterprise Edition ready to move to the main tree
- Add Summer of Code tool to the tree and convert majority of current
ebuilds to use it.
- Recruit more people: while we are not in bad shape right now we could
certainly use one or two more people to keep things moving along.
- Get our open bug count down.

Kind regards,

Hans

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

[gentoo-dev] Re: Project summaries

[Ryan Hill]

[-- Attachment #1: Type: text/plain, Size: 1537 bytes --]

On Wed, 6 May 2009 08:49:53 +0200
Christian Faulhammer <fauli@gentoo.org> wrote:

> Hi,
> 
> any project lead/member can post an answer to this mail for a status
> report:

I miss these. ;)


GCC-Porting:

Thanks to a load of help from darkside, loki_val, fauli, and others, GCC 4.3
is now stable on our primary archs.  Thanks to a load of bug reports from
Diego, the majority of the tree got fixed, including packages that haven't
been seen since Clinton was in office.

Work continues for GCC 4.4, which was just added to the tree last weekish.
Most of this work has happened in the gcc-porting overlay which will now be
merged with the tree, and future work will be directly applied to the tree.


wxWidgets:

Mainly in maintenance mode, but that should be changing soon as the 2.9
development series is released.  Major upcoming upstream changes will
include the merging of release and debug libraries, and later on, the
disappearance of separate ansi/unicode builds.  Usage will become much
simpler, probably to the point where we don't need the
eclass/eselect/wx-config wrapper stuff any more (I hope).

2.8.10 will be in the tree as soon as wxpython makes a release.

The eclass needs some love and updating to EAPI 2, which I should have time
to do sometime soon.


-- 
gcc-porting,                                      by design, by neglect
treecleaner,                              for a fact or just for effect
wxwidgets @ gentoo     EFFD 380E 047A 4B51 D2BD C64F 8AA8 8346 F9A4 0662

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] Project summaries

[Markos Chandras]

[-- Attachment #1: Type: text/plain, Size: 501 bytes --]

On Wednesday 06 May 2009 09:49:53 Christian Faulhammer wrote:
> Hi,
>
> any project lead/member can post an answer to this mail for a status
> report:
> [..]
Maybe, it would be nice each project, that wants more manpower, to update 
this[1] page, so that users would know what projects need more contribution :)

[1]: http://www.gentoo.org/proj/en/devrel/staffing-needs/

-- 
Markos Chandras (hwoarang)
Gentoo Linux Developer [KDE/Qt/Sound/Sunrise]
Web: http://hwoarang.silverarrow.org

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] Project summaries

[Ulrich Mueller]

>>>>> On Wed, 6 May 2009, Christian Faulhammer wrote:

> any project lead/member can post an answer to this mail for a status
> report:

Emacs project:

Christian has already reported, and I think he has covered the major
points. So nothing to add from my side.


Eselect project:

I've joined the project one month ago. Looks like it's my duty to
write a status report. ;-)

 * eselect-1.0.12 is out since three weeks. I've fixed most bugs
   (a dozen or so) that were open in bugzilla. So far, no regressions
   have been reported, so this version will be good for stabilisation
   soon.

   Hopefully this is also the last release from the 1.0.x branch,
   whose retirement is (IMHO) long overdue.

 * The eselect trunk has some new bells and whistles, including:
    - support for OpenRC in the "rc" module
    - "package-manager" library has been updated for Portage 2.1.6
    - new "modules" module, for listing and querying eselect modules
    - modules for EDITOR and PAGER environment variables
    - "news-tng", yet another module for reading GLEP 42 news
      (mainly with better Portage support)
    - the dysfunctional "mailer" module will be removed
    - more bug fixes; some of the reports are open since 2006 :-(

   There are still some things to be done before the release of
   version 1.1.0, but I hope that it will be ready in the second half
   of this month.

Ulrich

Re: [gentoo-dev] Project summaries - KDE team sumary

[Pacho Ramos]

El dom, 10-05-2009 a las 20:54 +0300, Markos Chandras escribió:
> We did quite good job in pushing Qt-4.5 packages really quick. We have a 
> stabilization process for 4.5.1 packages[1] as well.  We maintain many qt4 

I cannot see "[1]" link, seems missing in original mail

I think that it's:
http://bugs.gentoo.org/show_bug.cgi?id=266201

Best regards :-)

Re: [gentoo-dev] Project summaries - KDE team sumary

[Markos Chandras]

[-- Attachment #1: Type: text/plain, Size: 607 bytes --]

On Monday 11 May 2009 00:44:11 Pacho Ramos wrote:
> El dom, 10-05-2009 a las 20:54 +0300, Markos Chandras escribió:
> > We did quite good job in pushing Qt-4.5 packages really quick. We have a
> > stabilization process for 4.5.1 packages[1] as well.  We maintain many
> > qt4
>
> I cannot see "[1]" link, seems missing in original mail
>
> I think that it's:
> http://bugs.gentoo.org/show_bug.cgi?id=266201
>
> Best regards :-)
Oooops missed that :). Indeed this is the link
-- 
Markos Chandras (hwoarang)
Gentoo Linux Developer [KDE/Qt/Sound/Sunrise]
Web: http://hwoarang.silverarrow.org

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] Project summaries

[Rémi Cardona]

Le 10/05/2009 23:43, Gokdeniz Karadag a écrit :
> It seems like you have forgotten the link.
>

[1] https://bugs.gentoo.org/show_bug.cgi?id=267769

Thanks

Re: [gentoo-dev] Project summaries

[Daniel Pielmeier]

[-- Attachment #1: Type: text/plain, Size: 267 bytes --]

Ulrich Mueller schrieb am 10.05.2009 23:08:
> 
> 
> Eselect project:
> 
> I've joined the project one month ago. Looks like it's my duty to
> write a status report. ;-)
> 

Thank you for bringing the eselect project back to life.

-- 
Daniel Pielmeier


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 261 bytes --]

Re: [gentoo-dev] Project summaries

[Mart Raudsepp]

[-- Attachment #1: Type: text/plain, Size: 717 bytes --]

On Sun, 2009-05-10 at 18:45 +0200, Rémi Cardona wrote:
> 
> Medium term :
>   - libxcb 1.2 will be moved to portage once we figure out a sane way
> to 
> handle the disappearance of libxcb-x11.so. For those who haven't
> heard 
> or seen what happens during the upgrade, let's just say that the
> upgrade 
> from expat 1.95 to 2.0 was a walk in the park compared to this.

An important difference to note here is that expat case (sorry) was hit
by everyone, but xcb problem will be hit only by people who have enabled
USE=xcb on certain packages or globally, and that is not the default.


-- 
Mart Raudsepp
Gentoo Developer
Mail: leio@gentoo.org
Weblog: http://planet.gentoo.org/developers/leio

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: [gentoo-dev] Project summaries- kernel

[Daniel Drake]

Christian Faulhammer wrote:
> Hi,
> 
> any project lead/member can post an answer to this mail for a status
> report:

kernel:

Continues to be a small team with desires to grow. Our processes scale 
well but recruitment does not. Only real task is to handle 
gentoo-sources, 90% of the time is handling upstream bugs reported by 
users (the kernel is so big and fast-moving that in order to be more 
effective, we have to do a certain amount of work before sending users 
upstream).

gentoo-sources patchset continues to shrink, we're very close to vanilla 
which is great from a working-with-upstream perspective.

I'm not finding much time to devote to the project due to other 
commitments (seems to be an ongoing curse that occurs to anyone taking 
the 'lead' position). Not likely to change very soon :( Happy to 
consider proven contributors for taking over the lead position, past 
present and future.

Mike Pagano continues to be a driving force, continually attacking bugs, 
wranging patches and making releases.

Recruited George Kadianakis and Markos Chandras who have helped a lot. 
Need to spend more time integrating them and delegating more from me and 
Mike.

Overall in good shape with 22 open bugs.

One real drain for us is dealing with crazy gentoo devs who decide to 
maintain packages of kernel code outside of the kernel (i.e. external 
kernel drivers). These break really often because these external 
packages use the internal kernel API which is deliberately unstable. 
Many maintainers are responsive, but very often we have to deal with 
unresponsive maintainers or packages which simply can't be fixed easily, 
this eats a lot of our time, slows down stabling processes, and results 
in a bad experience for our users. Asking for extinction of all such 
packages is probably unreasonable, but it would be good to see them kept 
out of the stable tree or something like that, and we could do a better 
job at communicating these maintenance difficulties to our users ("use 
at your own risk, this will probably break next week").

My ideas for potential goals/improvements, totally dependent on time and 
interest from team members:
  - get bugs upstream faster
  - fewer and fewer bugs
  - accelerate stabling to the previous rate of 3 weeks after every major
    release from upstream. (quite time consuming)
  - speed up regression handling, prioritise higher
  - work more with bugs that we send upstream, right now they get a bit 
neglected by us and sometimes by upstream  (probably have 30-40 bugs in 
this state)
  - move genpatches website to independent location, automatically 
generated, with permanent/reliable tarball hosting



kernel-misc: Maintains various userspace packages that are tightly 
linked to the kernel e.g. jfsutils, module-rebuild, fuse,
also the kernel-2, linux-info and linux-mod eclasses.

Mostly neglected. Some packages have active maintainers, thanks! For the 
others I usually do a bug sweep every 6 months or so, taking out the 
easy bugs and applying patches from users.

Goals/improvements: find people to take care of this stuff..preferably 
people who can just step in and get on with it without me needing to 
find recruitment time.

Gentoo Security Project Summary -- was Re: [gentoo-dev] Project summaries

[Robert Buchholz]

[-- Attachment #1: Type: text/plain, Size: 7135 bytes --]

Gentoo Security Project Summary

Short Summary:
The Security Team is up and running, but we are dealing with numerous
tasks and a high load in daily maintenance. Fresh blood is not only
appreciated, but needed to continue the luxury of Security Support we
currently have. We have too many open bugs, too many undrafted GLSAs
that are eventually sent too slow, and a lot of channels to monitor.
There are some bugs that need extensive amount of work to be resolved.
The Security Team is also developing applications to support our
workflow and user's systems, such as improvements to glsa-check and our
DTD, a new Ruby on Rails application to draft GLSAs and an application
to coordinate Kernel security support and check local systems.

== Personal changes ==

=== Lead Election ===

Since the last election had been longer than a year ago, we held a new
election during the first two weeks of May. It was determined
unanimously that Pierre-Yves Rofes (py) and Robert Buchholz (rbu) will
be the new French-German duo that is our Team Leads. We would like to
publicly thank Raphael Marichez (falco) and Matthias Geerdsen (vorlon)
for doing the job the years past. They were both not available for
another term.

=== Additions to the team ===

Alex Legler (a3li) recently joined the Security Team. However we still
need more people helping with the daily maintenance work. This call for
help applies to both developers and users.

For more details on how to join the Security team, see:
http://www.gentoo.org/proj/en/security/

Or, more specifically:
http://www.gentoo.org/security/en/padawans.xml
http://www.gentoo.org/security/en/coordinator_guide.xml
http://www.gentoo.org/security/en/vulnerability-policy.xml
http://www.gentoo.org/security/en/bug-searching.xml

== Maintenance ==

=== Bugs and GLSAs ===

We have reached new highs in the number of open bugs and the length it
takes all of us to resolve them. A shortness in Gentoo developers in
general and on our team is leading to three issues:

(1) Security bugs are not resolved by ebuild maintainers

Some security bumps are staying open for weeks with teams not responding
to pings. Even issues that could be resolved before being public (what
we call "embargoed bugs") are not resolved due to maintainers not being
responsive on such bugs.
In fairness, I have to note this is limited to only some herds and not
architectures. Architectures and in particular their Arch Security
Liaisons are doing their job in a reliable and timely fashion.

(2) GLSAs are delayed

We're slow! We are sorry. I feel this is a great disappointment
especially in those cases where maintainers and arch teams are doing a
fast job and we take 4 weeks to write the accompanying GLSA. I see
potential for improvement with the GLSAMaker rewrite described below.
Contributors to GLSA writing are greatly welcome.

(3) Security Team is not resolving bugs either

In the past, we have been conducting simple version bumps ourselves or
have masked vulnerable ebuilds. Currently, doing other people's jobs in
the security process is mostly on hold as we have a hard time struggling
to cope with our part of the job.


=== Documentation update ===

We actually updated our existing documentation to reflect more of our
security process. Isn't that awesome? Read our project pages to find out
more:
http://www.gentoo.org/proj/en/security/


=== GLSA dtd and glsa-check ===

We have been discussing changes to the GLSA DTD for ages now. There's
few people interested in the subject and I have been slacking on it. I
have picked up glsa-check maintenance recently and we will announce
changes to the DTD to the dev lists as soon as they are fully drafted.
Since the GLSA format is supported in all package managers, the change
will be announced at least 6 weeks before going live.

Oh, and glsa-check will see some bugs fixed, I hope. And support for
UTF-8. And support for mask-glsas. Hmm.. anyone else here to help?

glsa-check changes in 0.2.4:
http://sources.gentoo.org/viewcvs.py/gentoolkit/branches/gentoolkit-0.2.4/src/glsa-check/
glsa-check changes in trunk (0.3):
http://sources.gentoo.org/viewcvs.py/gentoolkit/trunk/gentoolkit/
New DTD proposals:
http://git.goodpoint.de/?p=glsa-check.git;a=tree;h=refs/heads/glsa-2


== Feature extensions ==

=== GLSAMaker ===

The GLSAMaker is a web application that we use to draft, comment on and
refine GLSAs. It allows for the export of the GLSA texts and XML files
you might know from gentoo-announce or /usr/portage/metadata/glsa. The
application is considered helpful by all of us, however its shortcomings
require to duplicate some work that could be automated and its usability
makes working with it less fun than it could be and slows our work down
quite a bit.

Alex Legler (a3li) and Pierre-Yves Rofes (p-y) are currently working on
a rewrite that covers the current functionality and extensions to ease
the workflow dramatically by integrating metadata from Portage,
Bugzilla, the CVE database and Secunia.

We are looking forward to GLSAMaker 2 becoming the central point for
coordinating our efforts.

A refined access control will allow us to give access to the tool to
people that are not (yet) members of the team, and this allows us to
accept contributions from the community and other developers that want
to push GLSAs for their packages through our system faster.

If you are into Ruby On Rails development, or are looking for a project
to start, your help is greatly appreciated.
You can follow development here:
http://git.overlays.gentoo.org/gitweb/?p=proj/glsamaker.git
https://redmine.stingray.a3li.info/projects/show/glsamaker2


=== Kernel Security ===

Since 2005, we are not issueing GLSAs for Kernel vulnerabilities which
is an unfortunate flaw in our Vulnerability Policy. This is related to
the fact that these vulnerabilities are extremely hard to track and we
have a lot of Kernel sources with several maintainers. Unlike other
projects, the Kernel is actively maintained upstream and by bumping to
newer versions you will fix vulnerabilities automatically. This way, our
ebuilds are staying secure even without GLSAs. You machines, however,
may not.

However, we are looking to improve the process of handling these issues
as well. We are currently tracking all known bugs in Bugzilla, building
a large database of Kernel vulnerabilities -- most of which are fixed in
gentoo-sources. At the same time we are working on a tool to export this
data into a format that could be distributed as part of the Portage
tree. A tool will then allow checking of the locally running kernel
version against the vulnerability data to determine which updates are
required.

This work is conducted by Björn Tropf (asyme) and Robert Buchholz (rbu).
The part concerning the Portage tree will be proposed to this list at a
later time when we have a working module to collect and evaluate the
data.

Follow our work here:
http://git.overlays.gentoo.org/gitweb/?p=proj/kernel-check.git

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]