Hi
On 12/1/06, Waldemar Brodkorb <[EMAIL PROTECTED]> wrote:
Hi,
On Fri, 01 Dec 2006 at 10:31 +0000, Thorsten Glaser wrote:
> Markus Wigge dixit:
>
> >Funny, and after "make update-patches" you still have the comments?
>
> Of course? That's part of the design.
>
> >And what if one single file is patched for different reasons?
>
> Then the OLD system definitively sucks more than update-patches,
> because if a file is patched several times, stuff like "which
> .orig file belongs to which patch and which is my real pristine
> file now", "which patch depends on which patch", etc. appears.
>
> This point of yours seems to be the weak point of update-patches
> at first, but if you work with it for a while, you see it's
> actually an improvement. Plus, you always get diffs which are
> guaranteed to apply. They're even applying with a greater chance
> to succeed after you update the package. (You should still regen
> them afterwards, but it helps the upgrader.)
>
> >Let's skip this system with
> >busybox too then.
>
> That's up to the busybox subsystem maintainer. wbx and I aren't
> forcing anyone. I just do want people to not think that the new
> system is inferiour.
That is the point. We do not force anyone to use make
update-patches. The maintainer of a package decides on his own.
I really had problems to integrate my udhcp background patch to
ifupdown, because of the old structure. Therefore I decided to
switch to autogenerated patches, which saves me a lot of time.
For trunk we should use a maintainer model for packages.
Now the question:
How we establish maintainership for packages in trunk? Does we have
enough developers to take maintainership for important packages?
Who wants to maintain a package in trunk?
I can look at shorewall stuff and maybe some other packages...
lg,
Christian
_______________________________________________
freewrt-developers mailing list
[email protected]
https://www.freewrt.org/lists/listinfo/freewrt-developers
