All of lore.kernel.org
 help / color / mirror / Atom feed
From: Pablo Neira Ayuso <pablo@netfilter.org>
To: Patrick McHardy <kaber@trash.net>
Cc: Robert Scott <rbscott@cadvium.net>, netfilter-devel@lists.netfilter.org
Subject: Re: nfq_set_verdict_mark
Date: Wed, 11 Oct 2006 23:47:34 +0200	[thread overview]
Message-ID: <452D6676.8090700@netfilter.org> (raw)
In-Reply-To: <452CB33D.8060908@trash.net>

Patrick McHardy wrote:
> Pablo Neira Ayuso wrote:
>> Patrick McHardy wrote:
>>
>>> I'm beginning to wonder how much more kludges we will have in these
>>> libraries by continuing to treat them as stable without having had
>>> even a single beta version.
>>
>> OK, I start thinking that I'm getting obsessed with breaking current
>> deployed apps :(. I also think that we can solve this minor annoying
>> issues by fixing the problem and then releasing a new version asap.
> 
> I checked google code-search and the two users I could find already
> do the conversion manually, so they will break. Thats definitely not
> good, but I wonder if we should trust that this will be the last
> of these bugs or if we should clearly mark this as beta/unstable API
> and appologize for not beeing clear from the beginning. Its just
> not a good idea to release a library with an interface that is more
> or less cast in stone without any real testing.

We can warn about incompatibilities in the announce of new releases for
this kind of minor issues that we need to fix up and that result in
breakages, some kind of "heads up" section.

For the rest of the API, I remember that in one of my discussions with
Harald we conclude that is better to introduce new API than breaking
current just not to annoy users. We can strongly recommend the use of
the new API and mark old one as deprecated (with the gcc attribute) to
warn users that such obsolete function will vanish soon. That would
stagger changes.

>> The current release process is too slow, I have the impression that
>> nobody is using the lastest official releases. For conntrackd, I'm
>> currently doing unnofficial releases of libnetfilter_conntrack because
>> the official release is broken with NAT handlings, well apart from the
>> fact that I also introduce some patches with new features that I need.
> 
> You're probably right (about people not using official releases) and
> definitely right about releasing too seldom.
> 
>> Just tell you that I don't mind about spending some time on
>> administration tasks like releases and any other stuff related with the
>> website if that can help to speed up the release process. I worked on
>> some scripts to automate the release process time ago after the workshop
>> that I can recover.
> 
> That would be great. Let me know if you need anything (I think I recall
> your keys expired?).

I need to renew my key in order to tag new releases in SVN, I also need
to generate some kind of "release master GPG key" or something in other
to sign new releases.

-- 
The dawn of the fourth age of Linux firewalling is coming; a time of
great struggle and heroic deeds -- J.Kadlecsik got inspired by J.Morris

  reply	other threads:[~2006-10-11 21:47 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-10-01 20:09 nfq_set_verdict_mark Robert Scott
2006-10-02 14:55 ` nfq_set_verdict_mark Pablo Neira Ayuso
2006-10-10  5:20   ` nfq_set_verdict_mark Patrick McHardy
2006-10-10 23:59     ` nfq_set_verdict_mark Pablo Neira Ayuso
2006-10-11  9:02       ` nfq_set_verdict_mark Patrick McHardy
2006-10-11 21:47         ` Pablo Neira Ayuso [this message]
2006-10-12  6:35           ` nfq_set_verdict_mark Eric Leblond
2006-10-13  6:15             ` nfq_set_verdict_mark Patrick McHardy

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=452D6676.8090700@netfilter.org \
    --to=pablo@netfilter.org \
    --cc=kaber@trash.net \
    --cc=netfilter-devel@lists.netfilter.org \
    --cc=rbscott@cadvium.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.