Distrowatch > linux

Zbigniew Łuszpiński zbiggy at o2.pl
Sun Jul 17 20:11:49 UTC 2005


> On Sun, Jul 17, 2005 at 12:17:06PM +0200, Zbigniew ?uszpi?ski wrote:
> > > A couple a things:
> > >
> > > * Linux module is normally well maintained.
> >
> > It's obvious. Everybody needs it.
>
> If 30 mins after the release has been broadcasted, you update the module in
> new (for the sake of the example) and the maintainer -believe me, there is
> one, though maybe you don't know who, but you can get to know if you drop
> in #lunar or check for yourself the old commits- hasn't had a sec to review
> it, it can wait a little more. My point is more towards asking you to wait
> a little more before submitting well maintained modules, since most
> probably the dev is already taking care of it.

Speedy zbiggy, the fastest module updater on wild west linux used to say:

Keeping fresh makes lunar atractive. Instant (but tested!) updates allows 
lunar be the most up to date distro on the planet. I never posted broken 
patch. It was idea ((c) by sheriff sofar) long time ago to make a list of 
modules explictly updated by devels, but such list was never made available 
for public. So what is not forbidden is allowed. I'm advanced at C/C++ 
programming and can see what code does and how far changes go. Minor linux 
updates are very short so reading deeply changelogs and code takes minutes, 
the rest takes building and checking (never send a patch or module to 
svn->new without using it by myself).

I had idea how to resolve such 'module maintaining conflicts' but will not say 
any word more because sofar will hang me on the highest branch of svn 
tree. :-D

OK. If this linux-2.6 module belongs to you I will remember to not post 
updates to svn. I do not look at commits log, never looked for so do not know 
where it is. Before I send to svn->new I do lunar update, svn co, browse 
lunar-linux homepage. I'm thinking I offload devels in this way.

> > > Would be better if you kept track of more unmaintained modules.
> >
> > They are tracked. But their life ends in svn->new and my zlocal. I
> > updated to current version modules I use. If even these modules are not
> > imported to moonbase I see no sense of updating other. Popular modules
> > like linux have chance to be in moonbase. I maintain modules which I use.
> > Kernel is one of such modules. I do module updates for myself and drop
> > them to lunar svn also. I can keep them for myself only if you wish.
>
> That is not what I meant.

Sorry for misunderstanding.

> > > Obviously, I am not saying your  submission is not welcomed ;)))))
> >
> > ??? Thats strange. Your mail have rather opposite meaning.
>
> Not really. I'm just asking you to take a little more time before
> submitting to new.

OK. Will keep them in zlocal. I like new soft so make immediatly new module 
for myself (if it is not already in moonbase). I do not use computer 24/7 so 
update module only if nobody did it yet.

> > OK. I was not sure if you see svn->new commits. But if commit changelog
> > is tracked - no more update posts.
>
> Thanks.
>
> > > Yet, if by any chance, something like Linux had been left behind for a
> > > good while, I would think it would be reasonable to knock on the door
> > > and say "¡hey, bump it!"
> >
> > ...and the answer usually is "have no time". Most modules have no
> > personal maintainer field so such contact is not possible.
>
> Again, #lunar is open. If someone has no time, you will see it not bumped.
> Therefore you could request the bump yourself, as I have pointed out above.

I do not like IRC (as a technology, not people) . Was at #lunar only once, was 
nice. Maybe drop in in the future for a while to ask what's new. Maybe then 
someone will tell me how lunar is organized as community, so will not do 
something correct but unexpected in the future.

> Ciao,
> nestu.

greets,
Zbigniew 'zbiggy' Luszpinski


More information about the Lunar-dev mailing list