Hi, There! What about adding something like prt-get --push <portname> that a newly created / updated port will be published to some mailing list for review and inclusion into i.e. contrib? I take care of my own (maybe five to ten) ports which get an update every once in a while. I think adding my repo to the already 50 others doesn't make sense since I don't see any advantage to have even more repos and more different versions to choose from (not knowing versions without checking it manually). I think it would be much better to centralise the repositories to get opt and contrib more up-to-date instead of everybody is doing his/her own thing. What do you think? Regards, Clemens
Am 10.12.2009 21:25, schrieb Clemens Koller:
What about adding something like prt-get --push <portname> that a newly created / updated port will be published to some mailing list for review and inclusion into i.e. contrib?
You think about something like git-format-patch and git-send-email? ;)
I take care of my own (maybe five to ten) ports which get an update every once in a while. I think adding my repo to the already 50 others doesn't make sense since I don't see any advantage to have even more repos and more different versions to choose from (not knowing versions without checking it manually).
I think it would be much better to centralise the repositories to get opt and contrib more up-to-date instead of everybody is doing his/her own thing. What do you think?
Somehow I don't get, how you came to the conclusion, that you want to centralize all ports, but don't think, that it is worth to publish your own ports. Imho it is pretty simple to become a conrtib maintainer to make your ports available for everyone. The problem I see in putting everything in contrib is that _everyone_ then puts his port into it and therefore (if someone puts a port there and forgets about them) ports can get unmaintained pretty soon. You could work arround this, if you say, that everyone is "allowed" to update everyone's port in conrtib. But as a developer I know, that you can pretty easyly offend other developers, if you touch their code, so this could be some kind of contraproductive. bye richi
On Thu, Dec 10, 2009 at 11:39:03PM +0100, Richard Pöttler wrote:
Am 10.12.2009 21:25, schrieb Clemens Koller:
What about adding something like prt-get --push <portname> that a newly created / updated port will be published to some mailing list for review and inclusion into i.e. contrib?
You think about something like git-format-patch and git-send-email? ;)
I take care of my own (maybe five to ten) ports which get an update every once in a while. I think adding my repo to the already 50 others doesn't make sense since I don't see any advantage to have even more repos and more different versions to choose from (not knowing versions without checking it manually).
I think it would be much better to centralise the repositories to get opt and contrib more up-to-date instead of everybody is doing his/her own thing. What do you think?
Somehow I don't get, how you came to the conclusion, that you want to centralize all ports, but don't think, that it is worth to publish your own ports. Imho it is pretty simple to become a conrtib maintainer to make your ports available for everyone. The problem I see in putting everything in contrib is that _everyone_ then puts his port into it and therefore (if someone puts a port there and forgets about them) ports can get unmaintained pretty soon. You could work arround this, if you say, that everyone is "allowed" to update everyone's port in conrtib. But as a developer I know, that you can pretty easyly offend other developers, if you touch their code, so this could be some kind of contraproductive.
I agree, we have the bug tracker and maintainers email addresses are available. The problem exists with people preferring to roll their own ports rather than file a bug or contact the maintainer directly; and this isn't necesarilly a bad thing either. The more people that add personal repos to the portdb, the better. It increases the chances of finding a port that you want, even if you have to modify it to suit your purposes (or even get it to work). As a side note, I am designing a new portdb web app that should make collaboration easier between users. But this is a long way of from being complete. -- Lucas Hazel <lucas@die.net.au>
Hello, Richard! Richard Pöttler schrieb:
Am 10.12.2009 21:25, schrieb Clemens Koller:
What about adding something like prt-get --push <portname> that a newly created / updated port will be published to some mailing list for review and inclusion into i.e. contrib?
You think about something like git-format-patch and git-send-email? ;)
Yes, for example. It seems like a very good idea to use git. But how many users are using git and push their changes nowadays? Why isn't this part of the default setup?
I take care of my own (maybe five to ten) ports which get an update every once in a while. I think adding my repo to the already 50 others doesn't make sense since I don't see any advantage to have even more repos and more different versions to choose from (not knowing versions without checking it manually).
I think it would be much better to centralise the repositories to get opt and contrib more up-to-date instead of everybody is doing his/her own thing. What do you think?
Somehow I don't get, how you came to the conclusion, that you want to centralize all ports, but don't think, that it is worth to publish your own ports.
I think that a problem is that (duplicated) ports are scattered among many repos and it's hard to find out which one is the most current and which one is most likely to work for a quick and dirty update - increasing the version number, adjusting the Pkgfile a bit, check footprint and ... ? In my point of view, something is missing in the default CRUX way: Feedback to one _central_ place.
Imho it is pretty simple to become a conrtib maintainer to make your ports available for everyone.
If it's so simple, can it become a default for everyone? A simple way to push changes to i.e. contrib (via a list and via review by some list members) would imo motivate more people to contribute. This could focus development more to one 'upstream' repository and avoid more diversification of the ports.
The problem I see in putting everything in contrib is that _everyone_ then puts his port into it and therefore (if someone puts a port there and forgets about them) ports can get unmaintained pretty soon. You could work arround this, if you say, that everyone is "allowed" to update everyone's port in conrtib. But as a developer I know, that you can pretty easyly offend other developers, if you touch their code, so this could be some kind of contraproductive.
There need be an instance to review these changes - a list. A clearly visible version and timestamp could make it very clear which port is old an could benefit from an update. Example: I need to update qt4 because I want to find out if the newest qtcreator can be used for sw development for a project. That is: qt-4.6.0 and qtcreator-1.3.0 What do you do? Search the portdb for 'qt'... You will get some hits: 3x qt4, qt-creator and qtcreator from different collections. (Some work was done more than once.) Now, you need to find and decide which qt thing is good for you. Here, the mess starts: You cannot check all the Pkgfiles in one place. -> :-( You have to check the Pkgfiles manually to find out which version can be preferrably used for an update. -> :-( You have to clone the whole collection if it's using rsync just to be able to find out the version of one port... -> :-( Something like timestamps don't really exist. I hope you got what I try to suggest you. Best regards, Clemens
Clemens Koller wrote:
Hello, Richard!
Richard Pöttler schrieb:
Am 10.12.2009 21:25, schrieb Clemens Koller:
What about adding something like prt-get --push <portname> that a newly created / updated port will be published to some mailing list for review and inclusion into i.e. contrib?
You think about something like git-format-patch and git-send-email? ;)
Yes, for example. It seems like a very good idea to use git. But how many users are using git and push their changes nowadays? Why isn't this part of the default setup?
I take care of my own (maybe five to ten) ports which get an update every once in a while. I think adding my repo to the already 50 others doesn't make sense since I don't see any advantage to have even more repos and more different versions to choose from (not knowing versions without checking it manually).
I think it would be much better to centralise the repositories to get opt and contrib more up-to-date instead of everybody is doing his/her own thing. What do you think?
Somehow I don't get, how you came to the conclusion, that you want to centralize all ports, but don't think, that it is worth to publish your own ports.
I think that a problem is that (duplicated) ports are scattered among many repos and it's hard to find out which one is the most current and which one is most likely to work for a quick and dirty update - increasing the version number, adjusting the Pkgfile a bit, check footprint and ... ?
In my point of view, something is missing in the default CRUX way: Feedback to one _central_ place.
I think the point is to get feedback, doesn't really matter if it's centrilzed or not. There are lot of ways to talk with maintainers, email adresses, irc and of course the bugtracker.
Imho it is pretty simple to become a conrtib maintainer to make your ports available for everyone.
If it's so simple, can it become a default for everyone? A simple way to push changes to i.e. contrib (via a list and via review by some list members) would imo motivate more people to contribute.
This could focus development more to one 'upstream' repository and avoid more diversification of the ports.
Duplicated ports in personal repositories I think are used to specify personal options to a port. The "official" repositories must fill the basic options, and I think that's the reason why there are lot of duplicates. When the only difference between official ports and personal ports is a version bump, then there is a lack of comunication (exists the possibility about a security reason too, or may be dependencies with other ports with a unique version) but the way to go must be to talk with maintainer's port and advice about a new version.
The problem I see in putting everything in contrib is that _everyone_ then puts his port into it and therefore (if someone puts a port there and forgets about them) ports can get unmaintained pretty soon. You could work arround this, if you say, that everyone is "allowed" to update everyone's port in conrtib. But as a developer I know, that you can pretty easyly offend other developers, if you touch their code, so this could be some kind of contraproductive.
There need be an instance to review these changes - a list.
A clearly visible version and timestamp could make it very clear which port is old an could benefit from an update.
Example: I need to update qt4 because I want to find out if the newest qtcreator can be used for sw development for a project. That is: qt-4.6.0 and qtcreator-1.3.0
What do you do? Search the portdb for 'qt'... You will get some hits: 3x qt4, qt-creator and qtcreator from different collections. (Some work was done more than once.)
Now, you need to find and decide which qt thing is good for you. Here, the mess starts:
You can verify if the port exists in an official repo and talk directly to the maintainer. Your point can be discussed and reasoned. I think the best way to maintain a port is to let it to one person, and this doesn't mean that a port update can't be talked. We finish in the same point, communication between maintainers and users.
You cannot check all the Pkgfiles in one place. -> :-( You have to check the Pkgfiles manually to find out which version can be preferrably used for an update. -> :-( You have to clone the whole collection if it's using rsync just to be able to find out the version of one port... -> :-( You can get the port when using rsync, there is a command in the portdb to get only the port instead of getting the entire collection.
Something like timestamps don't really exist.
I hope you got what I try to suggest you.
Best regards,
regards, Victor.
Clemens
Hi, Victor Martinez wrote:
Clemens Koller wrote:
Hello, Richard!
Richard Pöttler schrieb:
Am 10.12.2009 21:25, schrieb Clemens Koller:
What about adding something like prt-get --push <portname> that a newly created / updated port will be published to some mailing list for review and inclusion into i.e. contrib?
You think about something like git-format-patch and git-send-email? ;)
Yes, for example. It seems like a very good idea to use git. But how many users are using git and push their changes nowadays? Why isn't this part of the default setup?
Maintainers from core, opt, xorg, contrib, kde, xfce, all x86_64's
collections and etc. are using git. See http://crux.nu/gitweb/
[...]
I think it would be much better to centralise the repositories to get opt and contrib more up-to-date instead of everybody is doing his/her own thing. What do you think? Somehow I don't get, how you came to the conclusion, that you want to centralize all ports, but don't think, that it is worth to publish your own ports. [...] In my point of view, something is missing in the default CRUX way: Feedback to one _central_ place. I think the point is to get feedback, doesn't really matter if it's centrilzed or not. There are lot of ways to talk with maintainers, email adresses, irc and of course the bugtracker. Imho it is pretty simple to become a conrtib maintainer to make your ports available for everyone. If it's so simple, can it become a default for everyone? A simple way to push changes to i.e. contrib (via a list and via review by some list members) would imo motivate more people to contribute. Just file a contrib application to push changes to contrib but first, to keep the quality of contrib high, you should maintain an repository for a while (2-6 month) to get used to packaging, following upstream sources etc. All the other
This could focus development more to one 'upstream' repository and avoid more diversification of the ports.
Duplicated ports in personal repositories I think are used to specify personal options to a port. The "official" repositories must fill the basic options, and I think that's the reason why there are lot of duplicates. When the only difference between official ports and personal ports is a version bump, then there is a lack of comunication (exists the possibility about a security reason too, or may be dependencies with other ports with a unique version) but the way to go must be to talk with maintainer's port and advice about a new version.
There need be an instance to review these changes - a list.
A clearly visible version and timestamp could make it very clear which port is old an could benefit from an update.
Example: I need to update qt4 because I want to find out if the newest qtcreator can be used for sw development for a project. That is: qt-4.6.0 and qtcreator-1.3.0
What do you do? Search the portdb for 'qt'... You will get some hits: 3x qt4, qt-creator and qtcreator from different collections. (Some work was done more than once.)
Now, you need to find and decide which qt thing is good for you. Here, the mess starts:
You cannot check all the Pkgfiles in one place. -> :-( You have to check the Pkgfiles manually to find out which version can be preferrably used for an update. -> :-( As nipuL says, he's working on portdb-ng, and for what I know he has created a great CLI tool (pdb) to get all the stuff you need from the portdb. Maybe you could contribute with testing it. You have to check the Pkgfiles manually to find out which version can be preferrably used for an update. -> :-( You have to clone the whole collection if it's using rsync just to be able to find out the version of one port... -> :-( You can get the port when using rsync, there is a command in the
You can verify if the port exists in an official repo and talk directly to the maintainer. Your point can be discussed and reasoned. I think the best way to maintain a port is to let it to one person, and this doesn't mean that a port update can't be talked. We finish in the same point, communication between maintainers and users. portdb to get only the port instead of getting the entire collection. You can use the http command too. And that is also improved in the
Since CRUX was made as a lightweight distro I don't think git should be part of the default setup, but that doesn't means that you can't install git on your setup. maintainers will review your ports, and if they decide to trust your work you'll become a maintainer. (Please see http://crux.nu/Main/ContribRules) I would not image if a new user updates a Pkgfile and because of his lack of experience he push something wrong (like missing the $PKG variable) or maybe malware, etc. IMHO people should trust you before push packages. portdb-ng. You can use other alternatives to have a meta collection of ports. I'm developing 'mpup' (a meta-collection driver script for ports). Tests, ideas and help are welcome (http://mikeux.dyndns.org/crux/files/mpup.html) Best regards, -- Jose V Beneyto | http://mikeux.dyndns.org -- Jose V Beneyto | http://mikeux.dyndns.org
Hello, Victor & Co. Victor Martinez schrieb:
In my point of view, something is missing in the default CRUX way: Feedback to one _central_ place.
I think the point is to get feedback, doesn't really matter if it's centrilzed or not. There are lot of ways to talk with maintainers, email adresses, irc and of course the bugtracker.
You are right... it doesn't need to be one place essentially. However, I think it wouldn't harm to get posted to a list instead of one maintainer to be able to get wider review. But giving feedback could be much more simple as it is currently. If you want to file a bug or update a port, you have to manually look up the email-address of the maintainer, open some mailer, type some email, or login to flyspray or open up irc. Well, I don't even have mail configured on some fileservers... Why do we need to do so much typing when all necessary information is already in the Pkgfile? prt-get --send-update <portname> could send an updated Pkgfile to the maintainer (or to the list for public review). There is no intention to take away any responsibility of the maintainers, it should just give a hint that an update might be possible - and here is the/a solution. Git is a great feature for development, but cloning, fetching some branch, committing, pushing is still too much hand-typing, non-KISS and not suitable for non-git users.
You cannot check all the Pkgfiles in one place. -> :-( You have to check the Pkgfiles manually to find out which version can be preferrably used for an update. -> :-( You have to clone the whole collection if it's using rsync just to be able to find out the version of one port... -> :-( You can get the port when using rsync, there is a command in the portdb to get only the port instead of getting the entire collection.
mpup sounds very interesting and will at least reduce the mess with conflicting names in repos in an easy way. A wish: $ prt-get depinst mpup without much browsing, fetching sepen.rsync, pull at all... Yes, I might be a lazy typer, but I also have to get other work finished. Regards, Clemens
Clemens Koller wrote:
Hello, Victor & Co.
Hello Clemens,
Victor Martinez schrieb:
In my point of view, something is missing in the default CRUX way: Feedback to one _central_ place.
I think the point is to get feedback, doesn't really matter if it's centrilzed or not. There are lot of ways to talk with maintainers, email adresses, irc and of course the bugtracker.
You are right... it doesn't need to be one place essentially. However, I think it wouldn't harm to get posted to a list instead of one maintainer to be able to get wider review.
In my opinion I think the list can be the bugtracker. i think there are lot of ways but they aren't full used. give another way it's give more possibilities, but the point like I i said in the other mail (or at least i see in that way) is the lack of communication between users and maintainers, developers, ...)
But giving feedback could be much more simple as it is currently. If you want to file a bug or update a port, you have to manually look up the email-address of the maintainer, open some mailer, type some email, or login to flyspray or open up irc. Well, I don't even have mail configured on some fileservers...
if you want to send a mail to the maintainer, you must check the email adress, and send a mail (wich can be sent directly from the console, there isn't needed much things to setup). If doing that is hard, it can be done with a flyspray account (I see hard to don't have the possibility of using a console mail or a web client, which will avoid you the need of checking the mail address, but you will need to know who is the maintainer to fill the bug and let flyspray advice him)
Why do we need to do so much typing when all necessary information is already in the Pkgfile?
really is so much typing? I think that isn't really a problem, the solution you talk about can be more confortable (but for me, not much more than using flispray, but this is my opinion only)
prt-get --send-update <portname> could send an updated Pkgfile to the maintainer (or to the list for public review). There is no intention to take away any responsibility of the maintainers, it should just give a hint that an update might be possible - and here is the/a solution.
think that flyspray will do it for you, you can attach files, comments or whatever you want.
Git is a great feature for development, but cloning, fetching some branch, committing, pushing is still too much hand-typing, non-KISS and not suitable for non-git users.
I wasn't a git user since I joined contrib. Isn't so hard to use it (at least the basics... atm I think I didn't broke anything) and with the comunity near, help is near too, there is good people with lot of knowledge around crux and always give their hands to help others)
You cannot check all the Pkgfiles in one place. -> :-( You have to check the Pkgfiles manually to find out which version can be preferrably used for an update. -> :-( You have to clone the whole collection if it's using rsync just to be able to find out the version of one port... -> :-( You can get the port when using rsync, there is a command in the portdb to get only the port instead of getting the entire collection.
mpup sounds very interesting and will at least reduce the mess with conflicting names in repos in an easy way.
A wish: $ prt-get depinst mpup
without much browsing, fetching sepen.rsync, pull at all... Yes, I might be a lazy typer, but I also have to get other work finished.
Regards,
Clemens
Regards, Victor.
Am 11.12.2009 04:36, schrieb Clemens Koller:
Richard Pöttler schrieb:
Am 10.12.2009 21:25, schrieb Clemens Koller:
What about adding something like prt-get --push <portname> that a newly created / updated port will be published to some mailing list for review and inclusion into i.e. contrib?
You think about something like git-format-patch and git-send-email? ;)
Yes, for example. It seems like a very good idea to use git. But how many users are using git and push their changes nowadays?
Pushing the changes (or making them available) via git-send-email is only necessary for people who don't have write access to the repository.
Why isn't this part of the default setup?
Because simply the fact, that you are using CRUX doesn't imply, that you are a developer. ;)
I take care of my own (maybe five to ten) ports which get an update every once in a while. I think adding my repo to the already 50 others doesn't make sense since I don't see any advantage to have even more repos and more different versions to choose from (not knowing versions without checking it manually).
I think it would be much better to centralise the repositories to get opt and contrib more up-to-date instead of everybody is doing his/her own thing. What do you think?
Somehow I don't get, how you came to the conclusion, that you want to centralize all ports, but don't think, that it is worth to publish your own ports.
I think that a problem is that (duplicated) ports are scattered among many repos and it's hard to find out which one is the most current and which one is most likely to work for a quick and dirty update - increasing the version number, adjusting the Pkgfile a bit, check footprint and ... ?
For small changes I used "prt-get edit" (for example for the cvs port), but unfortunatelly the changes aren't available, if you switch the version number, or the maintainer updates it.
Imho it is pretty simple to become a conrtib maintainer to make your ports available for everyone.
If it's so simple, can it become a default for everyone?
For me it is important, that someone who has no clue about crux or linux is able to mess with contrib, so that I somehow can trust this collection. To become a crontib member, at least a view people got to know you, and believe, that you would do a good job.
A simple way to push changes to i.e. contrib (via a list and via review by some list members) would imo motivate more people to contribute.
I think, the problem here is, that imho noone ever tried the git-send-email way.
The problem I see in putting everything in contrib is that _everyone_ then puts his port into it and therefore (if someone puts a port there and forgets about them) ports can get unmaintained pretty soon. You could work arround this, if you say, that everyone is "allowed" to update everyone's port in conrtib. But as a developer I know, that you can pretty easyly offend other developers, if you touch their code, so this could be some kind of contraproductive.
There need be an instance to review these changes - a list.
A clearly visible version and timestamp could make it very clear which port is old an could benefit from an update.
Example: I need to update qt4 because I want to find out if the newest qtcreator can be used for sw development for a project. That is: qt-4.6.0 and qtcreator-1.3.0
What do you do? Search the portdb for 'qt'... You will get some hits: 3x qt4, qt-creator and qtcreator from different collections. (Some work was done more than once.)
Now, you need to find and decide which qt thing is good for you. Here, the mess starts:
You cannot check all the Pkgfiles in one place. -> :-( You have to check the Pkgfiles manually to find out which version can be preferrably used for an update. -> :-( You have to clone the whole collection if it's using rsync just to be able to find out the version of one port... -> :-( Something like timestamps don't really exist.
If I didn't know, which collection to take (if the port isn't already in contrib) I took one from one of the developers. But like Victor pointed out: Maybe there is a reason for all this dublicates? If you are only interressted in one port of a collection you could try out mult [1].
I hope you got what I try to suggest you.
I hope I get you. bye richi [1] http://crux.nu/Wiki/Mult
Hi, [...] Richard Pöttler wrote:
[...] If you are only interressted in one port of a collection you could try out mult [1]. The current version is named 'mpup' (which sounds better imho).
You can use this command to get the port: $ rsync -aqz mikeux.dyndns.org::ports/sepen/mpup/ mpup And as I posted on my mail, here is the updated location for the doc: http://mikeux.dyndns.org/crux/files/mpup.html Feedback and suggeriments will be welcome ;D Regards, -- Jose V Beneyto | http://mikeux.dyndns.org
participants (5)
-
Clemens Koller -
Jose V Beneyto -
Lucas Hazel -
Richard Pöttler -
Victor Martinez