nth match

nth match

[Torsten Luettgert]

Hello,

I understand Patrick wanted to integrate nth and random
into a new statistics match. That's fine with me, but why
was nth and random removed from pom without any replacement,
i.e. the new statistics match?

You're just ripping out functionality based on something which
will probably appear at some undetermined time in the future.

That's no good style, sorry. Good style would be to first write
the new match, adding it, giving it time to mature and marking
the old stuff as obsolescent, then at some time removing it.

Regards,
Torsten

(P.S.: sorry if this appears twice. I was so pissed off at the
time that I forgot to use the correct sender address)

Re: nth match

[Patrick McHardy]

Torsten Luettgert wrote:
> Hello,
> 
> I understand Patrick wanted to integrate nth and random
> into a new statistics match. That's fine with me, but why
> was nth and random removed from pom without any replacement,
> i.e. the new statistics match?
> 
> You're just ripping out functionality based on something which
> will probably appear at some undetermined time in the future.

I did neither "rip something out", as the match was never part
of anything but a mostly random crap collection, nor is the
time undetermined, it will go in 2.6.18. In fact it is queued
for upstream submission sometime this weekend.

> That's no good style, sorry. Good style would be to first write
> the new match, adding it, giving it time to mature and marking
> the old stuff as obsolescent, then at some time removing it.

You're free to grab one of the many releases of patch-o-matic
that still contain the nth match and use that. I certainly
won't let trivial patches bitrot in patch-o-matic. Unlike the
kernel, patch-o-matic never made any promises about backwards
compatibility, support or anything else. You may also have
noticed that it didn't even compile with current kernels.

> (P.S.: sorry if this appears twice. I was so pissed off at the
> time that I forgot to use the correct sender address)

If you're so pissed off, how about you maintain a version until
2.6.18 is released? Feel free to set up a repository and send
me the URL to be included in the distibuted sources.list.

Re: nth match

[Torsten Luettgert]

On Sat, 2006-05-27 at 17:48 +0200, Patrick McHardy wrote:
> Torsten Luettgert wrote:
> > Hello,
> > 
> > You're just ripping out functionality based on something which
> > will probably appear at some undetermined time in the future.
> 
> I did neither "rip something out", as the match was never part
> of anything but a mostly random crap collection,

But you did, it's not in there any longer. Nevermind, I can
get it from old revisions.

>  nor is the
> time undetermined, it will go in 2.6.18. In fact it is queued
> for upstream submission sometime this weekend.

That's good to hear. How about putting a patchlet dir into the
repository? I could update my scripts that use nth to statistics
once I see how it's used.

> > That's no good style, sorry. Good style would be to first write
> > the new match, adding it, giving it time to mature and marking
> > the old stuff as obsolescent, then at some time removing it.
> 
> You're free to grab one of the many releases of patch-o-matic
> that still contain the nth match and use that.

Yep, just did that an hour ago.

> I certainly won't let trivial patches bitrot in patch-o-matic.
> Unlike the kernel, patch-o-matic never made any promises about backwards
> compatibility, support or anything else.

Oh, I never said you "must" do anything because you promised it
or something. It's just that something I used and that works
well just disappeared. Would it hurt so much to leave it in
while it's still working until an alternative is available?

I always thought pom was an effort to bring useful functionality
which didn't make the long, painful way into the official kernel
(and probably never will) to simple users like me who can benefit
from it, folks that don't have the time (or ability) to write it
for themselves.

Apparently you're seeing it more as a step stone on the way to
kernel inclusion. Now, it's you who are part of the team
and you're investing a lot of your own time for pom, not me,
so I'll just have to make do with what you're offering.

> You may also have noticed that it didn't even compile with current
> kernels.

Interesting. I just made a 2.6.16.18 with it, and it compiled
just fine. Does it break on 2.6.17?

> > (P.S.: sorry if this appears twice. I was so pissed off at the
> > time that I forgot to use the correct sender address)

Let me apologize for the tone of my original posting. I was
really running on adrenaline, since useful stuff was gone,
and stuff like rtsp-conntrack, which I have never seen even
compile, stays in just fine.

> If you're so pissed off, how about you maintain a version until
> 2.6.18 is released? Feel free to set up a repository and send
> me the URL to be included in the distibuted sources.list.

Personally, I'd like to do this. Unfortunately, I cannot, for
reasons I cannot go into at the moment. Nevermind, it has worked
for a long time (not counting the trivial changes in the .ladd files
when x_tables appeared), so it'll probably continue to do so
until your statistics match is available.

