On Fri, Dec 01, 2006 at 12:25:20PM +0100, Waldemar Brodkorb wrote: > On Fri, 01 Dec 2006 at 10:31 +0000, Thorsten Glaser wrote: [...] > > > > 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.
Hi, I haven't seen any opinions besides Markus, Thorsten and yours. Perhaps we should wait a little bit longer. Waldemar's solving of the problem mentioned above has my fully agreement when you look only into the current problem, but it is very shortlooking. I bet that you do not know very much about this integration in a half year. And if you even know it, no other one can reconstruct it. It is just a bunch of patchfiles, in optimal case with some additional comments. Before we decide about maintainer responsibility, we should solve this situation. Where is the solution for the problem of loosing linkage between parts of patches? Just put some hints in different files? What is the real difference for you to migrate to new upstream releases? As you know I have done this with many different packages, no problem at all, I have migrated the kernel from 2.4.32 to 2.4.33.x. Even Marcus has done this with busybox, and it was finished in a short period 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? This is not a question today. Dirk _______________________________________________ freewrt-developers mailing list [email protected] https://www.freewrt.org/lists/listinfo/freewrt-developers
