gnu-arch-users
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Gnu-arch-users] Regarding pyarch future


From: Rene Schallner
Subject: Re: [Gnu-arch-users] Regarding pyarch future
Date: Sun, 8 May 2005 22:55:20 +0200
User-agent: KMail/1.8

On Sunday 08 May 2005 22:11, Mikhael Goikhman wrote:
> On 08 May 2005 10:29:00 -0500, John A Meinel wrote:
> > I think a lot of it is if we could define what "Arch" is. I know it
> > was mentioned in the past about writing actual documents. I think we
> > could discuss on the list, but probably as Migo says #arch might be
> > better.
>
> No, I didn't say anything about #arch, this is a too general channel
> with no interest in development of arch frontends.

He was talking about #arch-frontends, just for the record.  But I am not 
sure whether IRC channels would be the ideal medium for these discussions.  
One, there might be time zone issues.  On IRC all people can meet, that is 
true, but what about those on the other side of the planet who are 
asleep :)?  I understand, for clarifying issues where everybody is about 
on the same level of knowledge, this is a very effective way of 
communicating.  But in a situation where one might want to sit back and 
think about a design for a few hours, there's no point in instant 
interactive communication?  The mailing lists also provide a good 
publically available history...  But enough about that.


> > >My focus on Baz-NG is not merely a consequence of corporate policies.
> > >I personally regard it as a superior model and I am confident in the
> > >author's ability to deliver a tool whose design it as least as good
> > > as Arch, and which provides a superior user experience.
>
> It is hard to have an opinion about something that does not exist.

ACK

> But I once said you my worry about baz (that it sometimes feels like a
> dumbed down version of tla intended for svn users), so if this is the
> direction, then at least technical superiority is not obvious for me.
> The user experience may be another story, but it is personal, one likes
> the unix feel, someone else may hate it.

Double ACK :)  I personally prefer tla, too - as Tom Lord stands for 
"quality" (and conservatism, etc) - in my eyes.  So I want to stick with 
"the original".  That's just my personal preference.  I can imagine that 
many people are happy with baz.  I also understand that it seems to be 
easier to contribute to baz, which is something not to under-estimate.


> > >It just needs more interest than "it would be nice to have, but I'm
> > > not going to need it".
>
> Yes, this is the problem. People with skills and dedication are missing.

Well, I can only speak for myself: I do have (at least) some skills.  I can 
even work on the dedication thing (meaning: trying to allocate more time 
for this stuff).  I am in a funny situation right now.  There's octopy.  A 
python Qt GUI for a subset of tla's features.  The octopy project would 
hugely benefit from python bindings similar to Arch-Perl.  Actually, to 
make octopy more useful, one important thing to do would be to make it 
work with baz and not just tla.  Now I have to ask myself:  Should I hack 
something together so that everything that octopy can do now will be 
possible with baz as backend as well?  And keep on hacking until it's one 
great big mess in - say - half a year?  Somehow I prefer to take this 
opportunity of radical change and create some python library similar to 
arch-perl.  Well I don't want to say _I_ want to do it all or all on my 
own.  But I also don't want to say that I want others to do it and just 
benefit from it.  I want to say: "I _am_ going to need it.  It's not just 
a nice-to-have for me."

Now here's a stupid question:  What about cloning Arch-Perl in python?  The 
design seems to be solid, Mikhael is very convinced about that.  Maybe not 
a 100% clone but you get the idea...?  My point is:  Arch-Perl seems to 
have it all worked out already.  Having a similar API can also be a big 
plus on the documentation side of things...  
        -Rene

Attachment: pgpS5cnvEFCfP.pgp
Description: PGP signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]