--- Johannes Winkelmann <jw@tks6.net> wrote:
Hi there,
From yesterday's chatlog: [23:27] <pli> first bootstrap of crux 2.1 started... yay!
So I guess it's time to have a close look at
http://clc.morpheus.net:6999/clc/wiki?p=CruxConResults
and see what we want to and can do for 2.1 :-)
To me personally, the following point is most important: - combined httpup collection as new 'contrib'
I'll try to start testing this weekend (I'll send another mail on this). If there's anything that you'd like to be ready for 2.1, please let us know so we don't all work on the same things ;-).
Kind regards, Johannes
Excellent. I agree that the merged contrib is very important. Please let me know if prtsync needs further work. What of merging CRUX and CLC cvs on clc.morpheus.net? Has this started yet? Essentially, we need to add all ports from base and opt, and also retag contrib, no? Does Per want to put this off until he's more satisfied with his ports? Do his ports have CLC-style headers yet? Also, as prt-get and httpup will be provided on the ISO, I will try to patch up httpup to fix the url.encode/decode issue before 2.1, as I consider that kindof important. The next most pressing issue I think would have to be merging the CLC portal and CRUX website, altho I don't see it on the list it was something we talked at length about at CruxCon. I don't want to start rambling off ideas without knowing what other people are thinking of doing, but we need a plan ;) ===== Jay Dolan Software Engineer, Systems Analyst Windmill Cycles, Inc. 508.999.4000 __________________________________ Do you Yahoo!? Yahoo! Mail - Find what you need with new enhanced search. http://info.mail.yahoo.com/mail_250
To me personally, the following point is most important: - combined httpup collection as new 'contrib'
I'll try to start testing this weekend (I'll send another mail on this). [...]
Excellent. I agree that the merged contrib is very important. Please let me know if prtsync needs further work. I'd really like to have an instant notification if a port is not
The next most pressing issue I think would have to be merging the CLC portal and CRUX website, altho I don't see it on the list it was something we talked at length about at CruxCon. I don't want to start rambling off ideas without knowing what other people are thinking of doing, but we need a plan ;) Yeah, and some commitment I guess. I've heard people complaining about
Hi, On Fri, Feb 04, 2005 at 05:03:00 -0800, Jay Dolan wrote: [..] maintained anymore; as far as I can see, this is only done by the "not modified in 20 days" check, which again is rather dangerous for ports which hardly ever change (even though aterm has a beta out, and blackbox an RC ;-)). [...] the CLC wiki in #crux... I guess if we build up a new page, we should really try to make those people help us to build up the new wiki, since there really is some interest. Kind regards, Johannes -- Johannes Winkelmann mailto:jw@tks6.net Bern, Switzerland http://jw.tks6.net
On 02/04/05 21:34 Johannes Winkelmann wrote:
I'd really like to have an instant notification if a port is not maintained anymore; as far as I can see, this is only done by the "not modified in 20 days" check, which again is rather dangerous for ports which hardly ever change (even though aterm has a beta out, and blackbox an RC ;-)).
Just an idea: what about looking at the REPO file instead? Either at the REPO timestamp or at a var inside that file (maybe auto-generated by httpup?). That would 'gently invite' the contributors to update the repo (say once a month), even if by simply adjusting the 'lastgenerated' var, just to tell us the repo is still maintained as a whole. Oh, and since we're on topic, a sort of blocking mechanism by CLC maintainers could be useful to disable a port/repo that does stupid or nasty things as quick as possible.
The next most pressing issue I think would have to be merging the CLC portal and CRUX website, altho I don't see it on the list it was something we talked at length about at CruxCon. I don't want to start rambling off ideas without knowing what other people are thinking of doing, but we need a plan ;)
Yeah, and some commitment I guess. I've heard people complaining about the CLC wiki in #crux... I guess if we build up a new page, we should really try to make those people help us to build up the new wiki, since there really is some interest.
I'd like to help with the website design / coding, but some technical question has to be discussed before starting anything: - where will the site be hosted? - what kind of services are available (db, language, webserver...) - what level of integration between cvstrac / wiki / website do we plan to have? (ie, an independent wiki integrated with the website would probably be more user-friendly than the cvstrac one) Personally I'm quite busy with my last exams at the moment (until feb 24), a slightly more detailed timeline would be of great help at this point. Per, is it possible to plan / postpone the 2.1 release to a more or less defined date? Regards, Simone -- Simone Rota WEB : http://www.varlock.com Bergamo, Italy MAIL: sip@varlock.com
--- Simone Rota <sip@varlock.com> wrote:
Just an idea: what about looking at the REPO file instead? Either at the REPO timestamp or at a var inside that file (maybe auto-generated by httpup?). That would 'gently invite' the contributors to update the repo (say once a month), even if by simply adjusting the 'lastgenerated' var, just to tell us the repo is still maintained as a whole.
Oh, and since we're on topic, a sort of blocking mechanism by CLC maintainers could be useful to disable a port/repo that does stupid or nasty things as quick as possible.
Not sure how to tackle the block/filter thing off the top of my head, but I like your idea about examining the REPO file to see if a repository is being maintained. Of course, a lazy maintainer could always setup a cron job to httpup-repgen, but ..I'll see how easily I can work it in and we'll go from there :) ===== Jay Dolan Software Engineer, Systems Analyst Windmill Cycles, Inc. 508.999.4000 __________________________________ Do you Yahoo!? The all-new My Yahoo! - What will yours do? http://my.yahoo.com
On 02/04/05 21:34 Johannes Winkelmann wrote:
I'd really like to have an instant notification if a port is not maintained anymore; as far as I can see, this is only done by the "not modified in 20 days" check, which again is rather dangerous for ports which hardly ever change (even though aterm has a beta out, and blackbox an RC ;-)).
Just an idea: what about looking at the REPO file instead? Either at the REPO timestamp or at a var inside that file (maybe auto-generated by httpup?). That would 'gently invite' the contributors to update the repo (say once a month), even if by simply adjusting the 'lastgenerated' var, just to tell us the repo is still maintained as a whole. I don't think this is a good idea, since it places an additional burden on the developers (regenerate the repo even if there's no need for it). Given that I'd like to have as many people as possible taking part in
Hi, On Sun, Feb 06, 2005 at 02:08:36 +0100, Simone Rota wrote: this new contrib, I'd like to not introduce any additional complexity over maintaining a personal repo (besides the duplicates, of course). Other than that, I think I got slighly missunderstood, or maybe I didn't understand Jay's script: as far as I understood, even if the port is not in the input set anymore, the 'unmaintained' tag is only set after a certain time. It's not about measuring a maintainer's activity, it's just about marking those ports which have been dropped by a maintainer as 'unmaintained'. This cannot be seen by looking at the REPO file, since a REPO file of an active maintainer will never be older than a month; he might nevertheless drop ports. Please let me know if I'm not clear here. preprep [1] handles this by maintaining a list if ports which were synced last time, and synced this time; those is $last but not in $this are those which have to be marked 'unmaintained'. Either way, I hope I'll manage to setup a test repository this evening using preprep; I'll be in #crux during that :-). Kind regards, Johannes References: 1. http://jw.tks6.net/files/crux/preprep/preprep.sh.html -- Johannes Winkelmann mailto:jw@tks6.net Bern, Switzerland http://jw.tks6.net
--- Johannes Winkelmann <jw@tks6.net> wrote:
I don't think this is a good idea, since it places an additional burden on the developers (regenerate the repo even if there's no need for it). Given that I'd like to have as many people as possible taking part in this new contrib, I'd like to not introduce any additional complexity over maintaining a personal repo (besides the duplicates, of course).
Other than that, I think I got slighly missunderstood, or maybe I didn't understand Jay's script: as far as I understood, even if the port is not in the input set anymore, the 'unmaintained' tag is only set after a certain time. It's not about measuring a maintainer's activity, it's just about marking those ports which have been dropped by a maintainer as 'unmaintained'. This cannot be seen by looking at the REPO file, since a REPO file of an active maintainer will never be older than a month; he might nevertheless drop ports. Please let me know if I'm not clear here.
I think the way I had intended for prtsync to work (it might even have this in it right now, without looking at the script I can't recall..), was to create the merged repo in a clean directory. That is, if a port is no longer in the input from the various repositories, it will disappear the next time prtsync is run. Is this in itself problematic? ===== Jay Dolan Software Engineer, Systems Analyst Windmill Cycles, Inc. 508.999.4000 __________________________________ Do you Yahoo!? Take Yahoo! Mail with you! Get it on your mobile phone. http://mobile.yahoo.com/maildemo
As Jay replies in this thread, the missing ports will simply not be part of the new contrib anymore.
I prefer this solution, that encourages the presence only of maintained ports in private collections: I'm not much in favour of providing an additional 'unmaintained' collection (or subset of ports). I guess the idea was to keep those ports around for a while; I sometimes lose interest in port, and drop it from my repo; maybe someone would
This is another reason for which I suggested checking the contributed repsitories as a whole, I like the fact that a contributor would submit the ports in the spirit "Here's a set of ports that I currently use and maintain".
Maybe I'm too afraid the new contrib will become a large pile of junk :) Given that an activation measurement is rather easy to add (be it in the original sync script or externally), I wouldn't try to solve a problem
Hi, On Mon, Feb 07, 2005 at 00:36:25 +0100, Simone Rota wrote: [...] pick it up, if he/she likes it. This would be simplified if 'unmaintained' ports would stay around for a while (a month is definitely enough time for this). Timeline example: X drops port ---> notification --*----> Y picks it up \ \ 30 days ----------> the port is removed Note that there are two components: first, thanks to the notification, interested maintainers will learn about the "free port" and pick it up. Second, it's rather easy to do a 'cp -r /usr/ports/contrib/someport ~/build/upstream'. If a port just fades away, chances are that this happens unnoticed; even if it is noticed, to get the original port, one would have to find the original maintainer, contact him/her and get the port somehow. I'm conviced that small details like this will have a huge effect on the quality of the new contrib collection (but that's of course just an opinion :-)). that doesn't exist yet. I believe that an "update requirement" would mean that only those who want to dedicate a good amount of time will join this project ("uh, I have to guarantee fixed update cycles to join? I don't know..."); the net effect of this is the opposite of what we wanted originally: instead of creating a big collection where to look for ports, we'd add another layer (base/opt, contrib, httpups) and would end up with the very same situation we have now. But before we continue, I guess we should come to some agreement what we actually want ('we' being more than just the three of us, hopefully). Should we schedule an irc meeting to discuss that? Kind regards, Johannes P.S. I started a rewrite of preprep in ruby, which should be both quite efficient and feature packed ;-) -- Johannes Winkelmann mailto:jw@tks6.net Bern, Switzerland http://jw.tks6.net
On 02/07/05 10:43 Johannes Winkelmann wrote:
Given that an activation measurement is rather easy to add (be it in the original sync script or externally), I wouldn't try to solve a problem that doesn't exist yet. I believe that an "update requirement" would mean that only those who want to dedicate a good amount of time will join this project ("uh, I have to guarantee fixed update cycles to join? I don't know..."); the net effect of this is the opposite of what we wanted originally: instead of creating a big collection where to look for ports, we'd add another layer (base/opt, contrib, httpups) and would end up with the very same situation we have now.
Generally speaking, I'd like to see a well-working contrib repository, which encourages collaboration between maintainers ("I'm dropping portX, does anybody want to take care of it?"). I agree that could discurage occasional contributors. After all, people aiming at providing a "more maintained" collection could simply join CLC, so your view of a less strict policy for the new contrib is fine with me as well.
But before we continue, I guess we should come to some agreement what we actually want ('we' being more than just the three of us, hopefully). Should we schedule an irc meeting to discuss that?
It's OK with me, the ML provides a more flexible way (less time constraints), but IRC is probably quicker. Regards, Simone -- Simone Rota WEB : http://www.varlock.com Bergamo, Italy MAIL: sip@varlock.com
On 02/06/05 19:50 Johannes Winkelmann wrote:
Just an idea: what about looking at the REPO file instead?
I don't think this is a good idea, since it places an additional burden on the developers (regenerate the repo even if there's no need for it). Given that I'd like to have as many people as possible taking part in this new contrib, I'd like to not introduce any additional complexity over maintaining a personal repo (besides the duplicates, of course).
Well, if the private repo contains a fair number of ports I think that usual updates would keep the repo alive without the need of unnecessary refreshes. I recognise this could be annoying if one has few ports in his repo.
Other than that, I think I got slighly missunderstood, or maybe I didn't understand Jay's script: as far as I understood, even if the port is not in the input set anymore, the 'unmaintained' tag is only set after a certain time. It's not about measuring a maintainer's activity, it's just about marking those ports which have been dropped by a maintainer as 'unmaintained'. This cannot be seen by looking at the REPO file, since a REPO file of an active maintainer will never be older than a month; he might nevertheless drop ports. Please let me know if I'm not clear here.
preprep [1] handles this by maintaining a list if ports which were synced last time, and synced this time; those is $last but not in $this are those which have to be marked 'unmaintained'.
As Jay replies in this thread, the missing ports will simply not be part of the new contrib anymore. I prefer this solution, that encourages the presence only of maintained ports in private collections: I'm not much in favour of providing an additional 'unmaintained' collection (or subset of ports). This is another reason for which I suggested checking the contributed repsitories as a whole, I like the fact that a contributor would submit the ports in the spirit "Here's a set of ports that I currently use and maintain". Maybe I'm too afraid the new contrib will become a large pile of junk :) Of course, others opinion may be different. Regards, Simone -- Simone Rota WEB : http://www.varlock.com Bergamo, Italy MAIL: sip@varlock.com
Hi, On Fri, Feb 04, 2005 at 05:03:00 -0800, Jay Dolan wrote:
http://clc.morpheus.net:6999/clc/wiki?p=CruxConResults [...] Also, as prt-get and httpup will be provided on the ISO, I will try to patch up httpup to fix the url.encode/decode issue before 2.1, as I consider that kindof important. I uploaded a test version of httpup 0.4.0 (available in my repo); this one encodes files names obtained from the REPO file when used with the '--encode' switch (or '-e'). In addition, it also supports --repofile=FILENAME (-r FILENAME) to specify an alternative name for the REPO file. I'm not yet sure whether 'encode' should be the default, will have to think about that.
Use httpup --help and httpup sync --help to get started. WARNING: 0.4.0-test1 also includes the updated repgen script, which doesn't support the unfriendly HS_IGNORE variable any more. Read the following for more info: http://marc.theaimsgroup.com/?l=crux&m=109584311525991&w=2 Feedback appreciated. Kind regards, Johannes P.S. I exchanged the argument parsing, and dropped the 'mirror' command for now; also the 'copy' command always requires two arguments -- Johannes Winkelmann mailto:jw@tks6.net Bern, Switzerland http://jw.tks6.net
--- Johannes Winkelmann <jw@tks6.net> wrote:
Hi,
On Fri, Feb 04, 2005 at 05:03:00 -0800, Jay Dolan wrote:
http://clc.morpheus.net:6999/clc/wiki?p=CruxConResults
Also, as prt-get and httpup will be provided on
ISO, I will try to patch up httpup to fix the url.encode/decode issue before 2.1, as I consider
[...] the that
kindof important. I uploaded a test version of httpup 0.4.0 (available in my repo); this one encodes files names obtained from the REPO file when used with the '--encode' switch (or '-e'). In addition, it also supports --repofile=FILENAME (-r FILENAME) to specify an alternative name for the REPO file. I'm not yet sure whether 'encode' should be the default, will have to think about that.
Use httpup --help and httpup sync --help to get started.
WARNING: 0.4.0-test1 also includes the updated repgen script, which doesn't support the unfriendly HS_IGNORE variable any more. Read the following for more info:
http://marc.theaimsgroup.com/?l=crux&m=109584311525991&w=2
Feedback appreciated. Kind regards, Johannes
P.S. I exchanged the argument parsing, and dropped the 'mirror' command for now; also the 'copy' command always requires two arguments -- Johannes Winkelmann mailto:jw@tks6.net Bern, Switzerland http://jw.tks6.net
Thanks, sunshine ;* ===== Jay Dolan Software Engineer, Systems Analyst Windmill Cycles, Inc. 508.999.4000 __________________________________ Do you Yahoo!? Yahoo! Mail - Find what you need with new enhanced search. http://info.mail.yahoo.com/mail_250
On Fri, Feb 04, 2005 at 09:56:08AM +0100, Johannes Winkelmann wrote:
Hi there,
From yesterday's chatlog: [23:27] <pli> first bootstrap of crux 2.1 started... yay!
So I guess it's time to have a close look at http://clc.morpheus.net:6999/clc/wiki?p=CruxConResults and see what we want to and can do for 2.1 :-)
To me personally, the following point is most important: - combined httpup collection as new 'contrib'
hmm, to be able to do this there are one point that must happen before, or missed I something ? - merge opt / contrib, that implies the merge of the crux/clc cvs repositories or - we have to invent another name for the "new contrib" collection and we stick with base/opt/contrib kind regards Jürgen -- Juergen Daubert | mailto:jue@jue.li Korb, Germany | http://jue.li/crux
Hi, On Fri, Feb 04, 2005 at 14:47:56 +0100, Juergen Daubert wrote:
On Fri, Feb 04, 2005 at 09:56:08AM +0100, Johannes Winkelmann wrote:
Hi there,
From yesterday's chatlog: [23:27] <pli> first bootstrap of crux 2.1 started... yay!
So I guess it's time to have a close look at http://clc.morpheus.net:6999/clc/wiki?p=CruxConResults and see what we want to and can do for 2.1 :-)
To me personally, the following point is most important: - combined httpup collection as new 'contrib'
hmm, to be able to do this there are one point that must happen before, or missed I something ?
- merge opt / contrib, that implies the merge of the crux/clc cvs repositories That's true, I got side-tracked; I remember Per saying that the repo merge would probably have to wait until 2.1 is out; maybe we could start looking into the requirements for the common CVS, like where to host it etc.
In addition, I don't think it's a bad idea to start testing the scripts, to make sure we can put up the new contrib really soon once CVS is ready. Kind regards, Johannes -- Johannes Winkelmann mailto:jw@tks6.net Bern, Switzerland http://jw.tks6.net
participants (4)
-
Jay Dolan -
Johannes Winkelmann -
Juergen Daubert -
Simone Rota