here are some ideas:
1. we should provide an easy to use tool for users so that they can compile packages themselves. This also comes with the fact that we also need to provide a good howtos and strong community support. this will circumvent the problem of heavy package maintenance cost. we can avoid a kind of situation that one person is taking care of many vital packages.
2. we should get core libs from slacks, perhaps. and perhaps we still need to maintain big packages like open office. for this, we should perhaps have a small group of dedicated packagers who can possibly work in turns so if one is busy then another one can cover him or her.
3. we should have a good packaging rules to obey - so that we can provide high quality packages. (This is something i liked a lot about Zenwalk.)
what do you think about them?
package maintenance
package maintenance
'Tommorow is like today, just happens tomorrow.'
Re: package maintenance
1. Agreed. We should use something like buildpkg again.
2. Yep, covering for others is a good idea.
3. Definitely.
2. Yep, covering for others is a good idea.
3. Definitely.
Re: package maintenance
Thumbs up!gapan wrote:1. Agreed. We should use something like buildpkg again.
2. Yep, covering for others is a good idea.
3. Definitely.
Re: package maintenance
+1, totally agree.
Re: package maintenance
I'm late for the train ride here, but personally I think it would be great if there was one single centralized system online, perhaps even without package maintainers, but rather with all packages as a pool that any of the trusted packagers could update as new version came out.
No matter what way it happens, things could be much simpler and easier than the FIFO/testing forums posts of zenwalk, IMHO that's just abusing a forum for something it is not designed to do. It could be done much more efficiently I think, but that's just my inexperienced opinion. The heap of confusing and conflicting information about how to package really was aggravating on zenwalk, when it could have been very simple with an online interface like ZUR or something for the packaging.
Just in my opinion.
No matter what way it happens, things could be much simpler and easier than the FIFO/testing forums posts of zenwalk, IMHO that's just abusing a forum for something it is not designed to do. It could be done much more efficiently I think, but that's just my inexperienced opinion. The heap of confusing and conflicting information about how to package really was aggravating on zenwalk, when it could have been very simple with an online interface like ZUR or something for the packaging.
Just in my opinion.
Re: package maintenance
I agree on that. The forum is good for package testing, but posting packages there and somebody else hast to fifo then is doing the work twice. But I don't know a better systemSparky wrote:No matter what way it happens, things could be much simpler and easier than the FIFO/testing forums posts of zenwalk, IMHO that's just abusing a forum for something it is not designed to do. It could be done much more efficiently I think, but that's just my inexperienced opinion.
Re: package maintenance
Yes, I agree about the FIFO part. But I can't think of a better way to do it either, at least for non-trusted packagers. Someone else has to upload packages for them. We could possibly have an upload page for everyone and then trusted users could just click Accept or something and put them on the repos. That's what I had in mind originally for ZUR, but it never really happened and I don't know if anyone here has the knowledge or willing to code something like that.
For trusted users, that could have ssh access to the server, I thought it won't be that hard to code something that would make everything put in a local FIFO dir, be automatically uploaded in the server in the right place, replacing old versions etc.
For trusted users, that could have ssh access to the server, I thought it won't be that hard to code something that would make everything put in a local FIFO dir, be automatically uploaded in the server in the right place, replacing old versions etc.
Re: package maintenance
Sparky : welcome
Sparky, thenktor, Gapan : you're right. Forums are bad and increase work. A sort-of private ZUR could be a good idea.
With a simpler one, I could code it. I'm used to code this type of application for the web. But I'm very bad in graphics, so when it's done, help me with that part When everything on this will be decided, I'll start coding it.
Sparky, thenktor, Gapan : you're right. Forums are bad and increase work. A sort-of private ZUR could be a good idea.
With a simpler one, I could code it. I'm used to code this type of application for the web. But I'm very bad in graphics, so when it's done, help me with that part When everything on this will be decided, I'll start coding it.
Re: package maintenance
I have to admit that I really don't know anything about this ZUR thing. I've never used it because it seemed to be like doing things twice (testing and posting packages in the forum and in ZUR again?).
Basically we just need a web interface, where trusted users can post the links to packages (txz, dep, md5, src), click on "Upload" and it will automatically get FIFOed.
And just idea: we could add a file $packagename-chaneglog.txt to the repository, where all past versions with changes are listed. Example:
Basically we just need a web interface, where trusted users can post the links to packages (txz, dep, md5, src), click on "Upload" and it will automatically get FIFOed.
And just idea: we could add a file $packagename-chaneglog.txt to the repository, where all past versions with changes are listed. Example:
Code: Select all
2009-06-13: spkg-pkgtools-1.0rc11-i486-1tm.txz (package structure changed, new version)
2009-06-10: spkg-pkgtools-1.0rc10-i486-1tm.txz (initial version)
Re: package maintenance
I think that is overkill to do for each package. Anyone can easily create that list with grep packagenme CHANGELOG.TXT anyway. That assumes that changelogs stay there and not get deleted with each version as they do in zenwalkthenktor wrote:And just idea: we could add a file $packagename-chaneglog.txt to the repository, where all past versions with changes are listed.