Considering the amount of work happening in 2f30 i decided it will be
easier for me to send patches there from now on.
On Sun, Jul 6, 2014 at 11:31 PM, Bigby James wrote:
>> I don't see Ari whining over this, so why would you care? If you care about
>> the project and the direction it is taking,
> I don't see Ari whining over this, so why would you care? If you care about
> the project and the direction it is taking, then start a technical discussion
> or
> even better demonstrate your ideas with patches!
>
> I am not here to satisfy all your needs or even provide context that I deem
>
On Sun, Jul 06, 2014 at 09:33:29AM -0500, Bigby James wrote:
> I can't speak for Dzen, but the wording of your first message in the thread
> gave
> me the same impression. We basically have two messages in the discussion
> thread
> to work with: One from the original author anouncing the project,
On 07/06, Dimitris Papastamos wrote:
> On Sat, Jul 05, 2014 at 09:30:25PM +0200, Džen wrote:
> > On Sat, Jul 5, 2014 at 11:35 AM, Dimitris Papastamos wrote:
> > > I've forked scron[0] [...]
> >
> > Why fork scron if you could just provide useful patches to the original
> > author?
>
> Why do yo
On Sun, Jul 06, 2014 at 12:16:38PM +0200, Džen wrote:
> Yes. That's why I was asking, I wanted to know the reason.
It was purely because the original author did not feel like having
duplicate code around, which I explained in my first e-mail. He was not
going to drive the project in a different d
On Sun, Jul 6, 2014 at 12:02 PM, Dimitris Papastamos wrote:
> If you had, you would have seen that I already had merged ~20 patches
> into the original repo which renders your question useless.
Why useless? I was just wondering about the actual reason. I pulled
scron from the original repo to try
On Sun, Jul 06, 2014 at 11:57:18AM +0200, Džen wrote:
> On Sun, Jul 6, 2014 at 11:13 AM, Dimitris Papastamos wrote:
> > And please next time look at the actually git history of the project
> > before you jump in talking bs.
> I did look at the git history, this doesn't change the reason why I
> w
On Sun, Jul 6, 2014 at 11:13 AM, Dimitris Papastamos wrote:
> And please next time look at the actually git history of the project
> before you jump in talking bs.
I did look at the git history, this doesn't change the reason why I
was asking. I was just wondering. Jump in talking bullshit. Yeah,
On Sat, Jul 05, 2014 at 09:30:25PM +0200, Džen wrote:
> On Sat, Jul 5, 2014 at 11:35 AM, Dimitris Papastamos wrote:
> > I've forked scron[0] [...]
>
> Why fork scron if you could just provide useful patches to the original
> author?
And please next time look at the actually git history of the p
On Sat, Jul 05, 2014 at 09:30:25PM +0200, Džen wrote:
> On Sat, Jul 5, 2014 at 11:35 AM, Dimitris Papastamos wrote:
> > I've forked scron[0] [...]
>
> Why fork scron if you could just provide useful patches to the original
> author?
Why do you assume that?
I made a number of patches, I notifie
Džen writes:
> Why fork scron if you could just provide useful patches to the
> original author?
To expand further on FRIGN's reply, forking with Git is not as
destructive as it would be with, say, CVS or SVN. There are standard
tools that can quite easily integrate the forked upstream back to
mai
On Sat, 5 Jul 2014 21:30:25 +0200
Džen wrote:
> Why fork scron if you could just provide useful patches to the original
> author?
Because 2f30 > ∞
No, seriously: With git, forking is a very appropriate form of working
on something. Waiting for patches to be applied, especially if they're
drama
On Sat, Jul 5, 2014 at 11:35 AM, Dimitris Papastamos wrote:
> I've forked scron[0] [...]
Why fork scron if you could just provide useful patches to the original author?
Nice! Thanks a lot.
I've made an AUR package for scron btw:
https://aur.archlinux.org/packages/scron-git
On Sat, Jul 05, 2014 at 12:52:05PM +0300, Ari Malinen wrote:
> Maybe something like this:
> --- /home/defer/temp/scron/crond.c 2014-07-05 12:16:11.917457442 +0300
> +++ crond.c 2014-
On Sat, Jul 05, 2014 at 12:52:05PM +0300, Ari Malinen wrote:
> Maybe something like this:
Nice! Applied it just now.
I only removed the debug message in matchentries().
Maybe something like this:
--- /home/defer/temp/scron/crond.c 2014-07-05 12:16:11.917457442 +0300
+++ crond.c 2014-07-05 12:47:43.147434577 +0300
@@ -23,6 +23,7 @@
struct range {
int low;
int high;
+ int div;
};
struct ctabentry {
@@ -150,12 +151,15 @@ matchentry(
On Sat, Jul 05, 2014 at 11:41:00AM +0400, Jack L. Frost wrote:
> No */n for “every n ”?
> Pretty much useless without that if you ever need a command to be run every
> five minutes, for example.
I've forked scron[0] and I plan to implement */n at some point. If
you get to it first, please send a
No */n for “every n ”?
Pretty much useless without that if you ever need a command to be run every
five minutes, for example.
On Wed, Jul 02, 2014 at 12:34:10PM +0300, Ari Malinen wrote:
> I made cron daemon because vixie-cron was too complex for my taste. It
> does the job for me. Maybe someone
Ari Malinen wrote:
> It does the job for me.
>
Nice.
On Wed, Jul 02, 2014 at 08:10:47AM -0400, Andrew Gwozdziewycz wrote:
> Sounds neat! Where can we find it?
https://github.com/defer-/scron
On July 2, 2014 5:34:10 AM EDT, Ari Malinen wrote:
>I made cron daemon because vixie-cron was too complex for my taste. It
>does the job for me. Maybe someone finds use for it.
>
>features:
>schedule tasks
>single daemon, config and initscript
>log job output: command &>> /var/log/cron.log
>run
21 matches
Mail list logo
