kicad-developers team mailing list archive

["Dick H." <dick@...>]

Igor,

Thank you for your input. Much of this comes down to "available time"
and "personal choice". I do not have time to go beyond what I have
previously stated regarding the tags subtree. The path we are on is
well documented in my earlier post.  

Changing now would involve more than simply the repository. One would
have to formulate a clear posting in comprehensible English explaining
why the change was made and what it is.

The tags branch is primarily for Jean-Pierre anyway, as he transitions
from release candidate to release. I will probably not be involved in
that.

Everyone is the master of their own time, so voting on this will have
no effect. I don't have the time to spend on it.

Here is the posting that explains where we are at currently:

http://tech.groups.yahoo.com/group/kicad-devel/message/808


I do appreciate your concerns, and I really do not feel they are
unreasonable. However I feel they are a matter of personal choice and
limited resources. I feel they are unachievable by me as a minimum,
and since I cannot dictate how others spend their time, by the team as
a whole. In the future maybe you can find someone to snap-shot the
release candidate in the way you want for the next release. I did the
first couple, then Richard did a couple, and now that he's in medical
school I thought I would have to do it again. And in doing it, I
reconsidered the task in light of available resources and time. What
we have now works for me and probably Jean-Pierre.


My time is better spent tackling larger issues within the code, as I
offer strengths there that few others have.


Regards,

Dick




> Hello Dick!
> 
> Please imagine the situation:
> You try to quickly find something in a big repository with many tags, 
> branches and so on.
> When you see the many folders with names like "*2007-Nov", then you 
> can't see the properly sorted folders, but if folders (or files) have 
> names which can be sorted by browser (or by 'ls -l' command), then life 
> will be much easier :-)
> 
> I wont to say - do not use versions with words or special signs like 
> '@', better to use only digits, single letters, '.' or '-' simbols.
> 
> And second thing.
> Why we must invent special collation list for versions?
> Better to use clear for all naming scheme from the beginning (and in 
> all situations the same as at start).
> 
> > On the theory that anybody with a browser can show up and vote,
and that
> > this somehow impacts what actually happens, then I vote for better
zone
> > support.
> >
> > Hmmm, how long do I have to wait? I don't see it yet.
> >
> > Maybe those voting should write a constitution, and then we can
discuss
> > that and ratify it.
> >
> If you want, then you can easily make any page for voting at wiki.
> 
> > But first we should decide if we want a democracy or a republic.
(I say
> > republic.)
> >
> Not always one man (even smart) can make a good solution for entire 
> community.
> I think democracy better suited for open source projects. But this is 
> not mean that a developers must make what wants other (non
developers) :-)
> Good developers can hear others and make a conclusions - what is better.
> 
> > In the end, those doing the work get to decide. The change_log.txt
> > spells out who that is right now, hmmm, in there I see Jean-Pierre,
> > Geoff and a few others.
> >
> > I won't support any constitution that gives equal voting rights to
> > anyone with a browser. Voting rights in any constitution I support
> > would have to be proportional to the amount of development time
invested
> > by that voter.
> >
> > (Of course, I would prefer the same for my voting rights as a U.S.
> > Citizen, that they be proportional to the amount taxes a voter pays.)
> >
> > </tongue in cheek mode>
> >
> > This is the reality of open source. However, anyone should remain open
> > to good ideas, if they are expressed well and persuasively. And any
> > developer can probably be hired to perform anything at a
negotiated fee.
> 
> I think you are right in a questions regarding a free svn usage, but 
> better to use accustomed solutions from many people and documentation.
> 
> Best regards!
> --
> Igor Plyatov
>