tcpdump mailing list archives
Re: bpf.tcpdump.org vs github
From: Michal Sekletar <msekleta () redhat com>
Date: Tue, 25 Nov 2014 19:38:23 +0100
On Tue, Nov 25, 2014 at 01:12:18PM -0500, Michael Richardson wrote:
Michal Sekletar <msekleta () redhat com> wrote: >> okay, can we start again. I would appreciate some clear data and >> clear complaints. >> >> This is what I heard: a) which is "master", bpf or github? > There are commits on github/master which are not on bpf. We already > have maintenance branch for 4.7 but there was no release yet. No commit > on master has tcpdump-4.7 tag. This is very confusing. Right, but the idea was supposed to be that we DO NOT PUBLISH the fault until after you guys (the distros) actually have a package. So, this is ENTIRELY ON PURPOSE. Are you saying that you'd prefer to have a zero-day exploit?
Disregarding security patches, those two git trees are out-of-sync anyway. If I understand current state correctly, then whatever is pushed to GH must be pull to bpf manually. Other way around somewhat works.
>> b) bpf is unreliable. > I mean an outage for hour or two and regular maintaince windows are > fine but if site is unreachable for days without prior notice then it > is unreliable in my book. I am unaware of it being unreachable for more than a Sunday afternoon to Monday morning; and that instability with power was solved.
I was also referring to other occurrences in the past. IIRC buildbot was sending emails to workers multiple times that build is failing and reason at the time was bpf server unreachability.
>> before I propose some solution/policy/adjustment, I want to make sure >> that I've heard all the issues. > I don't follow, you don't like the idea to use GitHub then why we > encourage people to use it as tool for contributing to the project. github has lots of nice features. Maybe we should only use github --- certainly when I first proposed github, many people were uncertain about it --- it was too new, and we were too experienced with sourceforge coming and going to want to sign up for another disaster.
GitHub or something else, I will let this decision to you, core developers. All I am saying is that having to "master" trees is sub-optimal, confusing and adds needless work to people. Michal
-- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works | network architect [ ] mcr () sandelman ca http://www.sandelman.ca/ | ruby on rails [
_______________________________________________ tcpdump-workers mailing list tcpdump-workers () lists tcpdump org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Current thread:
- Re: Official patches for CVE-2014-8767/CVE-2014-8768/CVE-2014-8769?, (continued)
- Re: Official patches for CVE-2014-8767/CVE-2014-8768/CVE-2014-8769? Michal Sekletar (Nov 24)
- Re: Official patches for CVE-2014-8767/CVE-2014-8768/CVE-2014-8769? Michael Richardson (Nov 24)
- Re: Official patches for CVE-2014-8767/CVE-2014-8768/CVE-2014-8769? Guy Harris (Nov 24)
- Re: Official patches for CVE-2014-8767/CVE-2014-8768/CVE-2014-8769? Denis Ovsienko (Nov 24)
- Re: Official patches for CVE-2014-8767/CVE-2014-8768/CVE-2014-8769? Guy Harris (Nov 24)
- Message not available
- bpf.tcpdump.org vs github Michael Richardson (Nov 24)
- Re: bpf.tcpdump.org vs github Guy Harris (Nov 24)
- Re: bpf.tcpdump.org vs github Denis Ovsienko (Nov 25)
- Re: bpf.tcpdump.org vs github Michal Sekletar (Nov 25)
- Re: bpf.tcpdump.org vs github Michael Richardson (Nov 25)
- Re: bpf.tcpdump.org vs github Michal Sekletar (Nov 25)
- Re: Official patches for CVE-2014-8767/CVE-2014-8768/CVE-2014-8769? Romain Francoise (Nov 24)
- Re: Official patches for CVE-2014-8767/CVE-2014-8768/CVE-2014-8769? Guy Harris (Nov 23)