Sorry again, didn't mean to personally attack anyone.

Regards,
Torsten

Re: nth match

[Patrick McHardy]

Torsten Luettgert wrote:
> On Sat, 2006-05-27 at 17:48 +0200, Patrick McHardy wrote:
> 
>> nor is the
>>time undetermined, it will go in 2.6.18. In fact it is queued
>>for upstream submission sometime this weekend.
> 
> 
> That's good to hear. How about putting a patchlet dir into the
> repository? I could update my scripts that use nth to statistics
> once I see how it's used.

The removal was part of a large patch-o-matic cleanup to reduce
the overhead for us. Development today happens a lot nearer to
the kernel than it used to (which is good), so I don't think that
would do any good. I'll happily publish my git tree if anyone is
interested, but for 2.6.18 it doesn't really matter anymore since
I'm going to push out most of my patches this weekend.

>>I certainly won't let trivial patches bitrot in patch-o-matic.
>>Unlike the kernel, patch-o-matic never made any promises about backwards
>>compatibility, support or anything else.
> 
> 
> Oh, I never said you "must" do anything because you promised it
> or something. It's just that something I used and that works
> well just disappeared. Would it hurt so much to leave it in
> while it's still working until an alternative is available?

No, it wouldn't, but now its gone and we didn't even release the
stripped down pom yet, so I think people can just as well use the
last release.

> I always thought pom was an effort to bring useful functionality
> which didn't make the long, painful way into the official kernel
> (and probably never will) to simple users like me who can benefit
> from it, folks that don't have the time (or ability) to write it
> for themselves.
> 
> Apparently you're seeing it more as a step stone on the way to
> kernel inclusion. Now, it's you who are part of the team
> and you're investing a lot of your own time for pom, not me,
> so I'll just have to make do with what you're offering.

Actually I'm seeing it mostly as obsolete. Most of the patches
still in there will get merged at some point. As for step stone,
I think it many cases its counterproductive to put patches in
there because they will bitrot, stop to apply and not get nearly
as much testing as in the mainline kernel. Its usually even less
work just doing the last bits I see necessary for kernel inclusion
myself than apply to pom, wait, apply update, fix compilation,
wait some more, ...

>>You may also have noticed that it didn't even compile with current
>>kernels.
> 
> 
> Interesting. I just made a 2.6.16.18 with it, and it compiled
> just fine. Does it break on 2.6.17?

Yes. It also broke for 2.6.16, but was fixed.

> Sorry again, didn't mean to personally attack anyone.

Don't worry, no harm done.

Re: nth match

[Torsten Luettgert]

On Sat, 2006-05-27 at 19:45 +0200, Patrick McHardy wrote:
> Torsten Luettgert wrote:
> > On Sat, 2006-05-27 at 17:48 +0200, Patrick McHardy wrote:
> > 
> > Apparently you're seeing it more as a step stone on the way to
> > kernel inclusion. Now, it's you who are part of the team
> > and you're investing a lot of your own time for pom, not me,
> > so I'll just have to make do with what you're offering.
> 
> Actually I'm seeing it mostly as obsolete. Most of the patches
> still in there will get merged at some point. As for step stone,
> I think it many cases its counterproductive to put patches in
> there because they will bitrot, stop to apply and not get nearly
> as much testing as in the mainline kernel. Its usually even less
> work just doing the last bits I see necessary for kernel inclusion
> myself than apply to pom, wait, apply update, fix compilation,
> wait some more, ...

Hmm. So does this mean pom is (in)officially dead?
If new stuff doesn't go in there, and much of the old stuff is
removed, and the rest of it will be merged in the foreseeable future,
there's not much point in still maintaining it, right?

Personally, I'd regret that, because pom did at least supply
a fine framework for writing own matches and targets.

Regards,
Torsten

Re: nth match

[Patrick McHardy]

Torsten Luettgert wrote:
> Hmm. So does this mean pom is (in)officially dead?
> If new stuff doesn't go in there, and much of the old stuff is
> removed, and the rest of it will be merged in the foreseeable future,
> there's not much point in still maintaining it, right?

No, it will still be used for patches that we don't want to
put in mainline, but still have some interest in maintaining
and for patches maintained by other people.

> Personally, I'd regret that, because pom did at least supply
> a fine framework for writing own matches and targets.

It should be even easier to do this now since you can setup
your own repository and update it without having to send
patches to us, we just include the URL.