[crux-devel] How to speed up CRUX maintenance?

Jose V Beneyto sepen at mikeux.dyndns.org
Fri Dec 11 09:01:17 UTC 2009


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/

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.
>>>> [...]
>>>>
>>>> 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 
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.
>>
>> 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 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. -> :-( 
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 
> 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 
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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.crux.nu/pipermail/crux-devel/attachments/20091211/9f8f41e3/attachment.html>


More information about the crux-devel mailing list