On Feb 26, 2014, at 5:33 PM, Josef Bacik wrote:
>
> Just popping in here to say that btrfs is not ready to be default in Fedora
> yet. Optional is fine but not default.
>
>
OK good, that's definitive. Thanks Josef.
So my thought is Workstation WG choices: parity with Server WG, whatever t
On Wed, Feb 26, 2014 at 11:50 AM, Miloslav Trmač wrote:
Are you saying that the boot path should have tests, and the
less-frequently used parts of the system should be verified by seeing
whether any human users notice breakage?
No. First, it's more that in order to run any other tests,
Kevin, I think you are talking about releasing models...
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
On Feb 26, 2014 5:16 AM, "Colin Walters" wrote:
>
> On Wed, Feb 26, 2014 at 8:09 AM, Stanislav Ochotnicky <
sochotni...@redhat.com> wrote:
>>
>> "I" didn't name them. I used standard names for different testing levels
as defined by software engineering bodies. Quoting from SWEBOK:
>
>
> Yes, I thi
On Wed, 2014-02-26 at 21:56 +, Richard W.M. Jones wrote:
> For the sorts of tests you are talking about it's much better to test
> the final RPM installed in a full OS environment. That is what (I
> hope) Taskotron is trying to do.
Well, that's *one* of the things it does, yes (as AutoQA did
On Wed, 2014-02-26 at 21:53 +, Richard W.M. Jones wrote:
> On Wed, Feb 26, 2014 at 04:58:43PM +0100, Miloslav Trmač wrote:
> > 2014-02-26 14:11 GMT+01:00 Colin Walters :
> >
> > > During making glib changes you should run glib unit tests to have some
> > > basic level of assurance you didn't i
On Mon, 2014-02-24 at 05:16 +0100, Kevin Kofler wrote:
> Adam Williamson wrote:
> > I really don't know why you make these suggestions. I mean, you must
> > know no-one is going to reply "Why, Kevin! What a brilliant idea! We'll
> > do so immediately!", so what's the point?
>
> Why not? That's the
Miloslav Trmač wrote:
> I fully agree with you testers giving +1 is not even close to proper
> validation, but what alternative to get proper validation do you propose
> as an improvement? Dropping autokarma would replace broken validation
> with *no* validation; that's not an improvement.
The pr
The Board has reviewed the PRDs for the Cloud, Server, and Workstation
products and approves. While there are some reservations in certain
areas, the overall goals of each product seem to be well thought out
and an benefit to Fedora going forward. Thank you for taking the time
to work through these
On Feb 26, 2014 10:18 AM, "Jaroslav Reznik" wrote:
>
> - Original Message -
> > On Wed, Feb 26, 2014 at 9:25 AM, Josh Boyer
> > wrote:
> >
> >
> >
> > Yeah, agreed here. Everyone wants the latest shiniest thing, even if
that
> > thing isn't ready. I really don't want to wade through tons
Hello! My name is James Wilson Harshaw IV. I have been using Fedora for
a few years now, but recently really wanted to get more involved.
I have a pretty good amount of knowledge in C, C++, PHP, Perl, Golang,
and Java. I hope to use this knowledge to benefit the project.
A little about me: I
On Wed, 26 Feb 2014 14:26:41 +0100
Robert Mayr wrote:
...snip...
> For example spins, there was
> a long discussion on them, but we don't have any decision yet of how
> they should look like. I guess we will not provide them any more
> through spins.fpo, but that's a point we really need to know
On Wed, Feb 26, 2014 at 11:12:50PM +0100, Miloslav Trmač wrote:
> 2014-02-26 22:53 GMT+01:00 Richard W.M. Jones :
> > But bugs which break the boot prevent you from testing everything else.
> >
>
> Only if I would reboot boot my primary workstation into the new untested
> software, which I don't d
Following is the list of topics that will be discussed in the FPC
meeting Thursday at 2014-02-27 17:00 UTC in #fedora-meeting-1 on
irc.freenode.net.
Local time information (via. rktime):
2014-02-27 09:00 Thu US/Pacific PST
2014-02-27 12:00 Thu US/Eastern EST
2014-02-27 1
2014-02-26 22:53 GMT+01:00 Richard W.M. Jones :
> On Wed, Feb 26, 2014 at 04:58:43PM +0100, Miloslav Trmač wrote:
> > 2014-02-26 14:11 GMT+01:00 Colin Walters :
> >
> > > During making glib changes you should run glib unit tests to have some
> > > basic level of assurance you didn't introduce regr
https://bugzilla.redhat.com/show_bug.cgi?id=1070165
Petr Šabata changed:
What|Removed |Added
Status|ASSIGNED|CLOSED
Fixed In Version|
On Wed, Feb 26, 2014 at 01:56:22PM +, David Howells wrote:
> Alexander Todorov wrote:
>
> > How about making %check a packaging requirement in all cases - run tests or
> > add a comment explaining why not, how to run them (e.g. make test) or why
> > there are no tests for this package.
>
> D
On Wed, Feb 26, 2014 at 04:58:43PM +0100, Miloslav Trmač wrote:
> 2014-02-26 14:11 GMT+01:00 Colin Walters :
>
> > During making glib changes you should run glib unit tests to have some
> > basic level of assurance you didn't introduce regressions or unwanted
> > changes.
> >
> > The *very first*
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 02/26/2014 02:42 PM, Adam Williamson wrote:
> On Wed, 2014-02-26 at 12:18 -0700, Chris Murphy wrote:
>
>>> I agree switching from ext4 to XFS is likely not worthwhile.
>>
>> Whether Server WG goes with ext4 or XFS on LVM, it's worthwhile
>> for Wo
On Wed, Feb 26, 2014 at 2:42 PM, Adam Williamson wrote:
> On Wed, 2014-02-26 at 12:18 -0700, Chris Murphy wrote:
>
>> > I agree switching from ext4 to XFS is likely not worthwhile.
>>
>> Whether Server WG goes with ext4 or XFS on LVM, it's worthwhile for
>> Workstation WG to mimic it merely due to
On Wed, 2014-02-26 at 11:42 -0800, Adam Williamson wrote:
> The elephant in the room here seems to be LVM backing, I don't see
> anyone discussing that. Do desktop and server want to keep LVM backing
> by default if they don't go with btrfs? Do desktop and server have
> *differing* perspectives the
Chris Murphy wrote:
by default we put ext4 on LVM
The tool works in this use-case unless something has broken it recently.
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
On Wed, 2014-02-26 at 11:17 +0100, Karel Zak wrote:
> Don't try to be smart to everyone, it does not work. IMHO all you
> need is to support one or a very few scenarios (complete scenarios
> without customization) and a way how to switch from installer
> to manual partitioning by parted/fdisk
On Wed, 2014-02-26 at 12:18 -0700, Chris Murphy wrote:
> > I agree switching from ext4 to XFS is likely not worthwhile.
>
> Whether Server WG goes with ext4 or XFS on LVM, it's worthwhile for
> Workstation WG to mimic it merely due to simplicity because then we
> don't need separate installers or
On Wed, 2014-02-26 at 10:24 -0500, David Cantrell wrote:
> > Yep, a lot of fun - three different file systems for free different
> > products.
> > And we are back to the question how much these products could differ - with
> > limited resources we have right now - at least short term. Who can ans
On Feb 26, 2014, at 8:13 AM, Michael Cronenworth wrote:
> Ext4 has its btrfs conversion tool. Changing from ext4 to XFS, for arguably
> negligible benefits for Workstations, will make it more difficult for Fedora
> users to transition to btrfs.
It's an unlikely path because a.) by default we p
===
#fedora-meeting: FESCO (2014-02-26)
===
Meeting started by nirik at 18:00:06 UTC. The full logs are available at
http://meetbot.fedoraproject.org/fedora-meeting/2014-02-26/fesco.2014-02-26-18.00.log.html
.
Meeting summary
On Wed, 2014-02-26 at 17:50 +0100, Miloslav Trmač wrote:
> Are you saying that the boot path should have tests,
Yes, that is what was being said.
> and the less-frequently used parts of the system should be verified
> by seeing whether any human users notice breakage?
No, that was neither sai
On Wed, Feb 26, 2014 at 11:00 AM, Stanislav Ochotnicky
wrote:
> Actually we are strongly considering getting rid of javadocs
> completely[1] mostly due to Java 8 problems.
If for whatever reason those problems won't be fixed, I suppose one
approach to them is passing the -Xdoclint:none flag to ja
2014-02-26 17:46 GMT+01:00 Matthias Clasen :
> On Wed, 2014-02-26 at 16:58 +0100, Miloslav Trmač wrote:> That seems to be
> optimizing for bugs that break the boot, when bugs
> > that occur in less-frequently used parts of the system are far more
> > common; a lot of software is not used, or not c
On Wed, 2014-02-26 at 16:58 +0100, Miloslav Trmač wrote:
> 2014-02-26 14:11 GMT+01:00 Colin Walters :
> The *very first* test I run is "does the OS still boot"?
> That's called "smoketest" for me, and it only takes a few
> minutes.
>
>
> That seems to be optimizing for bu
On Wed, Feb 26, 2014 at 2:00 AM, Stanislav Ochotnicky <
sochotni...@redhat.com> wrote:
> Actually we are strongly considering getting rid of javadocs
> completely[1] mostly due to Java 8 problems. We might be able to leave
> them be perhaps, but it's just a lot of work with uncertain
> benefits/us
On Wed, Feb 26, 2014 at 2:19 AM, Aleksandar Kurtakov wrote:
> I'm all with you Ville.
> But this requires someone jumping in to do work and there is noone. We
> have to live in reality - noone is showing any interest into working on
> this :(.
I am willing to help with an effort to bring sanity
2014-02-26 14:11 GMT+01:00 Colin Walters :
> During making glib changes you should run glib unit tests to have some
> basic level of assurance you didn't introduce regressions or unwanted
> changes.
>
> The *very first* test I run is "does the OS still boot"? That's called
> "smoketest" for me, a
On Wed, Feb 26, 2014 at 10:24 AM, Adam Jackson wrote:
Just save the built tree as another build-time
artifact.
We do this already with glib2:
http://pkgs.fedoraproject.org/cgit/glib2.git/commit/?id=25351c50
And that's the general idea - assemble a tree containing -test
subpackages, and run
https://bugzilla.redhat.com/show_bug.cgi?id=1041304
--- Comment #9 from Fedora Update System ---
perl-PDL-2.7.0-3.fc20 has been submitted as an update for Fedora 20.
https://admin.fedoraproject.org/updates/perl-PDL-2.7.0-3.fc20
--
You are receiving this mail because:
You are on the CC list fo
https://bugzilla.redhat.com/show_bug.cgi?id=1041304
Petr Pisar changed:
What|Removed |Added
Status|ASSIGNED|MODIFIED
Fixed In Version|perl-PDL-2.7.0
On Wed, 2014-02-26 at 11:00 +0100, Dridi Boukelmoune wrote:
> I don't think this would be a good idea to avoid such tests in %check.
> If you do that you have to later fetch the source code again, build it
> again and finally you can run the tests.
No you don't. There's no reason the final rpms
On Wed, Feb 26, 2014 at 10:18 AM, Jaroslav Reznik wrote:
> - Original Message -
>> On Wed, Feb 26, 2014 at 9:25 AM, Josh Boyer
>> wrote:
>>
>>
>>
>> Yeah, agreed here. Everyone wants the latest shiniest thing, even if that
>> thing isn't ready. I really don't want to wade through tons of
On Wed, Feb 26, 2014 at 10:18:12AM -0500, Jaroslav Reznik wrote:
> - Original Message -
> > On Wed, Feb 26, 2014 at 9:25 AM, Josh Boyer
> > wrote:
> >
> >
> >
> > Yeah, agreed here. Everyone wants the latest shiniest thing, even if that
> > thing isn't ready. I really don't want to wade
On Wed, 2014-02-26 at 13:11 +, Colin Walters wrote:
> Ah, but if one makes "integration tests" very fast and easy to run as
> I have, then there's less need for "quick and dirty".
Which is sort of the crux of my argument against %check. "Hey, we found
this hammer, it smells kind of funny and
On Feb 26, 2014 7:00 PM, "Tim Lauridsen" wrote:
> The problem with this project is that there is no release tags, so you
cant get a specific version, just download the current master
> this is not very usefull for a fedora package.
You can ask them to tag it from now on. I always do that.
--
dev
- Original Message -
> On Wed, Feb 26, 2014 at 9:25 AM, Josh Boyer
> wrote:
>
>
>
> Yeah, agreed here. Everyone wants the latest shiniest thing, even if that
> thing isn't ready. I really don't want to wade through tons of bug reports
> for btrfs just because it has a lot of hype.
>
>
Alexander Todorov wrote:
> How about making %check a packaging requirement in all cases - run tests or
> add a comment explaining why not, how to run them (e.g. make test) or why
> there are no tests for this package.
Does %check install the package and run the tests as root? For the keyutils
p
2014-02-24 18:44 GMT+01:00 Stephen Gallagher :
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> tl;dr: FESCo needs to know what is going to need extra time to deliver
> Fedora.next in the Fedora 21 cycle.
[snip]
> * Websites Team: What sort of redesign work will we need to go through?
Webs
On Wed, Feb 26, 2014 at 8:09 AM, Stanislav Ochotnicky
wrote:
"I" didn't name them. I used standard names for different testing
levels
as defined by software engineering bodies. Quoting from SWEBOK:
Yes, I think they're wrong. Well, "suboptimal" is a better word.
During making glib chan
On Wed 26 Feb 2014 01:41:36 PM CET Colin Walters wrote:
> On Wed, Feb 26, 2014 at 5:01 AM, Stanislav Ochotnicky
> wrote:
>>
>> Because unit tests are designed to be run as part of the build
>> process. It's not impossible to run them *after* the build, but good
>> luck making it work reliably acr
On Fri, Feb 21, 2014 at 01:29:54PM -0800, Toshio Kuratomi wrote:
> Okay, here's some diff's to the current python-django14 package that will
> make it parallel installable. Once you have the parallel installable
> package you may also have to modify a few things in the dependent packages
> to make
On Wed, Feb 26, 2014 at 5:01 AM, Stanislav Ochotnicky
wrote:
Because unit tests are designed to be run as part of the build
process. It's not impossible to run them *after* the build, but good
luck making it work reliably across all packages without manual work.
The https://wiki.gnome.org/Ini
На 26.02.2014 13:00, Tim Lauridsen написа:
On Wed, Feb 26, 2014 at 11:21 AM, Christopher Meng wrote:
Bitbucket has downloads support.
Also you can get the tarball from the tags.
What's the problem?
The problem with this project is that there is no release tags, so you cant
get a specific
On Wed, Feb 26, 2014 at 11:21 AM, Christopher Meng wrote:
> Bitbucket has downloads support.
>
> Also you can get the tarball from the tags.
>
> What's the problem?
>
>
>
The problem with this project is that there is no release tags, so you cant
get a specific version, just download the current m
On 02/23/2014 06:29 PM, Mauricio Tavares wrote:
Could anyone point me to info on creating a local repo? I want to learn the
entire process of creating a package but
think it might be wiser to have a controlled environment
Do you really need it local?
If no - then:
http://copr.fedoraproject.or
На 26.02.2014 12:11, Tim Lauridsen написа:
Seems like bitbucket uses unversioned tar ball, not the best approch
https://bitbucket.org/yarosla/httpress/get/tip.tar.gz
I would make my own tarball from the git checkout and document in the
spec how to make it
For example:
https://bitbucket.org/
Bitbucket has downloads support.
Also you can get the tarball from the tags.
What's the problem?
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
On 26.02.2014 10:16, Nikos Mavrogiannopoulos wrote:
Hello,
I've submitted a while ago a review-request on a package [0] that is
taken from bitbucket.org. Unfortunately there was no reviewer yet, and I
suspect that is because unlike github [1] we have no rules on how to
handle bitbucket. Have o
On Fri, Feb 21, 2014 at 02:04:54PM -0800, Adam Williamson wrote:
> On Fri, 2014-02-21 at 16:38 -0500, john.flor...@dart.biz wrote:
>
> > > With the best of intentions, we'd gone from a reluctant exception to the
> > > 'no choice' design to a dropdown which included two very different
> > > complex
Seems like bitbucket uses unversioned tar ball, not the best approch
https://bitbucket.org/yarosla/httpress/get/tip.tar.gz
I would make my own tarball from the git checkout and document in the
spec how to make it
https://fedoraproject.org/wiki/Packaging:SourceURL#Using_Revision_Control
Tim
Adam Williamson writes:
> On Tue, 2014-02-25 at 18:35 -0800, Andrew Lutomirski wrote:
>
>> Just to mention: there are probably many packages where the equivalent
>> of %check can't be run without access to a source tree, so Taskotron
>> can't usefully replace %check. I maintain a package like th
On Wed, Feb 26, 2014 at 4:41 AM, Adam Williamson wrote:
> On Tue, 2014-02-25 at 18:35 -0800, Andrew Lutomirski wrote:
>
>> Just to mention: there are probably many packages where the equivalent
>> of %check can't be run without access to a source tree, so Taskotron
>> can't usefully replace %check
I'm all with you Ville.
But this requires someone jumping in to do work and there is noone. We have to
live in reality - noone is showing any interest into working on this :(.
Alexander Kurtakov
Red Hat Eclipse team
- Original Message -
> From: "Ville Skyttä"
> To: "Development discuss
Hello,
I've submitted a while ago a review-request on a package [0] that is
taken from bitbucket.org. Unfortunately there was no reviewer yet, and I
suspect that is because unlike github [1] we have no rules on how to
handle bitbucket. Have other packagers experienced something similar in
other so
Ville Skyttä writes:
> On Tue, Feb 25, 2014 at 10:59 AM, Stanislav Ochotnicky
> wrote:
>>
>> Since javadoc subpackages put files in /usr/share/javadoc they must
>> require package that provides this directory.
>
> In my opinion all javadocs should be crosslinked with local JDK's
> javadocs (+ ot
62 matches
Mail list logo
