only days left to ports lock (4.4 release)

Theo wrote:
>Yes, and sometimes tough love is required.
>
>Perhaps whoever the maintainer is will merge this in time.
>
>Perhaps not.
>
>Let me pose a question:
>
Would you rather have a good release that has good quality
integration between packages
>
>or
>
that has the latest python?

Let me pose a counter question:

Who needs "working" ports or a good quality integration between packages
f.e. for python if each kid from ghana could crash your webapplication or
whatever you build with python.

Some of us do have internet Theo

>You can't always have both.

You are right but we could try?
BSD isn't bug free either but you still try to do your best (and you
do pretty good! all of you developers do a very excellent job!).

The last sentence with the "you can't always have both" reminds me more to
Linus then to you Theo

I personaly wont face stack corruptions because I listen to a mp3 (or a
streaming radio?) and the lame-port is outdated but "works very well with
the also outdated &".

The main problem BSD has and wich affects the ports-situation propably
too is the lack of menpower.

Even I can't support the Maintainers by sending updated ports to them I
can still remind them to take a look if I do notice it's outdated.

solution may would be if at least all @openbsd-Maintainers would take
a look at their ports (again) like 1-2 weeks before the tree gets closed.
Just an idea but it takes time too (wich is the main problem I guess).

now start calling me a whiner or whatever. I can stand it so far.

But it's a fact that a secure S wont help you if your
PHP/Python/&anything_else_here crashes 24/7 because of a lame
autorooter-Script wich hits your webservers or a damn e-Mail worm or
&anything_else_here.

The weakest link breaks, always
Sure we all could run -current but then making "stable ports" would be a
joke anyway. :-)


Kind regards,
Sebastian

Look, I'm going to side with Theo on that one.

There are lots of *big* issues to fix each release. It doesn't look like
it from outside, but we have show-stoppers.

Each release, we refine the process.

This release, we cut down on the number of non-critical commits right up
to the lock.

So that the release goes smoother.

So that things go faster.

You can help by testing the snapshots, telling what does not work, etc.

As soon as the release is past, it will be `business as usual', and of
course, a lot of `minor' patches are going to happen.

Seriously, the release work is gigantic. There are choices to be made.
If you don't like the current choices, tough.

Thu, Jul 31, 2008 at 12:28:27PM +0200, Sebastian Rother wrote:

Theo wrote:
>Yes, and sometimes tough love is required.
>
>Perhaps whoever the maintainer is will merge this in time.
>
>Perhaps not.
>
>Let me pose a question:
>
Would you rather have a good release that has good quality
integration between packages
>
>or
>
that has the latest python?

Let me pose a counter question:

Who needs "working" ports or a good quality integration between packages
f.e. for python if each kid from ghana could crash your webapplication or
whatever you build with python.

Some of us do have internet Theo

>You can't always have both.

You are right but we could try?
BSD isn't bug free either but you still try to do your best (and you
do pretty good! all of you developers do a very excellent job!).

The last sentence with the "you can't always have both" reminds me more to
Linus then to you Theo

The point is that if you try to do too much during relese time, you
end up having accomplished nothing.

Look, I'm going to side with Theo on that one.
>
There are lots of *big* issues to fix each release. It doesn't look like
it from outside, but we have show-stoppers.
>
Each release, we refine the process.
>
This release, we cut down on the number of non-critical commits right up
to the lock.
>
So that the release goes smoother.
So that things go faster.
You can help by testing the snapshots, telling what does not work, etc.
>
As soon as the release is past, it will be `business as usual', and of
course, a lot of `minor' patches are going to happen.

Seriously, the release work is gigantic. There are choices to be made.
If you don't like the current choices, tough.

Well maybe the issue is that, except of the developers, nobody knows how
you do make a release or what a gigantic work it is?

I wont piss off anybody, it will be a gigantic task and I can imagine it
(hopefully) because of some projects as well but except to tell anybody
"you can't have both" a "we do not have the manpower to do this" would be
more truthly? It's no shame to admit there not enough res. available to do
things.

Anyway I wont argue and I thank you very much for any effort! (and I
seriously mean it). :)

And this is offtopic but: In case pcc gets "productiv" do you think this
may would speed things up. Except manpower what else is the bottleneck
currently (related to the ports)?


Kind regards,
Sebastian

Thu, Jul 31, 2008 at 04:32:02PM +0200, Sebastian Rother wrote:
Look, I'm going to side with Theo on that one.
>
There are lots of *big* issues to fix each release. It doesn't look like
it from outside, but we have show-stoppers.
>
Each release, we refine the process.
>
This release, we cut down on the number of non-critical commits right up
to the lock.
>
So that the release goes smoother.
So that things go faster.
You can help by testing the snapshots, telling what does not work, etc.
>
As soon as the release is past, it will be `business as usual', and of
course, a lot of `minor' patches are going to happen.

Seriously, the release work is gigantic. There are choices to be made.
If you don't like the current choices, tough.

Well maybe the issue is that, except of the developers, nobody knows how
you do make a release or what a gigantic work it is?

17 arches, 4000 ports yeah piece of cake.


I wont piss off anybody, it will be a gigantic task and I can imagine it

Too late; you as usual took a giant dump on the development process
without any knowledge of what is happening behind the scenes.

(hopefully) because of some projects as well but except to tell anybody
"you can't have both" a "we do not have the manpower to do this" would be
more truthly? It's no shame to admit there not enough res. available to do
things.

You can't have it both ways. Stabilizing an S isn't a piece of cake.


Anyway I wont argue and I thank you very much for any effort! (and I
seriously mean it). :)

Maybe you should not say those things then.


And this is offtopic but: In case pcc gets "productiv" do you think this
may would speed things up. Except manpower what else is the bottleneck
currently (related to the ports)?


Kind regards,
Sebastian
>

Thu, 31 Jul 2008, Sebastian Rother wrote:

I wont piss off anybody, it will be a gigantic task and I can imagine it
(hopefully) because of some projects as well but except to tell anybody
"you can't have both" a "we do not have the manpower to do this" would be
more truthly? It's no shame to admit there not enough res. available to do
things.

Want to help? Then you can cherrypick the patches from the python 2.5
branch that close the vulnerabilities and post them to the list (as links
to the svn changesets in the python webcvs/viewvc) matched against CVE
numbers.

As has been said countless times before, chatter on mailing lists will
not yield progress; someone has to actually do the work.

-d