Renat Lumpau <firstname.lastname@example.org> writes:
> We're in good shape now, but we weren't even a couple of months ago. At this
> point, we should be fine if we take care of ongoing maintenance, but things can
> _quickly_ turn ugly. As a matter of fact, I'll be offline for the better part of
> the summer, possibly as early as May, and I'd really like to make sure I don't
> spend another 4 months crawling through 150+ bugs when I return in September.
>> What is hard for me to judge is what kind of impact the security
>> problems had during the last year. What were the main problems for the
>> web-apps herd?
> There may have been a few security bugs to which we did not react as urgently as
> we should have. I don't know any specific instances because I wasn't around, and
> when I was, we reacted quickly :) Not to say that I'm the only person doing the
> work, just can't speak for all security issues we've had.
> As far as I'm concerned, the main problem is that we were badly out of sync with
> upstream for a few months when I was on hiatus. That means dissatisfied users,
> lots of bugs, potential security issues, etc etc etc.
Ok, so this clearly describes a man power problem that currently does
not exist. I know from personal experience that I only have about half
a day for looking at a bug assigned to webapps until Renat wakes up and
fixes it :) But it's clear that the herd should be able to handle the
bugs in case Renat is not around.
I think Renats suggestion to reduce the portage tree to a limited set of
packages that cover a variety of different topics makes sense.
Would it be reasonable to try to define two webapps members as primary
maintainers for each of the packages that we select? I believe that
could reduce the effect of looking at a bug and deciding that
"somebody" will certainly fix it.
I believe that we should not make the current suggestion for the
security requirements a real requirement for the list of selected
applications but instead just declare them as the desired goal.
As I mentioned in my last mail, I wanted to be able to have additional
packages in portage that I personally use. The main reason for that
was that I feel that the overlay will never be on the same level as
the tree itself. While it is not extremely complex to use the user
will have to know about it, install subversion, check out a
repository, and modify the make.conf. This is more than what I
consider necessary to tell the user "that this package is less well
maintained / less secure than the packages in the main portage tree".
I guess it will actually prevent a number of people from ever
seeing the package.
In addition I believe some users might not be exactly happy if we
start moving packages out of portage into the overlay.
So in order to make the process less complex I will provide
"layman". The tool is able to manage gentoo overlays. In order to get
the webapps overlay you run
layman -f -a webapps-stable -a webapps-experimental
to get both overlays fetched and added to your make.conf
automatically. To update the repositories you can later run
People that want to crash their hard drives can get it from my
layman -f -a wrobel-stable
I think this significantly reduces the differences between the overlay
and the tree. As a result my urge to add stuff to the tree would also
be significantly reduced. And I think that moving stuff from the tree
to the overlay would then be an acceptable option.
For the overlay I would suggest that the "production-stable" branch
should be only accesible to devs and that we handle it the same way as
we currently handle the tree. The "experimental" branch would continue
to be our playground.
Gunnar Wrobel Gentoo Developer
IRC: #gentoo-web at freenode.org