Re: packaging sfxr
On Mon, Nov 17, 2008 at 10:34, Hans de Goede <j.w.r.degoede@hhs.nl> wrote:
> Well, for that to be usefull, it would have to contain a golden set of
> patches, currently different distro's will be fixing the same issues in
> different manners, some may be fixing lots of issues in one big patch,
> others may have more granular patches. For such a patches repository to be
> really usefull, someone would need to take all those patches, get the best
> fixes for all issues, and where necessary come up with more generic fixes.
True, and that would be quite some work. Which is why starting with new
software would be best. It would allow for experimentation, for quick creation
and destruction of repos, etc etc.
> When all that is already done, how much work is left to make a new release ?
None. This is why this would so great for dead upstreams.
> Besides that such a repo would need distro maintainers to actively by
> pushing new patches in there and pulling patches from others.
No problem. Right now, you svn commit after you made a change. Now,
you run merge_with_fedora.sh and you are done.
> I have a different idea, why not make a website which allows searching of
> all the VCS's various distros use to store the various patches, so I could
> type foo, and it would show me that distros 1, 2 and 4 have a package which
> name matches foo, and then links to view each distro's patches.
That would be a lot of work. Once you have your distro-specific collection
modules, it would be OK, but still. This would need time and it would
redirect work effort into meta-stuff instead of real work. I am not dead
against it, but I think it's not needed.
It _would_ have the advantage of eabling us to pull from others so we
do not need to convinve them to push. On the other hand, a VCS can
be glued to other sources to pull from with the help of scripts as well.
A script to unpack an OpenSuSE SRPM could feed into a website as
easily as it could feed into a VCS.
> Then we take away the having to push part, and we make pulling much easier
> as you get announcements when there might be something worthy of pulling.
I will create a commit list along with the general discussion list on
fdo, anyway. That is the place where all patch notes etc should
ideally go to additionally to whereever they normally go to, anyway.
> I think this would make for a nice summer of code project ?
It would. If something like this is done, it should be modular on
both input and output side so that patches can be fed into
different back-ends.
Richard
Reply to: