Re: [Tinycc-devel] Governance (Re: cleanups)

2016-10-16 Thread David Mertens 
Hello Michael,

On Sun, Oct 16, 2016 at 5:59 PM, Michael Matz  wrote:

> 
> You can't "move" tinycc anyway.
>

Of course not. There are only a handful of folks who really understand the
inner workings of tcc (you being one of them), and if they want to stick
with repo.or.cz, then that's where code will stay. Nobody can forcibly move
the project anywhere.


> 
>
> Currently I don't see the need for gate keepers (though I certainly was
> extremely frustrated during at least two periods in the past where
> low-quality non-sense was added).
>

Sure, tcc itself does not need a gatekeeper. Unwanted commits can easily be
overturned. But, since tcc does not support extensions, it implicitly
forces extensions to be maintained as forks. This is what I do with my
extended symbol table project. Keeping forks up-to-date with mob is a huge
pain. A pull-request style would make the code much, much cleaner, and thus
my job much, much easier.

I wrote a much wordier statement, but I'm trying to learn to be more terse.
See below if you want to read more. :-)
David




Consider the following tcc policy:

* Nontrivial extensions to tcc should be maintained as separate forks.

That statement is not explicitly stated anywhere, but it is consistent with
how the tcc project maintains itself. Anything outside of tcc's main
goal---fast one-pass C compiler and linker---do not belong in this project.
As a corollary, any nontrivial extension to tcc should be maintained in a
fork*.* Or, there shouldn't be any nontrivial extensions, but that's not
realistic. So, I will take that as my premise.

The current situation is very precarious for extension maintainers like me.
This precariousness has been pointed out before: https://lists.nongnu.org/
archive/html/tinycc-devel/2014-05/msg00036.html. In a related but separate
story, I started my extended symbol table work back in the fall of 2013.
When I checked back in over the summer of 2014 (when Sia was writing that
email about jiang's commits), mob had an enormous number of low-quality
line changes, and it no longer compiled on Mac, so I didn't go through the
effort of updating my fork. The situation got worse and worse until I was
saved by seyko's heroic efforts and a major pull-request on my project.

Still, my efforts to track my nearly-up-to-date fork with mob are subject
to the whims of contributors who cannot or simply do not test their commits
on multiple operating systems, or who commit a series of half-completed
commits that break git-bisect. Or, suppose somebody contributes high
quality but unwanted code that touches something I've altered. Even if that
commit is later reverted---keeping tcc slim and the final state of the
sources in good shape---I still need to merge the initial commit and its
revert. I would be much, much happier if these reverted commits were never
added in the first place.

-- 
 "Debugging is twice as hard as writing the code in the first place.
  Therefore, if you write the code as cleverly as possible, you are,
  by definition, not smart enough to debug it." -- Brian Kernighan
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel

Re: [Tinycc-devel] Governance (Re: cleanups)

2016-10-16 Thread Michael Matz 

Hi,

On Sun, 16 Oct 2016, avih wrote:

Overall, I'd vote to move tinycc to github, with the caveat that it'd be 
nice to also have an external archive of all the discussions, issues, 
reviews, etc.


You can't "move" tinycc anyway.  If people want to start using github: 
more power to them, repo.or.cz won't go away.


My 2 cents: the mob branch is the very reason I started contributing to 
tinycc; if it wouldn't exist I wouldn't have cared.  So, there's that. 
That advantage is of course a disadvantage as well, as always.  There are 
similar advantages and disadvantages with github as well: e.g. moving 
discussions to some web-crap would be counter-productive.  OTOH facilities 
like travis are nice.  The possibility to maintain a website/wiki at the 
same place is also nice.


Don't know.  Currently I don't see the need for gate keepers (though I 
certainly was extremely frustrated during at least two periods in the past 
where low-quality non-sense was added).



Ciao,
Michael.

___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel

Re: [Tinycc-devel] Governance (Re: cleanups)

2016-10-16 Thread David Mertens 
avih, one more note:

The big problem is not how we handle our discussions on the mailing list,
it's when a person does not respect the open source governance and pushes a
bunch of unsolicited commits without *any* discussion. This has happened
many times over the last three or four years. Pull requests would let us
manage those, mostly by preventing them when they do not fit the goals of
the project (i.e. unwanted extensions to the compiler).

FWIW, I don't think this would stifle the current discussion of patches
that occurs on the mailing list.

David

On Sun, Oct 16, 2016 at 12:53 PM, David Mertens 
wrote:

> On Sun, Oct 16, 2016 at 11:26 AM, avih  wrote:
>
>> > I am less concerned about losing this kind of meta-info, as I expect
>> we would continue discussion primarily on the mailing list.
>>
>> Would you/we?
>>
>> The initial suggestion mentioned pull-requests as being easier to handle
>> than discussing patches over mailing lists - to which personally I agree
>> (though I don't claim everyone should agree to that).
>>
>> PRs carry discussions - which typically happen on the PR "page", on
>> github and the github hosting would also be quite more useful if people can
>> report bugs via github.
>>
>
> I had a vision in which the pull requests lived on github, but discussion
> of merging (or not) would take place on the mailing list. Even if we don't
> use the github facilities for discussion, just having a system for managing
> pull requests is a big win, in my book.
>
> That said, I think we can set up email notifications so that any bug
> notifications or pull requests would send an email to the mailing list. In
> that case, replies would go back to the PR/bug discussion, so we would have
> a synchronized discussion.
>
>
>> Otherwise, if there's no intention to use the github facilities which
>> make collaboration easier and more visible, what's the point of moving to
>> github? Just a different git-repo host?
>>
>
> Having a system for managing multiple pull-requests would be a big win. In
> addition, and probably more importantly, it's possible to set up travis and
> appveyor testing *on pull requests*, so we could get integration testing
> even *before* pulling in the code.
>
> David
>
> --
>  "Debugging is twice as hard as writing the code in the first place.
>   Therefore, if you write the code as cleverly as possible, you are,
>   by definition, not smart enough to debug it." -- Brian Kernighan
>



-- 
 "Debugging is twice as hard as writing the code in the first place.
  Therefore, if you write the code as cleverly as possible, you are,
  by definition, not smart enough to debug it." -- Brian Kernighan
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel

Re: [Tinycc-devel] Governance (Re: cleanups)

2016-10-16 Thread David Mertens 
Hey everyone,

I owe an apology to grishka. Grishka, I may not like how you currently
handle unwanted pushes (often by revert without discussion), but I don't
think you'd be half as reactive if we kept unwanted pushes out of the main
repo in the first place. In that case we'd get the best of your efforts
without the annoying parts, which I think would be a win for everyone.

Sorry,
David

On Sat, Oct 15, 2016 at 12:58 PM, David Mertens 
wrote:

> Hello all,
>
> Jean-Claude articulates concerns I have felt as well. Sometimes we'll get
> a series of ridiculous commits from hitherto unknown programmers trying to
> "help". Sometimes we get commits from people trying to extend tcc's
> behavior beyond its core intent. Other times core hackers (OK, mostly just
> grishka) push a series of commits, some of which are brilliant and others
> of which are inappropriate and highly opinionated. (Overall I am glad to
> have grishka's contributions, but they always seem to come with a bit of
> avoidable pain.)
>
> I would be happy to see this project moved *out* of a mob branch on
> repo.or.cz, and managed on a site that provides facilities for
> collaborative programming. My experience is with github, but I don't care
> if it's there or somewhere else. I would just like to have contributions
> submitted as pull requests, and managed by one or two gatekeepers. If there
> is significant interest in this, I'm sure that we can start a grass-roots
> group. This is open source, after all. :-)
>
> So, are Jean-Claude and I mostly alone in this, or do others feel
> similarly?
>
> David
>
> On Sat, Oct 1, 2016 at 5:09 PM, Jean-Claude Beaudoin <
> jean.claude.beaud...@gmail.com> wrote:
>
>>
>>
>> On Sat, Oct 1, 2016 at 3:03 PM, grischka  wrote:
>>
>>> Hey all,
>>>
>>> I did push some cleanups to prepare for a release 0.9.27,
>>> eventually.  Just if you wonder what's the point of that.
>>>
>>
>> I was indeed wondering if we would see a new release sometime soon
>> considering that the latest one dates from a few years ago. That is
>> answered now.
>>
>> That also brought me to wonder how that release process would be
>> managed and effectively executed. Could you elaborate on that
>> point please?
>>
>> One fact that gives me serious pause in that area is that the
>> majority of the commits I contributed in the last few days were
>> simply reverted thus reintroducing the problems they tried to fix
>> or introducing some new lesser one when the revert was partial.
>> A good number of others recent commits have been also similarly
>> impacted.
>>
>> That leaves me quite puzzled.
>>
>> My intent was to use libtcc as a significant part of the back-end
>> of MKCL . But after some study of
>> the TCC source code I came
>> to the realization that there were a number of serious technical
>> problems with that. And now there is this governance aspect
>> being raised.  All that push me to reconsider my approach.
>>
>> Regards,
>>
>> Jean-Claude Beaudoin
>>
>>
>> ___
>> Tinycc-devel mailing list
>> Tinycc-devel@nongnu.org
>> https://lists.nongnu.org/mailman/listinfo/tinycc-devel
>>
>>
>
>
> --
>  "Debugging is twice as hard as writing the code in the first place.
>   Therefore, if you write the code as cleverly as possible, you are,
>   by definition, not smart enough to debug it." -- Brian Kernighan
>



-- 
 "Debugging is twice as hard as writing the code in the first place.
  Therefore, if you write the code as cleverly as possible, you are,
  by definition, not smart enough to debug it." -- Brian Kernighan
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel

Re: [Tinycc-devel] Governance (Re: cleanups)

2016-10-16 Thread David Mertens 
On Sun, Oct 16, 2016 at 11:26 AM, avih  wrote:

> > I am less concerned about losing this kind of meta-info, as I expect we
> would continue discussion primarily on the mailing list.
>
> Would you/we?
>
> The initial suggestion mentioned pull-requests as being easier to handle
> than discussing patches over mailing lists - to which personally I agree
> (though I don't claim everyone should agree to that).
>
> PRs carry discussions - which typically happen on the PR "page", on github
> and the github hosting would also be quite more useful if people can report
> bugs via github.
>

I had a vision in which the pull requests lived on github, but discussion
of merging (or not) would take place on the mailing list. Even if we don't
use the github facilities for discussion, just having a system for managing
pull requests is a big win, in my book.

That said, I think we can set up email notifications so that any bug
notifications or pull requests would send an email to the mailing list. In
that case, replies would go back to the PR/bug discussion, so we would have
a synchronized discussion.


> Otherwise, if there's no intention to use the github facilities which make
> collaboration easier and more visible, what's the point of moving to
> github? Just a different git-repo host?
>

Having a system for managing multiple pull-requests would be a big win. In
addition, and probably more importantly, it's possible to set up travis and
appveyor testing *on pull requests*, so we could get integration testing
even *before* pulling in the code.

David

-- 
 "Debugging is twice as hard as writing the code in the first place.
  Therefore, if you write the code as cleverly as possible, you are,
  by definition, not smart enough to debug it." -- Brian Kernighan
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel

Re: [Tinycc-devel] Governance (Re: cleanups)

2016-10-16 Thread Christian Jullien 
Well, I’m not sure savannah allows this, but one way to limit anarchical and 
gratuitous commits is to refuse (with help of a pre-commit hook, see 
https://git-scm.com/book/en/v2/Customizing-Git-Git-Hooks) any commit that does 
not refer to a ticket.

This way, when you want to do something you must before enter a ticket or refer 
to an existing ticket

 


 
<http://savannah.nongnu.org/bugs/?group=tinycc&func=browse&set=open&msort=0&advsrch=0&morder=bug_id%3c&order=bug_id#results>
 Item ID http://savannah.nongnu.org/images/Savannah.theme/arrows/up.png

 
<http://savannah.nongnu.org/bugs/?group=tinycc&func=browse&set=open&msort=0&advsrch=0&morder=bug_id%3c&order=summary#results>
 Summary

 
<http://savannah.nongnu.org/bugs/?group=tinycc&func=browse&set=open&msort=0&advsrch=0&morder=bug_id%3c&order=resolution_id#results>
 Status

 
<http://savannah.nongnu.org/bugs/?group=tinycc&func=browse&set=open&msort=0&advsrch=0&morder=bug_id%3c&order=assigned_to#results>
 Assigned to

 
<http://savannah.nongnu.org/bugs/?group=tinycc&func=browse&set=open&msort=0&advsrch=0&morder=bug_id%3c&order=date#results>
 Submitted on


 #6

 <http://savannah.nongnu.org/bugs/?48900> FreeBSD fails with -run

None

None



 

$ git commit –m “Fix std library path with –run on FreeBSD”

Git pre-commit hook error: commit string does not refer to a ticket

 

$ git commit –m “Fix std library path with –run on FreeBSD, refs #6”

 

This is something redmine (http://www.redmine.org/) can do for example. 

 

 

From: Tinycc-devel [mailto:tinycc-devel-bounces+eligis=orange...@nongnu.org] On 
Behalf Of David Mertens
Sent: dimanche 16 octobre 2016 15:25
To: avih; tinycc-devel@nongnu.org
Subject: Re: [Tinycc-devel] Governance (Re: cleanups)

 

I am less concerned about losing this kind of meta-info, as I expect we would 
continue discussion primarily on the mailing list. Mailing lists seem to me to 
be much better venues for discussion than the facilities provided by github.

My bigger concern is: who would be the project managers? Who would manage pull 
requests? I would volunteer for some of it, but I could only guarantee 
responsiveness during winter and summer breaks, and would want to hand off 
responsibility during my school's semesters. Are others willing to step up? If 
not, we shouldn't move to a github/pull-requests workflow.

David

 

On Sun, Oct 16, 2016 at 7:13 AM, avih  wrote:

I also think github could be good to tinycc.

 

The obvious reasons were mentioned: Arguably easier and more open 
collaboration, bug reports and tracking, automatic builds and tests, possibly 
better exposure to other people, etc.

 

There's one thing though which github doesn't make easy as far as I know: all 
the discussions, comments, code reviews, tagging (of issues) are not easy to 
export as far as I know. The project's wiki pages are in a git repo which the 
project owns (separate from the project's code), but as far as I know all the 
text which people enter (other than at commits) is available at most only via 
some github API. This is a lot of info which would be a shame to lose if github 
closes its doors tomorrow.

 

While github is definitely used as the main host for some big projects, and 
while I maintain some projects on github myself (on my own and with others), 
I'd be much more comfortable if I knew all discussions/comments/etc are being 
mirrored to an external host under the project's control, even if only in a 
read-only format.

 

FWIW, I know such export tools exist, but I haven't used them and I don't know 
how good they are.

 

Overall, I'd vote to move tinycc to github, with the caveat that it'd be nice 
to also have an external archive of all the discussions, issues, reviews, etc.

 

On Sunday, October 16, 2016 1:39 PM, Daniel Glöckner  wrote:

 

Hi,

on Github we could use Travis to run tests after every commit.
We could also use Qemu there to check if the other architectures still
work. It might also serve as an example how to setup a cross development
environment with TinyCC.

Best regards.

  Daniel



___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel

 


___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel




-- 

 "Debugging is twice as hard as writing the code in the first place.
  Therefore, if you write the code as cleverly as possible, you are,
  by definition, not smart enough to debug it." -- Brian Kernighan

___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel

Re: [Tinycc-devel] Governance (Re: cleanups)

2016-10-16 Thread David Mertens 
I am less concerned about losing this kind of meta-info, as I expect we
would continue discussion primarily on the mailing list. Mailing lists seem
to me to be much better venues for discussion than the facilities provided
by github.

My bigger concern is: who would be the project managers? Who would manage
pull requests? I would volunteer for some of it, but I could only guarantee
responsiveness during winter and summer breaks, and would want to hand off
responsibility during my school's semesters. Are others willing to step up?
If not, we shouldn't move to a github/pull-requests workflow.

David

On Sun, Oct 16, 2016 at 7:13 AM, avih  wrote:

> I also think github could be good to tinycc.
>
> The obvious reasons were mentioned: Arguably easier and more open
> collaboration, bug reports and tracking, automatic builds and tests,
> possibly better exposure to other people, etc.
>
> There's one thing though which github doesn't make easy as far as I know:
> all the discussions, comments, code reviews, tagging (of issues) are not
> easy to export as far as I know. The project's wiki pages are in a git repo
> which the project owns (separate from the project's code), but as far as I
> know all the text which people enter (other than at commits) is available
> at most only via some github API. This is a lot of info which would be a
> shame to lose if github closes its doors tomorrow.
>
> While github is definitely used as the main host for some big projects,
> and while I maintain some projects on github myself (on my own and with
> others), I'd be much more comfortable if I knew all
> discussions/comments/etc are being mirrored to an external host under the
> project's control, even if only in a read-only format.
>
> FWIW, I know such export tools exist, but I haven't used them and I don't
> know how good they are.
>
> Overall, I'd vote to move tinycc to github, with the caveat that it'd be
> nice to also have an external archive of all the discussions, issues,
> reviews, etc.
>
>
> On Sunday, October 16, 2016 1:39 PM, Daniel Glöckner 
> wrote:
>
>
> Hi,
>
> on Github we could use Travis to run tests after every commit.
> We could also use Qemu there to check if the other architectures still
> work. It might also serve as an example how to setup a cross development
> environment with TinyCC.
>
> Best regards.
>
>   Daniel
>
>
> ___
> Tinycc-devel mailing list
> Tinycc-devel@nongnu.org
> https://lists.nongnu.org/mailman/listinfo/tinycc-devel
>
>
>
> ___
> Tinycc-devel mailing list
> Tinycc-devel@nongnu.org
> https://lists.nongnu.org/mailman/listinfo/tinycc-devel
>
>


-- 
 "Debugging is twice as hard as writing the code in the first place.
  Therefore, if you write the code as cleverly as possible, you are,
  by definition, not smart enough to debug it." -- Brian Kernighan
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel

Re: [Tinycc-devel] Governance (Re: cleanups)

2016-10-16 Thread Daniel Glöckner 
Hi,

on Github we could use Travis to run tests after every commit.
We could also use Qemu there to check if the other architectures still
work. It might also serve as an example how to setup a cross development
environment with TinyCC.

Best regards.

  Daniel

___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel

Re: [Tinycc-devel] Governance (Re: cleanups)

2016-10-15 Thread Chris Marshall 

I would like to have the ability to contribute to
tcc in a more structured fashion.  I have been working
to get tcc to build/run on cygwin but only in private work.

Without a way to publicly contribute to tcc development
I have little hope of having other contributers to assist
with the cygwin work.

Without being able to run tcc and libtcc on cygwin, I
am unable to make use of or contribute to tcc development
directly.  It is nice to see that there may be a new
official master release soon...  :-)

--Chris

On 10/15/2016 12:58, David Mertens wrote:

Hello all,

Jean-Claude articulates concerns I have felt as well. Sometimes we'll 
get a series of ridiculous commits from hitherto unknown programmers 
trying to "help". Sometimes we get commits from people trying to 
extend tcc's behavior beyond its core intent. Other times core hackers 
(OK, mostly just grishka) push a series of commits, some of which are 
brilliant and others of which are inappropriate and highly 
opinionated. (Overall I am glad to have grishka's contributions, but 
they always seem to come with a bit of avoidable pain.)


I would be happy to see this project moved /out/ of a mob branch on 
repo.or.cz , and managed on a site that provides 
facilities for collaborative programming. My experience is with 
github, but I don't care if it's there or somewhere else. I would just 
like to have contributions submitted as pull requests, and managed by 
one or two gatekeepers. If there is significant interest in this, I'm 
sure that we can start a grass-roots group. This is open source, after 
all. :-)


So, are Jean-Claude and I mostly alone in this, or do others feel 
similarly?


David

On Sat, Oct 1, 2016 at 5:09 PM, Jean-Claude Beaudoin 
> wrote:




On Sat, Oct 1, 2016 at 3:03 PM, grischka mailto:gris...@gmx.de>> wrote:

Hey all,

I did push some cleanups to prepare for a release 0.9.27,
eventually.  Just if you wonder what's the point of that.


I was indeed wondering if we would see a new release sometime soon
considering that the latest one dates from a few years ago. That is
answered now.

That also brought me to wonder how that release process would be
managed and effectively executed. Could you elaborate on that
point please?

One fact that gives me serious pause in that area is that the
majority of the commits I contributed in the last few days were
simply reverted thus reintroducing the problems they tried to fix
or introducing some new lesser one when the revert was partial.
A good number of others recent commits have been also similarly
impacted.

That leaves me quite puzzled.

My intent was to use libtcc as a significant part of the back-end
of MKCL . But after some
study of the TCC source code I came
to the realization that there were a number of serious technical
problems with that. And now there is this governance aspect
being raised.  All that push me to reconsider my approach.

Regards,

Jean-Claude Beaudoin


___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org 
https://lists.nongnu.org/mailman/listinfo/tinycc-devel





--
 "Debugging is twice as hard as writing the code in the first place.
  Therefore, if you write the code as cleverly as possible, you are,
  by definition, not smart enough to debug it." -- Brian Kernighan


___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel


___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel

Re: [Tinycc-devel] Governance (Re: cleanups)

2016-10-15 Thread Christian Jullien 
Gentlemen,

I will don’t blame anybody here, especially Grischka that does an amazing job.

 

The real issue I see with most computer languages having ports on different 
systems and processors is that they lack of compressive test suite and tcc is 
not an exception.

Here, I’m not talking about the few tests that exist in tinycc/test/.

 

If someone pushes a commit, how and when will we see that it has broken a major 
piece of code, like gawk, on Aarch64 or my OpenLisp compiler on Windows x64 for 
example?

 

The major difficulty with a language is that it is used to compile programs we 
have never seen.

Ideally, we should have a farm (as https://gcc.gnu.org/wiki/CompileFarm) that 
nightly compiles tcc on ALL supported platforms THEN uses this tcc version to 
compile a selected number of open source project that are known to compile with 
tcc THEN run test suite of those projects.

That’s why I’m trying to help this project by compiling, running tests, 
compiling my own Lisp on as much machine/system I have access on.

Unless obvious, I avoid to push anything that may break something. I prefer to 
ask.

 

For a project like this, we should never remove something, especially line of 
code, files or tests unless we are absolutely sure. If something is there, this 
is probably for a very good reason. The good attitude is at least to ping 
community about a questionable feature.

 

For every commit I make for my Lisp, I compile OpenLisp with 17 
compiler/version/options just on Windows and for each of them I run 3 lines 
of test.

Every 3 month or so, I build OpenLisp on:

 

openlisp-10.2.0-AIX-powerpc.tar.gz

openlisp-10.2.0-Darwin-i386.tar.gz

openlisp-10.2.0-Darwin-powerpc.tar.gz

openlisp-10.2.0-Darwin-x86_64.tar.gz

openlisp-10.2.0-FreeBSD-arm.tar.gz

openlisp-10.2.0-FreeBSD-x86_64.tar.gz

openlisp-10.2.0-Linux-armv6l.tar.gz

openlisp-10.2.0-Linux-armv7l.tar.gz

openlisp-10.2.0-Linux-i686.tar.gz

openlisp-10.2.0-Linux-powerpc.tar.gz

openlisp-10.2.0-Linux-powerpc64.tar.gz

openlisp-10.2.0-Linux-powerpc64le.tar.gz

openlisp-10.2.0-Linux-sparc.tar.gz

openlisp-10.2.0-Linux-sparc64.tar.gz

openlisp-10.2.0-Linux-x86_64.tar.gz

openlisp-10.2.0-NetBSD-i686.tar.gz

openlisp-10.2.0-NetBSD-x86_64.tar.gz

openlisp-10.2.0-OpenBSD-i386.tar.gz

openlisp-10.2.0-OpenBSD-x86_64.tar.gz

openlisp-10.2.0-QNX-i386.tar.gz

openlisp-10.2.0-SunOS-i386.tar.gz

openlisp-10.2.0-SunOS-sparc.tar.gz

openlisp-10.2.0-SunOS-sparc64.tar.gz

openlisp-10.2.0-SunOS-x86_64.tar.gz

openlisp-10.2.0-mingw64.zip

openlisp-10.2.0-win32-x86.zip

openlisp-10.2.0-win64-ia64.zip

openlisp-10.2.0-win64-x86.zip

openlisp-10.3.0-FreeBSD-arm.tar.gz

openlisp-10.3.0-Linux-mips.tar.gz

openlisp-10.3.0-Linux-mips64.tar.gz

openlisp-10.3.0-Linux-mips64el.tar.gz

openlisp-10.3.0-Linux-mipsel.tar.gz

openlisp-10.3.0-mingw64.zip

openlisp-10.3.0-win32-x86.zip

openlisp-10.3.0-win64-ia64.zip

openlisp-10.3.0-win64-x86.zip

 

From: Tinycc-devel [mailto:tinycc-devel-bounces+eligis=orange...@nongnu.org] On 
Behalf Of David Mertens
Sent: samedi 15 octobre 2016 18:58
To: tinycc-devel@nongnu.org
Subject: [Tinycc-devel] Governance (Re: cleanups)

 

Hello all,

Jean-Claude articulates concerns I have felt as well. Sometimes we'll get a 
series of ridiculous commits from hitherto unknown programmers trying to 
"help". Sometimes we get commits from people trying to extend tcc's behavior 
beyond its core intent. Other times core hackers (OK, mostly just grishka) push 
a series of commits, some of which are brilliant and others of which are 
inappropriate and highly opinionated. (Overall I am glad to have grishka's 
contributions, but they always seem to come with a bit of avoidable pain.)

I would be happy to see this project moved out of a mob branch on repo.or.cz, 
and managed on a site that provides facilities for collaborative programming. 
My experience is with github, but I don't care if it's there or somewhere else. 
I would just like to have contributions submitted as pull requests, and managed 
by one or two gatekeepers. If there is significant interest in this, I'm sure 
that we can start a grass-roots group. This is open source, after all. :-)

 

So, are Jean-Claude and I mostly alone in this, or do others feel similarly?

 

David

 

On Sat, Oct 1, 2016 at 5:09 PM, Jean-Claude Beaudoin 
 wrote:

 

 

On Sat, Oct 1, 2016 at 3:03 PM, grischka  wrote:

Hey all,

I did push some cleanups to prepare for a release 0.9.27,
eventually.  Just if you wonder what's the point of that.

 

I was indeed wondering if we would see a new release sometime soon

considering that the latest one dates from a few years ago. That is

answered now.

 

That also brought me to wonder how that release process would be

managed and effectively executed. Could you elaborate on that

point please?

 

One fact that gives me serious pause in that area is that the

majority of the commits I contributed in the last few days

[Tinycc-devel] Governance (Re: cleanups)

2016-10-15 Thread David Mertens 
Hello all,

Jean-Claude articulates concerns I have felt as well. Sometimes we'll get a
series of ridiculous commits from hitherto unknown programmers trying to
"help". Sometimes we get commits from people trying to extend tcc's
behavior beyond its core intent. Other times core hackers (OK, mostly just
grishka) push a series of commits, some of which are brilliant and others
of which are inappropriate and highly opinionated. (Overall I am glad to
have grishka's contributions, but they always seem to come with a bit of
avoidable pain.)

I would be happy to see this project moved *out* of a mob branch on
repo.or.cz, and managed on a site that provides facilities for
collaborative programming. My experience is with github, but I don't care
if it's there or somewhere else. I would just like to have contributions
submitted as pull requests, and managed by one or two gatekeepers. If there
is significant interest in this, I'm sure that we can start a grass-roots
group. This is open source, after all. :-)

So, are Jean-Claude and I mostly alone in this, or do others feel similarly?

David

On Sat, Oct 1, 2016 at 5:09 PM, Jean-Claude Beaudoin <
jean.claude.beaud...@gmail.com> wrote:

>
>
> On Sat, Oct 1, 2016 at 3:03 PM, grischka  wrote:
>
>> Hey all,
>>
>> I did push some cleanups to prepare for a release 0.9.27,
>> eventually.  Just if you wonder what's the point of that.
>>
>
> I was indeed wondering if we would see a new release sometime soon
> considering that the latest one dates from a few years ago. That is
> answered now.
>
> That also brought me to wonder how that release process would be
> managed and effectively executed. Could you elaborate on that
> point please?
>
> One fact that gives me serious pause in that area is that the
> majority of the commits I contributed in the last few days were
> simply reverted thus reintroducing the problems they tried to fix
> or introducing some new lesser one when the revert was partial.
> A good number of others recent commits have been also similarly
> impacted.
>
> That leaves me quite puzzled.
>
> My intent was to use libtcc as a significant part of the back-end
> of MKCL . But after some study of
> the TCC source code I came
> to the realization that there were a number of serious technical
> problems with that. And now there is this governance aspect
> being raised.  All that push me to reconsider my approach.
>
> Regards,
>
> Jean-Claude Beaudoin
>
>
> ___
> Tinycc-devel mailing list
> Tinycc-devel@nongnu.org
> https://lists.nongnu.org/mailman/listinfo/tinycc-devel
>
>


-- 
 "Debugging is twice as hard as writing the code in the first place.
  Therefore, if you write the code as cleverly as possible, you are,
  by definition, not smart enough to debug it." -- Brian Kernighan
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel