subject:"Fedora.next in 2014 \\\\\\\-\\\\\\\- Big Picture and Themes"

On Sat, Jan 25, 2014 at 12:39:53PM +0100, Thorsten Leemhuis wrote:
 Understood, but OTOH it makes me wonder if Fedora.next is a step to
 big and needs to be split or something.

Well, in practical implementation, it probably _will_ be done as incremental
steps. For example, there's the possibility of decoupling the schedules of
the base release from the products, but one of the few solid decisions we've
already made is that that won't happen for F21.

 point is needed obviously. But sometimes I miss a few introductions
 words on the why we want all of that and how it's supposed to make
 Fedora better. But that's obviously meta/abstract again, which I

So, here's some things I see.

* Fedora's drift towards being primarily a desktop OS (with other use areas
  considered secondarily if at all) ends up practically restricting uses
  which people really do want Fedora for. That's bad for people who want to
  use Fedora in innovative ways in server and cloud environments. Even
  though we have a lot of sysadmin users and there are many examples of real
  Fedora in production server environments, every time over the past decade
  that someone has tried to figure out what Fedora Server might actually
  mean, it's gotten stalled. This has left many sysadmins feeling like
  either Fedora isn't a place that they can meaningfully contribute, or else
  that their job is to be the Voice of No. Even when one doesn't want to
  just be the project's stop energy, it sometimes felt like there was no
  other option. Fedora.next should *give* that option for postive
  contribution.

* Although it's certainly not the only reason, Fedora as _solely_ a hobbyist
  desktop is not ideal for an upstream for RHEL server and cloud products.
  That doesn't mean that there isn't room for one, but if we would focus
  Fedora on just that, we'd become increasingly irrelevant to our biggest
  downstream -- and to the project sponsor. (And make no mistake -- that
  concern of mine comes from a point of view of caring about Fedora first,
  not just my employer, because we benefit from taking part in that whole
  ecosystem cycle in ways beyond just Red Hat's direct employee and monetary
  contributions.) One particularly underserved area for Fedora is RHEL
  customers who would benefit from Fedora in some key areas (possibly even
  in production!), as well as those who are interested in experimenting with
  and possibily even shaping the future of the downstream.

* General trend in Linux towards the base distribution being boring and
  not mattering. I asked several dozen different people at a gigantic Amazon
  conference why everyone was using the distribution they chose instead of
  Fedora, and the answer was almost universally oh, I don't care; that's
  not really an interesting question because there's nothing important at
  that level. Now, that might not be really _true_, but it's definitely an
  increasing perception. How can we either fight that perception, or make
  sure that Fedora expands to also do work in the interesting space?

* Difficulty building things on top of Fedora. This means both end-users
  with their own applications and bigger more complicated applications like
  OpenStack which it would be nice to have in the Fedora universe. There is
  value in the perfect-crystal-castle-of-all-packages approach, but if we
  build that in one place while everyone is going by on the highway, we're
  not really fulfilling our mission of leading free and open source software
  -- we're doing cleanup from behind and not making the impact we could be.
  I strongly believe that we can make room for this in the Fedora Project
  overall, even for things that are not appropriate in the Fedora
  *distribution* in its traditional sense.

* As you mentioned in an earlier thread, it would be nice if we could make
  it easier to contribute minor changes, including big changes to more
  obscure packages. We can't just be Wikipedia and allow anonymous editing
  of packages (for one thing, we don't have an easy rollback mechanism and
  consequences could be much more severe), but maybe we can find a way of
  loosening things up for the fringes -- maybe even a really large fringe --
  while keeping the core distribution under closer care. (Going way back to
  last summer's discussion, the problem with the former distinction between
  Core and Extras was that Core wasn't really open and the distinction was
  based on who you worked for; I'm quite certain we won't make that mistake
  again. Also, the standards for Extras were higher than those for Core,
  which was of course backwards and an example of community showing the way.
  But all that doesn't mean that we can't take the lessons and do it right.)

* Wanting to eat our cake and have it too when it comes to balancing
  innovation and change management. In order to move fast while not breaking
  everybody all the time, it helps to break things up into larger logical
  segments than just

Re: Fedora.next in 2014 -- Big Picture and Themes

2014-01-28 Thread drago01

On Tue, Jan 28, 2014 at 3:42 PM, Matthew Miller
mat...@fedoraproject.org wrote:
 [...]
 So that's some of my thoughts. More later -- gotta take the kids to the
 dentist now. :)

You forgot the part where you explain how / why Fedora.next solves all
this issues. Some like cloud and server usage is more or less clear
(focus product) but the rest is a bot hand weavy. For instance why
should any of the changes make people suddenly care about the
distribution they use if you think they don't.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Fedora.next in 2014 -- Big Picture and Themes

2014-01-28 Thread Tom Hughes


On 28/01/14 14:42, Matthew Miller wrote:


* Fedora's drift towards being primarily a desktop OS (with other use areas
   considered secondarily if at all) ends up practically restricting uses
   which people really do want Fedora for. That's bad for people who want to
   use Fedora in innovative ways in server and cloud environments. Even
   though we have a lot of sysadmin users and there are many examples of real
   Fedora in production server environments, every time over the past decade
   that someone has tried to figure out what Fedora Server might actually
   mean, it's gotten stalled. This has left many sysadmins feeling like
   either Fedora isn't a place that they can meaningfully contribute, or else
   that their job is to be the Voice of No. Even when one doesn't want to
   just be the project's stop energy, it sometimes felt like there was no
   other option. Fedora.next should *give* that option for postive
   contribution.


I think the reason that people have trouble defining what Fedora 
Server might mean is that it simply doesn't make a huge amount of sense 
as a thing.


A desktop has some kind of common meaning that everybody can agree on in 
terms of expecting a window manager and certain basic applications but 
everybody will want something different of a server, and indeed will 
want something different on each server.


To me what I would want of Fedora Server is simply a solid base OS and 
a solid set of package I can install on top of that depending on what I 
want each particular server to do - sometimes that will be postgres, 
sometimes it will be mysql and apache, sometimes it will be exim and 
spamassassin.


The thing is, for the most part, that is what we already have!

The biggest reason for people preferring, say, Ubuntu over Fedora for 
servers is probably not the existence of something called server but 
rather the extended stable lifetime offered by LTS releases.


Tom

--
Tom Hughes (t...@compton.nu)
http://compton.nu/
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Fedora.next in 2014 -- Big Picture and Themes

On Tue, Jan 28, 2014 at 09:42:54AM -0500, Matthew Miller wrote:
 So, here's some things I see.

Oh, I forgot one...

* There is a lot of excitement about containers right now. It's not a new
  idea, but one where a lot of things have come together to make
  containerization interesting and viable on Linux. We should be positioned
  to lead in this area. That means at minimum efforts around Docker and
  LinuxApps, but it could go beyond that. Look at what CoreOS and
  Boot-to-Docker are doing -- a very minimal base OS with even system
  services provided as containers. It's possible that it's just a fad, but
  it may also be the next big direction for Linux-based operating systems.
  Even if we don't lead here, we should be prepared to adapt.

-- 
Matthew Miller--   Fedora Project--mat...@fedoraproject.org
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Fedora.next in 2014 -- Big Picture and Themes

On Tue, Jan 28, 2014 at 04:19:38PM +0100, drago01 wrote:
  So that's some of my thoughts. More later -- gotta take the kids to the
  dentist now. :)
 You forgot the part where you explain how / why Fedora.next solves all
 this issues. Some like cloud and server usage is more or less clear
 (focus product) but the rest is a bot hand weavy. 

I didn't forget. That's just a different part of the conversation. I'm happy
to talk about that too, though.

I'm advocating for certain things which I think *do* address these needs.
I'll try to talk more about the particular connections as things come up,
but you're right that it's somewhat handwavy, because... well, many of the
specifics actually haven't come up yet, so it's a future conversation.
Possibly a very near-future one -- let's go!

I'm also happy to talk about other big issues that we as a community feel
like we face as we go into our second decade. I don't imagine the list I
sent is comprehensive (let alone universally-agreed on). And I'll definitely
advocate for any ideas anyone has to address any of this.

-- 
Matthew Miller--   Fedora Project--mat...@fedoraproject.org
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Fedora.next in 2014 -- Big Picture and Themes

On Tue, Jan 28, 2014 at 03:33:43PM +, Tom Hughes wrote:
 I think the reason that people have trouble defining what Fedora
 Server might mean is that it simply doesn't make a huge amount of
 sense as a thing.

Yes, that has traditionally been the stumbling block. But have you looked at
what the Fedora Server working group is coming up with?

 To me what I would want of Fedora Server is simply a solid base OS
 and a solid set of package I can install on top of that depending on
 what I want each particular server to do - sometimes that will be
 postgres, sometimes it will be mysql and apache, sometimes it will
 be exim and spamassassin.

And that's reasonable. But as we have defined Fedora server as not anything
in particular, that drifts closer and closer to not a thing. That leaves
define release criteria -- let alone blockers.

 The biggest reason for people preferring, say, Ubuntu over Fedora
 for servers is probably not the existence of something called
 server but rather the extended stable lifetime offered by LTS
 releases.

And that's on the table as a possibility, but it would take a lot of
commitment from package maintainers. Another approach is to work on making
upgrades less disruptive, so you don't need to fear the EOL -- just schedule
an update and your stuff keeps working.

-- 
Matthew Miller--   Fedora Project--mat...@fedoraproject.org
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Fedora.next in 2014 -- Big Picture and Themes

2014-01-28 Thread Jóhann B. Guðmundsson



On 01/28/2014 05:33 PM, Matthew Miller wrote:

And that's reasonable. But as we have defined Fedora server as not anything
in particular, that drifts closer and closer to not a thing. That leaves
define release criteria -- let alone blockers.



Why do you think we in QA are going to be defining release criteria 
surrounding cloud workstation or server?


JBG
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Fedora.next in 2014 -- Big Picture and Themes

2014-01-28 Thread Adam Williamson

On Tue, 2014-01-28 at 17:40 +, Jóhann B. Guðmundsson wrote:
 On 01/28/2014 05:33 PM, Matthew Miller wrote:
  And that's reasonable. But as we have defined Fedora server as not anything
  in particular, that drifts closer and closer to not a thing. That leaves
  define release criteria -- let alone blockers.
 
 
 Why do you think we in QA are going to be defining release criteria 
 surrounding cloud workstation or server?

Matthew's sentence does not parse grammatically at all, which makes it
hard for me to figure out what I'm saying, but he didn't mention 'QA' at
all.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Fedora.next in 2014 -- Big Picture and Themes

2014-01-28 Thread Adam Williamson

On Tue, 2014-01-28 at 09:44 -0800, Adam Williamson wrote:

 Matthew's sentence does not parse grammatically at all, which makes it
 hard for me to figure out what I'm saying,

what he's saying, I meant. Good grief, my fingers and brain are not
connected this morning.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Fedora.next in 2014 -- Big Picture and Themes

On Tue, Jan 28, 2014 at 04:19:38PM +0100, drago01 wrote:
 You forgot the part where you explain how / why Fedora.next solves all
 this issues. Some like cloud and server usage is more or less clear
 (focus product) but the rest is a bot hand weavy. For instance why
 should any of the changes make people suddenly care about the
 distribution they use if you think they don't.

To address your for instance specifically, I think there's two concrete
steps (which I hope you can see in the Cloud PRD).

First, emphasize unique things we have at the base level which *should* be
of interest. For example, SELinux around Docker containers makes them have
reasonable security (rather than just being resource division). No one else
has that, so it's a good selling point. (Or will be once it's actually
implemented.) Or, better integration of an orchestration layer (although
that's somethin that we are not readay to tackle yet.)

Second, give people what they *do* care about: choices of language stacks
above the base level, and a layer of separation so that there isn't a big
impact when the base layer changes. To quote someone I talked to: No
distribution does that well, so if you can, you'd really have something
valuable to me.


-- 
Matthew Miller--   Fedora Project--mat...@fedoraproject.org
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Fedora.next in 2014 -- Big Picture and Themes

On Tue, Jan 28, 2014 at 09:44:34AM -0800, Adam Williamson wrote:
   And that's reasonable. But as we have defined Fedora server as not
   anything in particular, that drifts closer and closer to not a
   thing. That leaves define release criteria -- let alone blockers.
  Why do you think we in QA are going to be defining release criteria 
  surrounding cloud workstation or server?
 Matthew's sentence does not parse grammatically at all, which makes it
 hard for me to figure out what I'm saying, but he didn't mention 'QA' at
 all.

Yeah, what? I'm not sure if that's lack of coffee or if I can blame my
computer in some way. I think that was supposed to be That leaves little
room to or something like that.

As for what I think... I expect the working groups will work with the QA
team experts to define release criteria appropriate for their areas. That's
what the board-approved plan says
https://fedoraproject.org/wiki/Fedora.next/boardproposal#QA. I didn't
anticipate that being controversial, but if it is in some way, I'm sure we
can figure something out.

-- 
Matthew Miller--   Fedora Project--mat...@fedoraproject.org
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Fedora.next in 2014 -- Big Picture and Themes

2014-01-28 Thread Jóhann B. Guðmundsson



On 01/28/2014 05:55 PM, Matthew Miller wrote:

Yeah, what? I'm not sure if that's lack of coffee or if I can blame my
computer in some way. I think that was supposed to be That leaves little
room to or something like that.

As for what I think... I expect the working groups will work with the QA
team experts to define release criteria appropriate for their areas. That's
what the board-approved plan says
https://fedoraproject.org/wiki/Fedora.next/boardproposal#QA. I didn't
anticipate that being controversial, but if it is in some way, I'm sure we
can figure something out.


Should not be controversial since it's simple really we will shrink our 
default release criteria and test cases if they exist in accordance with 
the output from the WG's either remove that completely or move that into 
their own defined release criteria which resides in the community's 
surrounding the WG's .


JBG
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Fedora.next in 2014 -- Big Picture and Themes

2014-01-28 Thread Tom Hughes


On 28/01/14 17:33, Matthew Miller wrote:


On Tue, Jan 28, 2014 at 03:33:43PM +, Tom Hughes wrote:



I think the reason that people have trouble defining what Fedora
Server might mean is that it simply doesn't make a huge amount of
sense as a thing.


Yes, that has traditionally been the stumbling block. But have you looked at
what the Fedora Server working group is coming up with?


The roles stuff? I have, though I'm not sure if I just failing to get it 
or something but I don't see anything there that looks especially useful 
to a server administrator.


Other than pulling in a group of packages it's not really clear to me 
what a role does for me, and I suspect that defining roles that are 
generally useful without pulling in more than people really want will be 
hard - the classic example being the database server role that was 
included in the examples and which was going to pull in both postgres 
and mysql. Well normally I want one or the other, but not both...


Obviously that can be fixed by having mysql server and postgres 
server roles but at one point do you wind up with one role per package 
and basically back where you started?


If I recall correctly there was also some talk of having each role 
provide some sort of configuration/management interface that plugged 
into a web console but frankly that's the last thing I want on a server 
I'm looking after.


Tom

--
Tom Hughes (t...@compton.nu)
http://compton.nu/
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Fedora.next in 2014 -- Big Picture and Themes

2014-01-28 Thread drago01

On Tue, Jan 28, 2014 at 6:47 PM, Matthew Miller
mat...@fedoraproject.org wrote:
 On Tue, Jan 28, 2014 at 04:19:38PM +0100, drago01 wrote:
 You forgot the part where you explain how / why Fedora.next solves all
 this issues. Some like cloud and server usage is more or less clear
 (focus product) but the rest is a bot hand weavy. For instance why
 should any of the changes make people suddenly care about the
 distribution they use if you think they don't.

 To address your for instance specifically, I think there's two concrete
 steps (which I hope you can see in the Cloud PRD).

 First, emphasize unique things we have at the base level which *should* be
 of interest. For example, SELinux around Docker containers makes them have
 reasonable security (rather than just being resource division). No one else
 has that, so it's a good selling point. (Or will be once it's actually
 implemented.) Or, better integration of an orchestration layer (although
 that's somethin that we are not readay to tackle yet.)

OK that one makes sense.

 Second, give people what they *do* care about: choices of language stacks
 above the base level, and a layer of separation so that there isn't a big
 impact when the base layer changes. To quote someone I talked to: No
 distribution does that well, so if you can, you'd really have something
 valuable to me.

This is again hand wavy(sorry for overusing this term). I can
already have multiple language stacks
for instance python, java, ruby and php on fedora (or pretty much any
other distribution) just fine today.

And I don't expect it to break when the base layer (whatever that
means ... kernel? glibc? systemd?) changes.
So in that case I didn't even get the problem itself so I cannot
comment much on the solution.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Fedora.next in 2014 -- Big Picture and Themes

2014-01-28 Thread Stephen John Smoogen

On 28 January 2014 07:42, Matthew Miller mat...@fedoraproject.org wrote:


 * General trend in Linux towards the base distribution being boring and
   not mattering. I asked several dozen different people at a gigantic
 Amazon
   conference why everyone was using the distribution they chose instead of
   Fedora, and the answer was almost universally oh, I don't care; that's
   not really an interesting question because there's nothing important at
   that level. Now, that might not be really _true_, but it's definitely an
   increasing perception. How can we either fight that perception, or make
   sure that Fedora expands to also do work in the interesting space?


I think it is a real item but even as a perception, it is not something
that could be fought. Perceptions are like the tide and if you are lucky
you might be able to build tons of dikes and stop the tide rolling in, but
most likely you just have to wait til it goes out again in 8-16 years.

The big issues with it not being interesting anymore is that like every
other technology it has to become more and more standardized to meet the
scale of issues that people are trying to solve. Plumbing had to do this in
the 1800's and electrical wiring had to do this in the 1900's and car parts
had to do this in the 1950's [while all of these are very diversified, they
are less so than they were and you can reasonably be assured that every car
of a certain model has the same parts, etc.]

What that means is that you end up with more and more stop energy to 'fix',
'change', 'innovate' on the lower levels because it becomes harder and
harder to get those parts to work with the rest of the industry. So either
the innovation moves up the the chain, it becomes smaller and more
specialized, or it goes to do something completely new that becomes
interesting to loads of people again. [Or in 8-16 years people all of a
sudden go, hey X is a really cool thing.. and everyone goes to do that
again.]

So I expect the work we need to work on is higher up in the stack as that
is where things are interesting. The cool kids don't want to work on the
plumbing levels of a single computer (or even a cluster), they want to work
on hundreds to thousands of computers and the distribution at that part is
just like a 'kernel' to them.. so if we want to move up we need to work on
the meta-distribution and how that works.

[Of course this could just be the rantings of a cough medicine dope fiend..
]

-- 
Stephen J Smoogen.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Fedora.next in 2014 -- Big Picture and Themes

2014-01-28 Thread Robert M. Albrecht


Hi,


* Although it's certainly not the only reason, Fedora as _solely_ a hobbyist
   desktop is not ideal for an upstream for RHEL server and cloud products.


No other system can be reinstalled / upgraded every six months. That 
single fact IMHO kills all other use cases.


If I need a stable Fedora-like server, I get CentOS. It's kind of a 
Fedora-LTS.



* General trend in Linux towards the base distribution being boring and
   not mattering. I asked several dozen different people at a gigantic Amazon
   conference why everyone was using the distribution they chose instead of
   Fedora, and the answer was almost universally oh, I don't care; that's
   not really an interesting question because there's nothing important at
   that level.


All (of the big) distros are mature today. At the early days one chose 
his distro by drivers, by installation-tool, by packages, ...


Nowady every distro has a working installer, has a bazillion packages, 
... they basically all work.


So non-technical topics become more relevant: is there a LTS-release, 
can I start with a free(beer) distro like centos and later change to a 
paid-support-modell (RHEL) without rebuilding all my configs and apps, 
how good is the documentation, ...


The real innovation is happening on the desktop: power management, 
Wayland, Mesa, wifi/3g/4g, color-management, pulseaudio, ...



Now, that might not be really _true_, but it's definitely an
   increasing perception. How can we either fight that perception, or make
   sure that Fedora expands to also do work in the interesting space?


I don't know anything about the statistics on Fedora contributors and 
their jobs. But if there are lot of hobbyists, students, ... these 
people are not able / interessted in large enterprise stuff like 
OpenStack, ... they work on devel-tools like languages and 
desktop-stuff, that's what they are using.


If Fedora want's more innovation in those topics, Fedora must possibly 
reallign the devel-community. Most enterprise-project like libvirt, 
freeipa, Spacewalk, ... are done by Redhat-people ? Or am I totaly 
mistaken there.


cu romal
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Fedora.next in 2014 -- Big Picture and Themes

2014-01-28 Thread Robert M. Albrecht


Hi,

what is a role? Is database-server a usefull role?

Or would that go more to owncloud-server or joomla-server ...

This would then pull all packages in.

And if Owncloud supports several databases, Fedora should make a choice 
and install only one of them. A user which cares so deeply to make a 
decision which database he want's will install it manually anyhow.


Fedora is making these choices on other instances: you get x.org and not 
wayland. You get gcc and not llvm. You get systemd and not upstart.


cu romal


Am 28.01.14 19:06, schrieb Tom Hughes:

On 28/01/14 17:33, Matthew Miller wrote:


On Tue, Jan 28, 2014 at 03:33:43PM +, Tom Hughes wrote:

 

I think the reason that people have trouble defining what Fedora
Server might mean is that it simply doesn't make a huge amount of
sense as a thing.


Yes, that has traditionally been the stumbling block. But have you
looked at
what the Fedora Server working group is coming up with?


The roles stuff? I have, though I'm not sure if I just failing to get it
or something but I don't see anything there that looks especially useful
to a server administrator.

Other than pulling in a group of packages it's not really clear to me
what a role does for me, and I suspect that defining roles that are
generally useful without pulling in more than people really want will be
hard - the classic example being the database server role that was
included in the examples and which was going to pull in both postgres
and mysql. Well normally I want one or the other, but not both...

Obviously that can be fixed by having mysql server and postgres
server roles but at one point do you wind up with one role per package
and basically back where you started?

If I recall correctly there was also some talk of having each role
provide some sort of configuration/management interface that plugged
into a web console but frankly that's the last thing I want on a server
I'm looking after.

Tom


--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Fedora.next in 2014 -- Big Picture and Themes

2014-01-28 Thread Nathanael D. Noblet

On Tue, 2014-01-28 at 19:04 +0100, drago01 wrote:
  Second, give people what they *do* care about: choices of language stacks
  above the base level, and a layer of separation so that there isn't a big
  impact when the base layer changes. To quote someone I talked to: No
  distribution does that well, so if you can, you'd really have something
  valuable to me.
 
 This is again hand wavy(sorry for overusing this term). I can
 already have multiple language stacks
 for instance python, java, ruby and php on fedora (or pretty much any
 other distribution) just fine today.
 
 And I don't expect it to break when the base layer (whatever that
 means ... kernel? glibc? systemd?) changes.
 So in that case I didn't even get the problem itself so I cannot
 comment much on the solution.

From my perspective it isn't about the language stacks, its about the
stacks within the languages. Fedora has a 18 month window. My servers
run for years. I don't have time to update the entire server every 18
months. It just isn't feasible. (I'm also not fully virtualized and
automated with ansible and friends yet). So given that I use CentOS
since I know it will remain stable. The downside is that php is never
updated on it. It has a really really old php 5.3, I want 5.4 but so
many things are compiled against the 5.3 so its a huge amount of work.

I'm SUPER intrigued by Fedora.next if it is trying to solve this issue.
I can have a base OS, but pick the PHP 5.4 stack or 5.5 stack and/or
upgrade *just* that part on a live server. I'd be super happy. I could
upgrade my php stack but leave the os running happily. Less work.
Eventually I'd expect bringing up a cloud instance with ansible
provisioning and all that would also allow that.

-- 
Nathanael

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Fedora.next in 2014 -- Big Picture and Themes

On Tue, Jan 28, 2014 at 07:04:52PM +0100, drago01 wrote:
 This is again hand wavy(sorry for overusing this term). I can
 already have multiple language stacks
 for instance python, java, ruby and php on fedora (or pretty much any
 other distribution) just fine today.
 And I don't expect it to break when the base layer (whatever that
 means ... kernel? glibc? systemd?) changes.

Everything that isn't the language runtime, basically. I'm answering this
second question first, because it helps answer the first part.

Right now, the version of Python installed has to be the version that is
required for code in the base -- yum or dnf at the very least, possibly
puppet or chef, maybe firewalld or cloud-init. If your code isn't
Python3-ready when Fedora switches, what will you do? If you don't update,
your code *will* break.

It is often the case that upstream code is tightly tied to particular
versions of the language or language modules. That's the hard problem. And
what about language modules which aren't yet packaged? Should everyone who
wants to use Fedora to deploy their application have to go through creating
RPMs for each?

The situation is particularly bad with Ruby. We don't have popular system
lifetime management software Foreman (http://theforeman.org/) packaged in
Fedora because of dependency hell. (And that just got worse when we went to
Ruby 4.) Now, we can say well, Ruby sucks, but that's the basic
problem.

To some degree, the answer might be to just give the user the minimum plus
the upstream package management tool (pip or gem or whatever), but to me
that seems like giving up on our broad mission. We can do better.

SCLs are one attempt at this, and despite some issues seem to be fairly well
received. (See for example http://developerweek.com/awards/) There are
probably even better solutions out there. One thing I'm interested in
experimenting with is Docker images built with packages from SCLs, but
rebuilt so that the binary RPMS aren't SCL-enabled (and therefore put ruby
at /usr/bin/ruby regardless of the version). Another idea is to work with
the upstream packaging system so that when you gem install, an rpm is
actually transparently built locally from the rubygems.org packages. There
are certainly more ideas -- the Environments and Stacks Working Group is
working on this.

But there's also a lot of handwaving. :)



-- 
Matthew Miller--   Fedora Project--mat...@fedoraproject.org
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Fedora.next in 2014 -- Big Picture and Themes

On Tue, Jan 28, 2014 at 08:34:23PM +0100, Robert M. Albrecht wrote:
 * Although it's certainly not the only reason, Fedora as _solely_ a
hobbyist desktop is not ideal for an upstream for RHEL server and
cloud products.
 No other system can be reinstalled / upgraded every six months. That
 single fact IMHO kills all other use cases.

Fedora actually has a 13-month lifecycle, which is still fast but less
dramatic than that. And although that makes it *challenging*, it doesn't
preclude real use in non-desktop cases. I know because I've seen people in
real life doing all sorts of things, from high-performance computing to
running hosting services to high-frequency stock trading.

 If I need a stable Fedora-like server, I get CentOS. It's kind of a
 Fedora-LTS.

Sure -- fine for some versions of what stable means. I don't think Fedora
and CentOS directly compete -- they complement.

 The real innovation is happening on the desktop: power management,
 Wayland, Mesa, wifi/3g/4g, color-management, pulseaudio, ...

I don't think I want to get into an argument about where real innovation is
or isn't happening, but it's definitely happening in non-desktop areas as
well.

 I don't know anything about the statistics on Fedora contributors
 and their jobs. But if there are lot of hobbyists, students, ...
 these people are not able / interessted in large enterprise stuff
 like OpenStack, ... they work on devel-tools like languages and
 desktop-stuff, that's what they are using.

We have a mix. But hobbyists and students and non-enterprise users are
absolutely critical to who we are, regardless of the statistics. The desktop
component isn't thrown out in Fedora.next. The Workstation WG PRD proposal
specifically targets students, independent developers, small-company
developers, and enterprise developers, but also has a section about
welcoming other user segments.

 If Fedora want's more innovation in those topics, Fedora must
 possibly reallign the devel-community. Most enterprise-project like
 libvirt, freeipa, Spacewalk, ... are done by Redhat-people ? Or am I
 totaly mistaken there.

We've got a lot of that, for sure, but we also have a lot of enterprise
packages maintained by non-Red-Hatters. I'm not quite sure what you mean by
realign the devel community -- can you elaborate?


-- 
Matthew Miller--   Fedora Project--mat...@fedoraproject.org
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Fedora.next in 2014 -- Big Picture and Themes

On Sat, Jan 25, 2014 at 12:16:40PM +0100, Thorsten Leemhuis wrote:
  I will be giving a talk on Sunday, February 9th in at DevConf in Brno,
  CZ, and I'll post slides from that (probably here as text as well), and
  I assume there will be video.
 That's great (I'll be there; Fosdem as well), but please allow me a side
 note here: Videos and IRC logs are a great resource if you really care
 about something and want to know all the details. But the ratio for
 time spend watching/reading vs. information gathered is often quite
 bad. That's why written, easy to read summaries are important. And I
 think we got too few of them from Flock last year, which is one of the
 reason why I had/have problems to fully understand Fedora.next.

Oh, absolutely.  The transcripts from the Flock talks that had them (see
https://lwn.net/Articles/563213/) were awesome, but summaries are even
better. I'll try to use the slides I have yet to put together as the basis
of a post here (and maybe a wiki page update).


 Agreed. For example, +1/like-Buttons for a mailing list would be good
 afaics, to get a rough impression how people think (just wondering: will
 hyperkitty or something from that camp of developers have this?). But
 that's just one thing that springs to my mind and a different topic.

FTR, yes, that's a key feature of hyperkitty.


 To be honest: only a little bit. Fedora.next simply is so big (I'm
 wondering if too much is cramped into it) and still vague in some parts
 that I remain careful. But that's not unusual, I'm quite sceptic all the
 time and more of a pessimist ;-)

The big parts don't need to be done all at once. (Some of them might not
need to be done at all.) Careful is good.

 And for now I have something else I need to take care of first:
 preparing my devconf talk :D

Yes -- see you there!

-- 
Matthew Miller--   Fedora Project--mat...@fedoraproject.org
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Fedora.next in 2014 -- Big Picture and Themes

2014-01-28 Thread Stephen John Smoogen

On 28 January 2014 13:38, Matthew Miller mat...@fedoraproject.org wrote:

 On Tue, Jan 28, 2014 at 08:34:23PM +0100, Robert M. Albrecht wrote:
  * Although it's certainly not the only reason, Fedora as _solely_ a
 hobbyist desktop is not ideal for an upstream for RHEL server and
 cloud products.
  No other system can be reinstalled / upgraded every six months. That
  single fact IMHO kills all other use cases.

 Fedora actually has a 13-month lifecycle, which is still fast but less
 dramatic than that. And although that makes it *challenging*, it doesn't
 preclude real use in non-desktop cases. I know because I've seen people in
 real life doing all sorts of things, from high-performance computing to
 running hosting services to high-frequency stock trading.


Well on paper it has a 13 month lifecycle, but the perceptions are a lot
shorter due to three factors:

1) If you have a complicated stack for applications then you are going to
need 3-6 months to port, test and verify that it works with the latest
perl, python, ruby, java, and haskell you ended up using to get your job
done.

2) If you are really a part of the community, it feels like a 3 month life
cycle because that is the time between X and X+1-alpha, and the constant
and needed drumbeat that you test, use and promote X+1alpha so that it can
be ready in 3 months time.

3) When you end up being on X-1 release, you quickly find your bugs being
answered that you need to either move to X or X+1-beta to see if it is
fixed there because the package maintainer only has so much attention to
spend on things.

The biggest things I can see from Fedora.Next is working on solving 1,2,3
by making it easier and faster to either port or carry your own versions of
the apps you need and making as much of the OS 'metric' as possible so that
it can be forgotten by the meta-os people.

-- 
Stephen J Smoogen.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Fedora.next in 2014 -- Big Picture and Themes

2014-01-28 Thread drago01

On Tue, Jan 28, 2014 at 9:06 PM, Matthew Miller
mat...@fedoraproject.org wrote:
 On Tue, Jan 28, 2014 at 07:04:52PM +0100, drago01 wrote:
 This is again hand wavy(sorry for overusing this term). I can
 already have multiple language stacks
 for instance python, java, ruby and php on fedora (or pretty much any
 other distribution) just fine today.
 And I don't expect it to break when the base layer (whatever that
 means ... kernel? glibc? systemd?) changes.

 Everything that isn't the language runtime, basically. I'm answering this
 second question first, because it helps answer the first part.

 Right now, the version of Python installed has to be the version that is
 required for code in the base -- yum or dnf at the very least, possibly
 puppet or chef, maybe firewalld or cloud-init. If your code isn't
 Python3-ready when Fedora switches, what will you do? If you don't update,
 your code *will* break.

Isn't that a contradiction to what you said above everything that
isn't a language runtime and now
you are talking about python updates.

OK in that case sure if you update the language runtime itself to a
version that is not compatible with
the deployed applications you have a problem. But the base itself
has nothing to do with it (ignoring some odd fringe cases).

 It is often the case that upstream code is tightly tied to particular
 versions of the language or language modules. That's the hard problem. And
 what about language modules which aren't yet packaged? Should everyone who
 wants to use Fedora to deploy their application have to go through creating
 RPMs for each?

Yeah I agree that this part needs fixing. Maybe automated packing
helps. We are to much focused on packing
and packages while a lot of that could be automated. You may not get
the cleanest spec files that way but
there was some distro created by Arjan I think that does it this way.

 SCLs are one attempt at this, and despite some issues seem to be fairly well
 received. (See for example http://developerweek.com/awards/) There are
 probably even better solutions out there. One thing I'm interested in
 experimenting with is Docker images built with packages from SCLs, but
 rebuilt so that the binary RPMS aren't SCL-enabled (and therefore put ruby
 at /usr/bin/ruby regardless of the version). Another idea is to work with
 the upstream packaging system so that when you gem install, an rpm is
 actually transparently built locally from the rubygems.org packages. There
 are certainly more ideas -- the Environments and Stacks Working Group is
 working on this.

Yeah SCLs are a way to deal with this issue. But is it really
incompatible with how we did Fedora in the past?

Don't get me wrong I am not trying to stop Fedora.next I am just
trying to understand what toughs lead to it.

It looks like ok there are problems lets do stuff differently and see
how it works out.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Fedora.next in 2014 -- Big Picture and Themes

On Sat, Jan 25, 2014 at 11:20:33AM +0100, Thorsten Leemhuis wrote:
 I for one waited (and still wait) for a text that gives a brief
 overview; something like a four or five para text which outlines the
 consequences and how Fedora will look like in the end. Something easy to
 understand; so easy that people can grasp it who are not involved in
 Fedora, but know what Linux is.

Well, we're still working on that in a smaller sense -- developing a _part_
of that is the current task for the working groups. That will be done in a
matter of weeks, and we can put together something that shows some of the
specifics. But in a larger sense, there's no description of the end state
because we're still figuring it out. We're trying to gather everyone's input
and effort to make a coherent community plan. That's the point of this
thread in the first place.

 Then provide some more text that then goes into the details. But keep it
 short and easy to read, too. Most of us have a stressful day and the
 attention span is quite short. So even the longer stuff should not take
 more than 10 minutes to read (or provide something to put 12 more hours
 into a day, then the text can be a bit longer ;-) ).

So eventually, yes, this would be a great thing to have. But right now, we
have people on the one hand concerned that there are no specifics and on the
other hand worried that there's some sort of sudden sealed deal. But really,
the reason that there are no specifics is because it's simply still being
worked on. We _have_ decided to go in a certain direction with the three
target products and the env  stacks and base design working groups, but
we will take the next steps as we get to them.

Eventually, that _will_ lead to a place where the text you're looking for
can exist.

-- 
Matthew Miller--   Fedora Project--mat...@fedoraproject.org
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Fedora.next in 2014 -- Big Picture and Themes

On Tue, Jan 28, 2014 at 01:58:55PM -0700, Stephen John Smoogen wrote:
 The biggest things I can see from Fedora.Next is working on solving 1,2,3
 by making it easier and faster to either port or carry your own versions of
 the apps you need and making as much of the OS 'metric' as possible so that
 it can be forgotten by the meta-os people.

Yes to all of that. :)


-- 
Matthew Miller--   Fedora Project--mat...@fedoraproject.org
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Fedora.next in 2014 -- Big Picture and Themes

On Tue, Jan 28, 2014 at 10:00:25PM +0100, drago01 wrote:
  Right now, the version of Python installed has to be the version that is
  required for code in the base -- yum or dnf at the very least, possibly
  puppet or chef, maybe firewalld or cloud-init. If your code isn't
  Python3-ready when Fedora switches, what will you do? If you don't update,
  your code *will* break.
 Isn't that a contradiction to what you said above everything that
 isn't a language runtime and now
 you are talking about python updates.

That's an example where the language is very tightly tied into the base. But
it's the case in general that all language environments we ship are tied to
the set of packages we ship at that time. Occasionally we do compatibility
packaging (python3 is actually an example of this), but in general it's
pretty painful. This is kind of creaky -- I'll use Puppet as an example: we
shipped it largely broken for several releases, because we updated Ruby to a
version not supported upstream. And we probably also shipped code that
required at least that new version. How do we decide in situations like
this? The traditional Fedora approach is to error in favor of going forward.
Because first is part of Fedora's fundamentals, I don't think we should
stop that, but we also could find a way to accommodate.

(And that's an example of something _within_ the distribution -- there's no
concern at all for user code.)

  It is often the case that upstream code is tightly tied to particular
  versions of the language or language modules. That's the hard problem. And
  what about language modules which aren't yet packaged? Should everyone who
  wants to use Fedora to deploy their application have to go through creating
  RPMs for each?
 Yeah I agree that this part needs fixing. Maybe automated packing
 helps. We are to much focused on packing
 and packages while a lot of that could be automated. You may not get
 the cleanest spec files that way but
 there was some distro created by Arjan I think that does it this way.

Yeah, so I think we're on the same page here.



 Yeah SCLs are a way to deal with this issue. But is it really
 incompatible with how we did Fedora in the past?

Traditionally, yes, although there's been some heroic guideline-writing
recently.

 Don't get me wrong I am not trying to stop Fedora.next I am just
 trying to understand what toughs lead to it.
 It looks like ok there are problems lets do stuff differently and see
 how it works out.

I hope we are and can be more intentional than that. Conversations like this
one help!

-- 
Matthew Miller--   Fedora Project--mat...@fedoraproject.org
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Fedora.next in 2014 -- Big Picture and Themes

On Thu, Jan 23, 2014 at 09:11:08PM -0500, Bill Nottingham wrote:
  I wasn't being dismissive.  I have seen no plans to alter the core of
  how Fedora, at a package level, is built.  In fact, if I did see a
  proposal that said we're not going to ship repositories or RPMs I'd
  be pretty damned upset, and I wouldn't support that.
 To be fair, I do recall Matt's original rings proposal discussing a
 core, different stacks on top of that, a 'commons' repository of packages, 
 and things like COPRs on the outside.  While it's not proposing moving
 away from repositories or RPMs, I did read that proposal as moving
 away from the current paradigm of One Big Repo Of Everything in favor
 of potentially multiple smaller repos. In that paradigm, things would
 change somewhat for users even if they were ignoring the N products.

I'm still not completely opposed to this. :) It would include managing
relationships (dependencies and conflicts) between the COPRs-like repos as
basically higher-level units than packages. That _would_ change the
experience -- although they'd still be repositories and still RPMs, at least
up until the application container level.

The repositories wouldn't necesssarily be completely decoupled -- think of
it more as policy separation like free and nonfree in... some other RPM
distributions meant to layer on top of Fedora. They work together and can
both be enabled at once (and packages from one can depend on packages from
the other, but, for example, maybe not the other way around).

But until we can really come up with clear reasons for a separation, I'm not
pushing for it.

-- 
Matthew Miller--   Fedora Project--mat...@fedoraproject.org
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Fedora.next in 2014 -- Big Picture and Themes

On Mon, Jan 27, 2014 at 01:53:56PM +, Ian Malone wrote:
 Cool. If I was to take this one step further then, an issue for Fedora
 Jam is we were limited in the customisations the could be made for a
 spin (e.g. defaulting users into certain groups to allow real time
 audio). While there's not enough of the developer base to make it an
 official product would there be a way to slot this into that
 framework?

Yes! Or at least I think so. This isn't worked out yet, but the idea I have
is that spins other than the three initial target products will become
secondary products, akin to secondary arches. (If we feel like secondary
seems too negative, we can come up with another word, but it works with
architectures.) We would correspondingly relax the restriction of
customizations. (I'm going to post about this in the Spins SIG for
discussion.)

-- 
Matthew Miller--   Fedora Project--mat...@fedoraproject.org
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Fedora.next in 2014 -- Big Picture and Themes

2014-01-28 Thread Adam Williamson

On Tue, 2014-01-28 at 20:34 +0100, Robert M. Albrecht wrote:
 Hi,
 
  * Although it's certainly not the only reason, Fedora as _solely_ a hobbyist
 desktop is not ideal for an upstream for RHEL server and cloud products.
 
 No other system can be reinstalled / upgraded every six months. That 
 single fact IMHO kills all other use cases.

Please stop repeating this argument. Fedora's lifecycle is ~13 months,
not six.

I have been running four production servers on Fedora for five years,
and find this to work perfectly well. Upgrading them takes me a weekend
every year.

 If I need a stable Fedora-like server, I get CentOS. It's kind of a 
 Fedora-LTS.
 
  * General trend in Linux towards the base distribution being boring and
 not mattering. I asked several dozen different people at a gigantic 
  Amazon
 conference why everyone was using the distribution they chose instead of
 Fedora, and the answer was almost universally oh, I don't care; that's
 not really an interesting question because there's nothing important at
 that level.
 
 All (of the big) distros are mature today. At the early days one chose 
 his distro by drivers, by installation-tool, by packages, ...
 
 Nowady every distro has a working installer, has a bazillion packages, 
 ... they basically all work.

There's a huge range of stuff to fix at the distro level. Lately I want
to clone myself ten times just to work on all the stuff I see that needs
fixing.

Just to wax philosophical for a minute: I think there's a lot of value
in building boring stuff that works well, and I might be weird, but I
wake up every day enthused by the prospect of doing it. The world needs
its Lennarts, but it also needs its pocket-protector dorks who spend all
day tightening the nuts and bolts on a platform that was cool ten
years earlier and is now so boring, out of date, stable...and essential.

It's not cool to work on a language that's been around and used in
production for decades (Python, perl, GCC...), or an operating system
installer, or a terminal app, or a text editor people have been using
for thirty years. You won't get on Hacker News or get a breathless
write-up in Wired. You won't get a massive VC funding round. But it is
*important*.

If you look at things that have been around forever and ever but are
still actively and carefully tended - python, GCC, vim, emacs, apache,
mariadb, etc etc etc etc etc etc etc - all the boring, 'stable' bits
that you're talking about - and compare them to projects that are
marginally maintained or not maintained at all, the difference is huge.

And yes, it's much harder to sell the story we work all day on
carefully and painstakingly improving something you've been using for
decades that already works pretty well than the story we're building
something SHINY and NEW!, even if the first thing is vital to the world
economy while the second is a lolcat generator. People do not always
have their priorities correctly wired, and neither do journalists
(rimshot, please!)

But perceptions are not reality, and I do think that people *do*
perceive the work done on 'boring', 'stable' projects, and differentiate
between them. They don't do so as consciously or immediately or clearly
as they look at SHINY NEW things, but they do. You see it happening
gradually, over time, and usually not as explicit statements, but rather
implied in other things.

Yeah, we spend a lot of time building the 'boring' nuts and bolts of an
operating system, and yeah, operating systems in general have got to the
point where they're 'boring', 'stable' things. You can probably pick one
blindfolded and be doing productive work on it in a half an hour (a
browser and a text editor and you're good to go!), and maybe if you're
asked about it straight up, you'll say the same kind of things as I'm
replying to here: it's a boring space, there's no real difference
between the choices any more, etc etc etc.

But I don't think we should rely on that conscious perception. The nuts
and bolts of this 'boring' operating system *are* important, and we
*are* providing substantial value by working on them, and people *do*
perceive that over time, even if they don't necessarily know it. Maybe
we don't get our Wired write-up (except when we do something really
crazy, or there's a giant political flamewar, or whatever), but that
doesn't mean we're not doing good and important work.

This doesn't mean I'm against doing Big Exciting New Things in general
or Fedora.next in particular, but I do want to stand up for the value of
just keeping your head down (hah, I know, Adam, practice what you
preach) and doing good, dull engineering work. With your pocket
protector firmly in place.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct:

Re: Fedora.next in 2014 -- Big Picture and Themes

2014-01-27 Thread Pierre-Yves Chibon

On Sat, Jan 25, 2014 at 11:20:33AM +0100, Thorsten Leemhuis wrote:
 Hi!
 
 On 23.01.2014 19:26, Josh Boyer wrote:
  On Thu, Jan 23, 2014 at 1:03 PM, Thorsten Leemhuis fed...@leemhuis.info 
  wrote:
  The packaging guidelines are very daunting.  Automating as much of
  that as possible, either through spec creation tooling or package
  review tooling would help.
 
 I think it's not only the packaging guidelines imho, it's the whole
 processes around package maintenance -- for existing packagers and
 newcomers.
 
 I for example recently saw that a package I used to maintain long ago
 was outdated in fedora 20. I chose to ignore it in the end, as I didn't
 want to nag the current maintainers via bugzilla (yes, I should have
 done that; sorry, was overly careful or lazy, but that's how people are
 quite often afaics); I would have preferred to simply do a fedpkg clone
 foo; update, build, quick test run and then submit it to rawhide,
 without fearing somebody might yell at me(¹). IOW: like editing a
 wikipedia page, even if that's in the end more work that simply filing a
 bug.
 
 (¹) Yes, I still have provenpackager rights, so I could have done that,
 but that wouldn't be considered appropriate under current rules

In pkgdb2, I'm replacing the wording 'Owner' by 'Point of contact' for this
exact reason, trying to get people to change their relation to 'their' package
into a relation where they are simply the primary point of contact, not a big
deal if someone updates it in rawhide w/o breaking too much.

Hopefully with time it will help changing things :)

Pierre
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Fedora.next in 2014 -- Big Picture and Themes

2014-01-27 Thread Ian Malone

On 23 January 2014 21:57, Adam Williamson awill...@redhat.com wrote:
 On Thu, 2014-01-23 at 16:54 -0500, Josh Boyer wrote:
 On Thu, Jan 23, 2014 at 4:49 PM, Adam Williamson awill...@redhat.com wrote:
  On Thu, 2014-01-23 at 13:48 -0500, Josh Boyer wrote:
 
   To be honest my concerns are more with my user hat on than my 
   contributor
   hat - that we will lose the gold standard unified packaging standards 
   and
   single source and mechanism for installing packages.
 
  I haven't seen anything from any WG that would suggest a deviation
  from RPM packaging guidelines or using separate repositories.  It is a
  valid concern and one we need to keep an eye on.
 
  Um. As I read it, three out of four WGs - desktop, server, and cloud -
  have at least discussed the possibility of implementing what are, in
  essence, secondary package management layers. The details differ - 'app
  bundles' for desktop, 'containers' or whatever for server and cloud -
  but the effect is the same.

 Secondary being the key word.  None of them are proposing alternate
 RPM repositories or changing the Fedora packaging guidelines.  Tom was
 expressing that he is concerned the Fedora repos would go away or be
 of decreased quality.  None of the WG proposals are altering those
 repos.  They will still exist, much as they do today.

 The repos will still exist, but things will be different. At present,
 the Fedora repos are the single unified official Fedora method for
 deploying software on Fedora products. Any other method you can use to
 deploy software is not an 'official Fedora' thing.

 If these plans go ahead, we will have multiple official/blessed methods
 for deploying software on Fedora, potentially with different policies
 about what software they can include and how that software should be
 arranged, how dependencies should be handled, and all the rest of it.
 Some of these methods will be shared between products, and some will
 either only exist in certain products, or at least be clearly associated
 with and 'owned' by those products.

So without, unfortunately, the time to read through reams of stuff on
this and with my user hat on (don't think I've seen any discussion of
this on the users list), if it means how fedora actually works is
better thought out then that's a good thing, but does this mean there
will be things unavailable on some 'products' that are not on others?
At the minute you install a spin and can add whatever other packages.
That's great if you want to do something like set up a quick web
server for testing or stream some music without creating VMs
everywhere. It sounds a bit like this plan may end up with finding you
can't do X on a Fedora system because you installed the wrong flavour.

-- 
imalone
http://ibmalone.blogspot.co.uk
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Fedora.next in 2014 -- Big Picture and Themes

2014-01-27 Thread Stephen Gallagher

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 01/27/2014 05:36 AM, Ian Malone wrote:
 So without, unfortunately, the time to read through reams of stuff
 on this and with my user hat on (don't think I've seen any
 discussion of this on the users list), if it means how fedora
 actually works is better thought out then that's a good thing, but
 does this mean there will be things unavailable on some 'products'
 that are not on others? At the minute you install a spin and can
 add whatever other packages. That's great if you want to do
 something like set up a quick web server for testing or stream some
 music without creating VMs everywhere. It sounds a bit like this
 plan may end up with finding you can't do X on a Fedora system
 because you installed the wrong flavour.
 

No.

The Products will be defining an environment and a standard install
set. They may have separate initial *installation* repositories if
they need to provide different options to Anaconda, but beyond that
the intent is for all of the Products to continue to draw from the
same store of packages together.

If (for example) we got ourselves into a situation where you couldn't
install Fedora Server and then also install the GNOME desktop
environment on that Server, this would be considered a major bug and
one that we would need to reconcile immediately.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iEYEARECAAYFAlLmWdMACgkQeiVVYja6o6P0twCfRk46ssphyt3+iZUnbh/t4TrG
+FEAoINANDTuTrd+jEY8rFLydsna8obW
=bmho
-END PGP SIGNATURE-
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Fedora.next in 2014 -- Big Picture and Themes

2014-01-27 Thread Ian Malone

On 27 January 2014 13:06, Stephen Gallagher sgall...@redhat.com wrote:

 On 01/27/2014 05:36 AM, Ian Malone wrote:

 does this mean there will be things unavailable on some 'products'
 that are not on others?

 No.

 The Products will be defining an environment and a standard install
 set. They may have separate initial *installation* repositories if
 they need to provide different options to Anaconda, but beyond that
 the intent is for all of the Products to continue to draw from the
 same store of packages together.

 If (for example) we got ourselves into a situation where you couldn't
 install Fedora Server and then also install the GNOME desktop
 environment on that Server, this would be considered a major bug and
 one that we would need to reconcile immediately.

Cool. If I was to take this one step further then, an issue for Fedora
Jam is we were limited in the customisations the could be made for a
spin (e.g. defaulting users into certain groups to allow real time
audio). While there's not enough of the developer base to make it an
official product would there be a way to slot this into that
framework?

-- 
imalone
http://ibmalone.blogspot.co.uk
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Fedora.next in 2014 -- Big Picture and Themes

2014-01-27 Thread Alec Leamas

On Sat, 2014-01-25 at 12:04 +0100, Alec Leamas wrote:


  After hacking a simple tool which provides a GUI for a repository file
  it's possible to create repository packages complete with  desktop and
  appdata file. I have some 5-10 such repository packages under way, my
  plan is to push them into rpmfusion.

 http://rpmfusion.org/Contributors#Read_the_packaging_guidelines

 RPM Fusion follows the Fedora packaging guidelines, make sure you've
 read and understood these:

Naming Guidelines



 Guidelines is a link to
 https://fedoraproject.org/wiki/Packaging:Guidelines :

 Configuration for package managers in Fedora MUST ONLY reference the
 official Fedora repositories in their default enabled and disabled state
 (see the yum repo configuration in the fedora-release package for the
 canonical list). Unofficial and third-party repositories that contain
 only packages that it is legal for us to direct people to in Fedora (see
 the Forbidden items and Licensing:Main pages for an explanation of what
 is legal) may be shipped in %{_docdir}. The idea is that the system
 administrator would need to explicitly copy the configuration file from
 doc into the proper location on the filesystem if they want to enable
 the repository.

 Presumably one is to s/Fedora/RPMFusion and Fedora/g/ when reading that
 as applying to Fusion, but still, Fusion's policies would appear to
 forbid you to ship packages that contain 'active' external repository
 configuration.

  If there will be a way for users to aggregate appdata from different
  sources such as rpmfusion  (don't fully really understand this process
  right now) users will be able to search and find also non-free items
  as long there is a packaged repository for them. It should work out of
  the box right now using old-school tools based on package metadata.

 Not ideal, but perhaps something.

 So I found this point interesting in thinking about these issues this
 morning. There was a post of Hughesie's (I think) in another thread
 which was also illuminating: it suggested the design of Software is to
 be a generic 'software' installer - to provide as much 'software' from
 as many sources as possible, under the 'it's all just software' theory,
  guess.

 I think the assumption that this is obviously the right design is
 interesting, because I strongly disagree - not just for legal or policy
 reasons, but because that's most definitely *not* what I want. I
 cut]

---

Sorry for badly formatted reply - lost the original in my mailbox and
only have this web UI right now :(.

Anyway,  I have submitted [1], a rpmfusion review request for
dropbox-repo. A real case should hopefully provide a sound base for
remaining things to discuss.

--alec

[1] https://bugzilla.rpmfusion.org/show_bug.cgi?id=3152

On 1/27/14, Stephen Gallagher sgall...@redhat.com wrote:
 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1

 On 01/27/2014 05:36 AM, Ian Malone wrote:
 So without, unfortunately, the time to read through reams of stuff
 on this and with my user hat on (don't think I've seen any
 discussion of this on the users list), if it means how fedora
 actually works is better thought out then that's a good thing, but
 does this mean there will be things unavailable on some 'products'
 that are not on others? At the minute you install a spin and can
 add whatever other packages. That's great if you want to do
 something like set up a quick web server for testing or stream some
 music without creating VMs everywhere. It sounds a bit like this
 plan may end up with finding you can't do X on a Fedora system
 because you installed the wrong flavour.


 No.

 The Products will be defining an environment and a standard install
 set. They may have separate initial *installation* repositories if
 they need to provide different options to Anaconda, but beyond that
 the intent is for all of the Products to continue to draw from the
 same store of packages together.

 If (for example) we got ourselves into a situation where you couldn't
 install Fedora Server and then also install the GNOME desktop
 environment on that Server, this would be considered a major bug and
 one that we would need to reconcile immediately.
 -BEGIN PGP SIGNATURE-
 Version: GnuPG v1
 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

 iEYEARECAAYFAlLmWdMACgkQeiVVYja6o6P0twCfRk46ssphyt3+iZUnbh/t4TrG
 +FEAoINANDTuTrd+jEY8rFLydsna8obW
 =bmho
 -END PGP SIGNATURE-
 --
 devel mailing list
 devel@lists.fedoraproject.org
 https://admin.fedoraproject.org/mailman/listinfo/devel
 Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Fedora.next in 2014 -- Big Picture and Themes

2014-01-27 Thread Jóhann B. Guðmundsson



On 01/27/2014 01:06 PM, Stephen Gallagher wrote:

No.

The Products will be defining an environment and a standard install
set. They may have separate initial*installation*  repositories if
they need to provide different options to Anaconda, but beyond that
the intent is for all of the Products to continue to draw from the
same store of packages together.

If (for example) we got ourselves into a situation where you couldn't
install Fedora Server and then also install the GNOME desktop
environment on that Server, this would be considered a major bug and
one that we would need to reconcile immediately.


So what exactly changes if the above step is considered a major bug?
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Fedora.next in 2014 -- Big Picture and Themes

2014-01-26 Thread Alec Leamas

On 1/25/14, Adam Williamson awill...@redhat.com wrote:
 On Sat, 2014-01-25 at 12:04 +0100, Alec Leamas wrote:


 After hacking a simple tool which provides a GUI for a repository file
 it's possible to create repository packages complete with  desktop and
 appdata file. I have some 5-10 such repository packages under way, my
 plan is to push them into rpmfusion.

 http://rpmfusion.org/Contributors#Read_the_packaging_guidelines

I know this is controversial. I've also heard some rumours about
Fedora using something they call Packaging Guidelines. Has anyone
some  information  on this topic? ;)

Can we just for the sake of discussion leave this formal side of it, for now?

 So I found this point interesting in thinking about these issues this
 morning. There was a post of Hughesie's (I think) in another thread
 which was also illuminating: it suggested the design of Software is to
 be a generic 'software' installer - to provide as much 'software' from
 as many sources as possible, under the 'it's all just software' theory,
 I guess.

 I think the assumption that this is obviously the right design is
 interesting, because I strongly disagree - not just for legal or policy
 reasons, but because that's most definitely *not* what I want. I don't
 want a 'greedy' software installer that just finds every piece of crap
 on the internet and offers it to me. I appreciate the curation that

I don't know if this is  Hughesie's vision. Anyway, it's certainly not
mine. Adding whatever software available out there to the repos is a
Bad Idea. Agreed

That said,, IMHO  we actually need  to be better on delivering what
people need. Some of this is not in Fedora's repos. This is already
acknowledged here and there. E. g., rpmfusion has  list of
repositories which are known to work with rpmfusion [1]. For fedora,
we have e. g. jpackage, which is stated s compatible in the Java GL.

I'm trying to find some middle ground here. Instead of just enabling
repos, perhaps when installing something else, I'm trying  a process
where each and every repository added is packaged separately. Hence,
here is also  separate review for each repository. And even if
installed, it's not enabled until l explicitly configured by user..

I see all the problems when using things like pip, gem etc. However,
this is not anything like this. It's about letting users install
carefully selected repositories which are known to work with Fedora.
Doing it this way, we also create a difference to other repositories
which are not endorsed.  Also this is something we need badly IMHO.

It's also  task which naturally belongs to rpmfusion, mostly the
non-free section.

--alec.

[1] http://rpmfusion.org/FedoraThirdPartyRepos
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Fedora.next in 2014 -- Big Picture and Themes

2014-01-26 Thread Aleksandar Kurtakov

- Original Message -
 From: Alec Leamas leamas.a...@gmail.com
 To: Development discussions related to Fedora 
 devel@lists.fedoraproject.org
 Sent: Sunday, January 26, 2014 11:22:36 AM
 Subject: Re: Fedora.next in 2014 -- Big Picture and Themes

 On 1/25/14, Adam Williamson awill...@redhat.com wrote:
  On Sat, 2014-01-25 at 12:04 +0100, Alec Leamas wrote:

  After hacking a simple tool which provides a GUI for a repository file
  it's possible to create repository packages complete with  desktop and
  appdata file. I have some 5-10 such repository packages under way, my
  plan is to push them into rpmfusion.

  http://rpmfusion.org/Contributors#Read_the_packaging_guidelines

 I know this is controversial. I've also heard some rumours about
 Fedora using something they call Packaging Guidelines. Has anyone
 some  information  on this topic? ;)

 Can we just for the sake of discussion leave this formal side of it, for now?

  So I found this point interesting in thinking about these issues this
  morning. There was a post of Hughesie's (I think) in another thread
  which was also illuminating: it suggested the design of Software is to
  be a generic 'software' installer - to provide as much 'software' from
  as many sources as possible, under the 'it's all just software' theory,
  I guess.

  I think the assumption that this is obviously the right design is
  interesting, because I strongly disagree - not just for legal or policy
  reasons, but because that's most definitely *not* what I want. I don't
  want a 'greedy' software installer that just finds every piece of crap
  on the internet and offers it to me. I appreciate the curation that

 I don't know if this is  Hughesie's vision. Anyway, it's certainly not
 mine. Adding whatever software available out there to the repos is a
 Bad Idea. Agreed

 That said,, IMHO  we actually need  to be better on delivering what
 people need. Some of this is not in Fedora's repos. This is already
 acknowledged here and there. E. g., rpmfusion has  list of
 repositories which are known to work with rpmfusion [1]. For fedora,
 we have e. g. jpackage, which is stated s compatible in the Java GL.

I feel obligated to comment on this. JPackage and Fedora have taken different 
routes years ago and installing JPackage rpm on top of Fedora will likely break 
Fedora packages due to:
* additional OSGi metadata Fedora ships but JPackage doesn't
* different places of maven pom and depmap changes
* different major versions of the same package (aka maven package in JPackage 
was 1.x (last I checked) but in Fedora it's 3.x) and etc.

Would you please point to a place where jpackage is stated as compatible? This 
is probably a legacy page which needs to be updated with current state of 
affairs so people don't think they can mix and match freely.

Alexander Kurtakov
Red Hat Eclipse team

 I'm trying to find some middle ground here. Instead of just enabling
 repos, perhaps when installing something else, I'm trying  a process
 where each and every repository added is packaged separately. Hence,
 here is also  separate review for each repository. And even if
 installed, it's not enabled until l explicitly configured by user..

 I see all the problems when using things like pip, gem etc. However,
 this is not anything like this. It's about letting users install
 carefully selected repositories which are known to work with Fedora.
 Doing it this way, we also create a difference to other repositories
 which are not endorsed.  Also this is something we need badly IMHO.

 It's also  task which naturally belongs to rpmfusion, mostly the
 non-free section.

 --alec.

 [1] http://rpmfusion.org/FedoraThirdPartyRepos
 --
 devel mailing list
 devel@lists.fedoraproject.org
 https://admin.fedoraproject.org/mailman/listinfo/devel
 Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Fedora.next in 2014 -- Big Picture and Themes

2014-01-26 Thread Nikos Roussos



Thorsten Leemhuis fed...@leemhuis.info wrote:
On 25.01.2014 17:35, Adam Williamson wrote:
 On Sat, 2014-01-25 at 11:20 +0100, Thorsten Leemhuis wrote:
 
 Debian, who has a similar stance on
 non-free Software, does a way better job in that area than Fedora
does.
 Well, not really - they don't have a 'similar stance', they have an
 official non-free repository. That's kind of a significant
 difference. :)

Ha, Debian and Fedora, the distributions, are imo not that different
after a standard install (but yes, there are differences as well -
patents strategy, Firmware). But yes, you are right, the Debian project
has a a official non-free repository, which is a significant difference
to the Fedora project. One that leads to a better user experience;
something that afics a lot of Fedora users and some Fedoraproject
developers want to see as well.

Let's avoid personal examples. I also know many users and Fedora contributors
that respect Fedora's foundations and would probably leave Fedora if these were 
to change. 

 That's why I think it would be good if
the the Fedora project might help/guide in that are, even if the
resulting repo and the main work is done outside of the Fedora project.

I agree with guidance. I don't think anyone would object to help them, 
so that *they* can ship their software for Fedora in a more UX friendly way. 

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Fedora.next in 2014 -- Big Picture and Themes

2014-01-26 Thread Alec Leamas

On 1/26/14, Aleksandar Kurtakov akurt...@redhat.com wrote:

 I feel obligated to comment on this. JPackage and Fedora have taken
 different routes years ago and installing JPackage rpm on top of Fedora will
 likely break Fedora packages due to:
 * additional OSGi metadata Fedora ships but JPackage doesn't
 * different places of maven pom and depmap changes
 * different major versions of the same package (aka maven package in
 JPackage was 1.x (last I checked) but in Fedora it's 3.x) and etc.

 Would you please point to a place where jpackage is stated as compatible?
 This is probably a legacy page which needs to be updated with current state
 of affairs so people don't think they can mix and match freely.

 Alexander Kurtakov
 Red Hat Eclipse team
Oops, bad example it seems. Had the link at hand yesterday, don't find it now.

Now let's drop jpackage in this discussion. It is obviously a bad
example. But in a way, it's also a good one. Given your statement, I
find it highly unlikely that  a packaged jpackage repo would have
survived a package review, if at all submitted. IMHO, this is really
the important issue here.

--alec
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Fedora.next in 2014 -- Big Picture and Themes

Hi!

On 23.01.2014 19:26, Josh Boyer wrote:
 On Thu, Jan 23, 2014 at 1:03 PM, Thorsten Leemhuis fed...@leemhuis.info 
 wrote:
 
 […]

Thx for your answer, just replying to some parts of it where I feel that
making additional statements bring the discussion forward.

 What really gives me the creeps on those pages: sub-committees of
 FESCo, with individual governance structures. Those afaics are three
 Product Working Groups Workgroups, two Fedora Rings Working Groups and
 the Inter-WG for coordination. That sounds like a awful lot of
 overhead an even more bureaucracy than we already have. And we imho
 have way to much already (part of it is my fault!) – something I had
 hoped Fedora.next would try to fix.
 It is more overhead to a degree.  On the other hand, the idea is to
 enable people that are interested in specific areas to go forth and
 create a Fedora deliverable that they think meets the needs of those
 areas best, without having to pass everything through FESCo.  FESCo
 just doesn't scale like that.

Sure, but I doubt that more committees are the best way to solve that.
I'm wondering if a development approach that more resembles the Linux
kernel would be better. Sure, the kernel also has people (not
committees!) that steer things and some rules (a lot not written down,
which has benefits imo). And in the end it's a lot if you want
something crazy new realized you can do that as long as you do not break
the things others care about. More of that attitude and less
rules/committees is something I'd like to see in Fedora.

 I these days wouldn't start contributing to Fedora, as all those rules
 and guidelines that the wiki provides would scare me off. That's what
 Fedora.next should fix imo, as we afaics need more contributors: I
 more often than a few years ago find packages in Fedora that are badly
 maintained or outdated. Contributing must be as easy as editing a
 The packaging guidelines are very daunting.  Automating as much of
 that as possible, either through spec creation tooling or package
 review tooling would help.

I think it's not only the packaging guidelines imho, it's the whole
processes around package maintenance -- for existing packagers and
newcomers.

I for example recently saw that a package I used to maintain long ago
was outdated in fedora 20. I chose to ignore it in the end, as I didn't
want to nag the current maintainers via bugzilla (yes, I should have
done that; sorry, was overly careful or lazy, but that's how people are
quite often afaics); I would have preferred to simply do a fedpkg clone
foo; update, build, quick test run and then submit it to rawhide,
without fearing somebody might yell at me(¹). IOW: like editing a
wikipedia page, even if that's in the end more work that simply filing a
bug.

(¹) Yes, I still have provenpackager rights, so I could have done that,
but that wouldn't be considered appropriate under current rules

 wikipedia page. Further: kororaproject.org, fedorautils-installer and
 similar project show that there are people that want to make Fedora
 better. But they do their work outside of Fedora and RPM Fusion;
 fixing the issues directly at the root would be better for all of us.
 Small note:  The two projects you use as an example are required to do
 what they're doing (in part) outside of Fedora for legal reasons.  I
 don't believe Fedora.next will change how US law works, so it might
 not be the best of examples.

Hmmm. Maybe it were bad examples. But I guess I didn't actually explain
the point I was trying to make properly. So here we go in different
words after a few more quotes lines:

 (And we have a Board meeting to discuss related things that are not
 legally prohibited.)
(for the archives: see
https://lists.fedoraproject.org/pipermail/advisory-board/2014-January/012433.html
for context and outcome; in short: the Fedora board voted against the
proposal to allow 3rd party repos in the App installer)

The Fedoraproject once again chose to leave non-free out of Fedora. I
appreciate that. I even think a lot of users understand why the
Fedoraproject acts like this (now and earlier, too). But: it utterly
hard to get non-free Software when running Fedora. That's what the
Fedora ecosystem IMHO needs to fix. Debian, who has a similar stance on
non-free Software, does a way better job in that area than Fedora does.
We need to catch up here and I think the Fedoraproject should drive
this, because it's important for the success of Fedora (and RHEL/CentOS)
that people can easily use it for what they want. And as the down-voted
proposal shows: There are developers within the Fedoraproject that are
willing to do the work; there are more in Korora, RPM Fusion and other
places. We just need to bring them together properly afiacs.

Obviously those developers need a place to do their work. I think RPM
Fusion is that, as it's well established and something a lot of people
all to Fedora anyway. But yes, RPM Fusion contains packages that are
problematic under

Re: Fedora.next in 2014 -- Big Picture and Themes

2014-01-25 Thread Alec Leamas

On Sat, Jan 25, 2014 at 11:20 AM, Thorsten Leemhuis fed...@leemhuis.infowrote:

 [cut]

 The Fedoraproject once again chose to leave non-free out of Fedora. I
 appreciate that. I even think a lot of users understand why the
 Fedoraproject acts like this (now and earlier, too). But: it utterly
 hard to get non-free Software when running Fedora. That's what the
 Fedora ecosystem IMHO needs to fix. Debian, who has a similar stance on
 non-free Software, does a way better job in that area than Fedora does.
 We need to catch up here and I think the Fedoraproject should drive
 this, because it's important for the success of Fedora (and RHEL/CentOS)
 that people can easily use it for what they want.


+1
Indeed. And to be frank it's not only about non-free software, it's just
about anything which if not is Not invented Here at least is Not
Packaged Here.


 And as the down-voted
 proposal shows: There are developers within the Fedoraproject that are
 willing to do the work; there are more in Korora, RPM Fusion and other
 places. We just need to bring them together properly afiacs.


I'm also on this. After the lpf effort trying to cope with
non-redistributable sw (skype, spotify, flash...) I'm now trying a
simplistic way top make foreign repositories more visible and usable.:

After hacking a simple tool which provides a GUI for a repository file it's
possible to create repository packages complete with  desktop and appdata
file. I have some 5-10 such repository packages under way, my plan is to
push them into rpmfusion.

If there will be a way for users to aggregate appdata from different
sources such as rpmfusion  (don't fully really understand this process
right now) users will be able to search and find also non-free items  as
long there is a packaged repository for them. It should work out of the box
right now using old-school tools based on package metadata.

Not ideal, but perhaps something.

--alec
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Fedora.next in 2014 -- Big Picture and Themes

Hi!

On 23.01.2014 20:57, Matthew Miller wrote:
On Thu, Jan 23, 2014 at 07:03:02PM +0100, Thorsten Leemhuis wrote:
Okay, I'll bite (after thinking whether writing this mail is worth it):
Thanks. I hope that I can make you feel that it was.

Thx for your answer – yes, I think it was worth it. But I hope I don't
get a Fedora badge that says started a discussion in
devel@fedoraproject that made it to Phoronix ;-)

[...]
I will be giving a talk on Sunday, February 9th in at DevConf in Brno, CZ,
and I'll post slides from that (probably here as text as well), and I assume
there will be video.

That's great (I'll be there; Fosdem as well), but please allow me a side
note here: Videos and IRC logs are a great resource if you really care
about something and want to know all the details. But the ratio for
time spend watching/reading vs. information gathered is often quite
bad. That's why written, easy to read summaries are important. And I
think we got too few of them from Flock last year, which is one of the
reason why I had/have problems to fully understand Fedora.next.

[...]
But also, I want to go back to the first part of my message that you're
responding to. I don't think our current online communication structure
really works very well for the kind of contributor you're concerned about.
(Let alone working very well for more active contributors who still don't
have time to read every list or hang out on IRC 24/7.) I think we need to
fix that, whether we consider that part of Fedora.next or a separate big
initiative.

Agreed. For example, +1/like-Buttons for a mailing list would be good
afaics, to get a rough impression how people think (just wondering: will
hyperkitty or something from that camp of developers have this?). But
that's just one thing that springs to my mind and a different topic.

In addition: A few days ago someone shared the article Top 10 ways to
ensure your best people will quit on G+:
http://www.ragan.com/Main/Articles/Top_10_ways_to_ensure_your_best_people_will_quit_47779.aspx
I normally don't read or like things like that much, but I enjoyed this
one. And I wondered if all of those points are relevant for Fedora as
well. I tend to think they are. Point 3 for example made me wonder if
every few months we should ask developers if they are happy with the
current state and how things evolve. Obviously automated web based
questioning system or something like that. Something simple could do for
the start. That way we could get early warning signs if developers are
unhappy, to do something before they leave.

I have many more thoughts in my head, but I'll stop here, as those are
basically the most important things that bother me right now when
looking at Fedora and Fedora.next.
I appreciate it. Does anything I've said help you feel better about it?

To be honest: only a little bit. Fedora.next simply is so big (I'm
wondering if too much is cramped into it) and still vague in some parts
that I remain careful. But that's not unusual, I'm quite sceptic all the
time and more of a pessimist ;-)

[...]
I would like to hear more of your thoughts, too.

In the past few months a few people encouraged be to write down how I'd
design Fedora if I could. Maybe I should finally do that – but OTOH I'm
not sure if that is worth the work and if it's really helpful for the
curent debate.

And for now I have something else I need to take care of first:
preparing my devconf talk :D

Cu have a nice weekend everyone
knurd
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Fedora.next in 2014 -- Big Picture and Themes

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Hi!

On 23.01.2014 22:33, Kevin Fenzi wrote:
 On Thu, 23 Jan 2014 19:03:02 +0100 Thorsten Leemhuis
 fed...@leemhuis.info wrote:
 On 03.01.2014 19:14, Matthew Miller wrote:
 […] So those are my things. What do you think about them? What 
 else should be included? What different directions should we 
 consider? How will we make Fedora more awesome than ever in
 the coming year?
 Okay, I'll bite (after thinking whether writing this mail is
 worth it):
 Hey Thorsten! Glad you did. ;)

:)

 I'm still undecided if I overall like Fedora.next or fear it. But
 more and more I tend to the latter position and wonder if it
 might be wise to slow things down: Do one more Fedora release the
 old style in round about June; that would give us more time to
 better discuss and work out Fedora.next and get contributors
 involved better in the planing.
 This is not practical. Lots of people are thinking about a 
 fedora.next, qa folks are coding away, lots of people who normally 
 would be working on the next release are not. If we tell them to
 stop all that and go back to normal, we could, but then fedora.next
 will likely never ever happen.

Understood, but OTOH it makes me wonder if Fedora.next is a step to
big and needs to be split or something.

 [...] The current problem I have with Fedora.next is that it's so
 abstract. I understand that people who like PRD's and TPS want high
 level descriptions of what we want to do with goals and visions and
 such, and thats great. However, I'm a technical person. I like
 concrete plans and pushing what we can do with the technology we
 have at hand, or helping to make new technology to do what we want.
 
+1 you found really good words for what's a big part of the problem I
have with Fedora.next

 We are now down to the point where groups have written up their
 PRD documents, and can get down to details. So, I am hopeful in the
 next month or so we will gain a lot more interest in fedora.next
 and more feedback as concrete deliverables are discussed, etc.
 
 That is my hope at least... we will see. :)

Yeah, we'll see :D

Your words otoh scratched another thought in my head: The PRD
documents (and some of the other docs around Fedora.next) in great
length talk a lot about how they want to do something. That up to a
point is needed obviously. But sometimes I miss a few introductions
words on the why we want all of that and how it's supposed to make
Fedora better. But that's obviously meta/abstract again, which I
myself criticized earlier. So maybe it's simply this ted talk that
stuck in my head too much:
http://www.ted.com/talks/simon_sinek_how_great_leaders_inspire_action.html

Cu
knurd
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBCgAGBQJS46KJAAoJEHK25u9MWD0tf8oQAKamRcqVt8XTbh8TmjfWxqqc
AeP5MVmJnhE9TEbgsenZUex0xo3dnRaU9prdF/delAVgL7ahCbIPWgKtKT3IsqsA
GHygf8d046PM2+z8lFH8IAinK5KhikmRki/xS+3IknHEPWUKmGcFtIG13L2C32w/
VEZ+/IF70NEa2xe7jtg0QzH4uungZfVH6Gsl2WcsjnjC0BiqU5vkVjdDWKWCt+GD
taAL5pNbO1TsuAhnNa4PL/eHJehEGUo1UrLv4FDnPFLm4v6Wex9VScd6Z2XQ6VLu
I2Lw5RqU5m0kNPa5k4+gEABqDrqObK6Q+akwX/c97Tcus52SwmIQA4yHGHsIQy2c
hSeg/mQyzZHabob909EPu2y6/m49uEpmU8sgb7QqQzIk77rKaUQrGloPSOTrAs6j
TSMtZX/DkF6VZIBATSTtOJD7pL3jvCWOb66ueA+MJqGZdB3WiuB7En+9JTrhjYSe
mEs9KORkYgyQniVTlhtVG9tu8/OFvt8ud+iq+FlAVzyHAfDofpC+w7WnkSSn3Mit
wEEgsvuYx630z+HY2+aBBViU+/11D1G8lVBJqGINogPRxopTpN9EPCbvAOnHmwd3
iOqsPzsUjZCviXasjIrrj91QDXduS/N3sFCam1dq2CqXF692ampEzAfavu/VX9yB
jfSdBXA1/7Vk/MLXgB6E
=BoBF
-END PGP SIGNATURE-
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Fedora.next in 2014 -- Big Picture and Themes

Hi!

On 23.01.2014 22:45, Adam Williamson wrote:
 On Thu, 2014-01-23 at 19:03 +0100, Thorsten Leemhuis wrote:
 
 wikipedia page. Further: kororaproject.org, fedorautils-installer and
 similar project show that there are people that want to make Fedora
 better. But they do their work outside of Fedora and RPM Fusion;
 fixing the issues directly at the root would be better for all of us.
 Those particular examples are very bad examples because they are doing
 things Fedora explicitly chooses not to do, [...]

See my reply in
https://lists.fedoraproject.org/pipermail/devel/2014-January/194581.html
as that hopefully better explains what I had up in my mind.

 [...]
 And the lead Korora dev is an active Fedora contributor.

I know, but for me Korora, fedorautils-installer, and similar things are
a sign that some problems in Fedora and RPM Fusion get circumvented in
to many layers instead of being solved at their root. It reminds me of a
kernel enhancement that is maintained outside of the Linux kernel: they
often solve real problems and some users love them, but it's better for
everyone to get a proper solution upstream, as that's the way to reach
the masses and make things simply work.

Cu
knurd
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Fedora.next in 2014 -- Big Picture and Themes

2014-01-25 Thread Adam Williamson

On Sat, 2014-01-25 at 11:20 +0100, Thorsten Leemhuis wrote:

 Debian, who has a similar stance on
 non-free Software, does a way better job in that area than Fedora does.

Well, not really - they don't have a 'similar stance', they have an
official non-free repository. That's kind of a significant
difference. :)
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Fedora.next in 2014 -- Big Picture and Themes

2014-01-25 Thread Adam Williamson

On Sat, 2014-01-25 at 12:04 +0100, Alec Leamas wrote:


 After hacking a simple tool which provides a GUI for a repository file
 it's possible to create repository packages complete with  desktop and
 appdata file. I have some 5-10 such repository packages under way, my
 plan is to push them into rpmfusion.   

http://rpmfusion.org/Contributors#Read_the_packaging_guidelines

RPM Fusion follows the Fedora packaging guidelines, make sure you've
read and understood these:

Naming Guidelines

Guidelines

Guidelines is a link to
https://fedoraproject.org/wiki/Packaging:Guidelines :

Configuration for package managers in Fedora MUST ONLY reference the
official Fedora repositories in their default enabled and disabled state
(see the yum repo configuration in the fedora-release package for the
canonical list). Unofficial and third-party repositories that contain
only packages that it is legal for us to direct people to in Fedora (see
the Forbidden items and Licensing:Main pages for an explanation of what
is legal) may be shipped in %{_docdir}. The idea is that the system
administrator would need to explicitly copy the configuration file from
doc into the proper location on the filesystem if they want to enable
the repository.

Presumably one is to s/Fedora/RPMFusion and Fedora/g/ when reading that
as applying to Fusion, but still, Fusion's policies would appear to
forbid you to ship packages that contain 'active' external repository
configuration.

 If there will be a way for users to aggregate appdata from different
 sources such as rpmfusion  (don't fully really understand this process
 right now) users will be able to search and find also non-free items
 as long there is a packaged repository for them. It should work out of
 the box right now using old-school tools based on package metadata.

 Not ideal, but perhaps something.

So I found this point interesting in thinking about these issues this
morning. There was a post of Hughesie's (I think) in another thread
which was also illuminating: it suggested the design of Software is to
be a generic 'software' installer - to provide as much 'software' from
as many sources as possible, under the 'it's all just software' theory,
I guess.

I think the assumption that this is obviously the right design is
interesting, because I strongly disagree - not just for legal or policy
reasons, but because that's most definitely *not* what I want. I don't
want a 'greedy' software installer that just finds every piece of crap
on the internet and offers it to me. I appreciate the curation that
repositories provide, I tend my repository configuration carefully, and
I really do only want to be offered software from my configured
repositories as a matter of course, and yes, I do not expect that the
packages from my configured repos will go and set up other repos, and I
would be quite angry if they did.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Fedora.next in 2014 -- Big Picture and Themes

2014-01-25 Thread Adam Williamson

On Sat, 2014-01-25 at 08:43 -0800, Adam Williamson wrote:

 Guidelines is a link to
 https://fedoraproject.org/wiki/Packaging:Guidelines :
 
 Configuration for package managers in Fedora MUST ONLY reference the
 official Fedora repositories in their default enabled and disabled state
 (see the yum repo configuration in the fedora-release package for the
 canonical list). Unofficial and third-party repositories that contain
 only packages that it is legal for us to direct people to in Fedora (see
 the Forbidden items and Licensing:Main pages for an explanation of what
 is legal) may be shipped in %{_docdir}. The idea is that the system
 administrator would need to explicitly copy the configuration file from
 doc into the proper location on the filesystem if they want to enable
 the repository.
 
 Presumably one is to s/Fedora/RPMFusion and Fedora/g/ when reading that
 as applying to Fusion, but still, Fusion's policies would appear to
 forbid you to ship packages that contain 'active' external repository
 configuration.

Of course, it's interesting to read the above and then reflect on the
situation of pip, rubygems, pear etc etc etc etc etc. Presumably the
term 'package managers' is being interpreted very narrowly...
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Fedora.next in 2014 -- Big Picture and Themes

2014-01-25 Thread Kevin Fenzi

On Sat, 25 Jan 2014 12:16:40 +0100
Thorsten Leemhuis fed...@leemhuis.info wrote:

...snip...
 
 Agreed. For example, +1/like-Buttons for a mailing list would be
 good afaics, to get a rough impression how people think (just
 wondering: will hyperkitty or something from that camp of developers
 have this?). But that's just one thing that springs to my mind and a
 different topic.

Yes, hyperkitty does have this ability. ;) 

It's not been synced lately, so I can't +1 your post, but you can look
at our staging instance: 

https://lists.stg.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/2014//

kevin


signature.asc
Description: PGP signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Fedora.next in 2014 -- Big Picture and Themes

2014-01-25 Thread Kevin Fenzi

On Sat, 25 Jan 2014 09:59:12 -0700
Kevin Fenzi ke...@scrye.com wrote:

 On Sat, 25 Jan 2014 12:16:40 +0100
 Thorsten Leemhuis fed...@leemhuis.info wrote:
 
 ...snip...
  
  Agreed. For example, +1/like-Buttons for a mailing list would be
  good afaics, to get a rough impression how people think (just
  wondering: will hyperkitty or something from that camp of developers
  have this?). But that's just one thing that springs to my mind and a
  different topic.
 
 Yes, hyperkitty does have this ability. ;) 
 
 It's not been synced lately, so I can't +1 your post, but you can look
 at our staging instance: 
 
 https://lists.stg.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/2014//

Oops. That should be: 

https://lists.stg.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/2014/1/

I somehow dropped the 1 there. ;( 

Sorry about that... 

kevin


signature.asc
Description: PGP signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Fedora.next in 2014 -- Big Picture and Themes

On 25.01.2014 17:35, Adam Williamson wrote:
 On Sat, 2014-01-25 at 11:20 +0100, Thorsten Leemhuis wrote:
 
 Debian, who has a similar stance on
 non-free Software, does a way better job in that area than Fedora does.
 Well, not really - they don't have a 'similar stance', they have an
 official non-free repository. That's kind of a significant
 difference. :)

Ha, Debian and Fedora, the distributions, are imo not that different
after a standard install (but yes, there are differences as well -
patents strategy, Firmware). But yes, you are right, the Debian project
has a a official non-free repository, which is a significant difference
to the Fedora project. One that leads to a better user experience;
something that afics a lot of Fedora users and some Fedoraproject
developers want to see as well. That's why I think it would be good if
the the Fedora project might help/guide in that are, even if the
resulting repo and the main work is done outside of the Fedora project.

CU
knurd
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Fedora.next in 2014 -- Big Picture and Themes

2014-01-24 Thread Tom Hughes


On 23/01/14 18:48, Josh Boyer wrote:

On Thu, Jan 23, 2014 at 1:38 PM, Tom Hughes t...@compton.nu wrote:


Even the formation of the working groups was odd - the original decision to
form them, as I read it, was that they were to explore the idea of doing
these three streams but within days it seemed that the question was no
longer whether to do them but rather how to do them.


I can see how that would be confusing.  I always understood it to be
these WGs will be formed and they will be tasked with figuring out
how to create their respective products.  Perhaps some lack of
clarity in the proposal?


I've been digging back through the list archives and various other 
sources trying to determine where my view of this was founded, but not 
with a hug amount of success so far. The best I have come up with is 
your report to the list of the board's decision:


https://lists.fedoraproject.org/pipermail/devel/2013-August/187784.html

Where we are told that the board agree with the development of a 
working group to describe an implementation proposal for the future of 
Fedora which sounds like the idea is to make a proposal for how to do 
things in the future, which might then be accepted or rejected.


By the time Fesco is discussing the creation of those groups (for it has 
now become multiple groups) a week or two later the proposal the groups 
are being asked to create is not a proposal as to whether to change but 
rather a proposal for the specific way to do the change.


In other words the question seems to have changed from whether to do 
it to how to do it.


Of course this is all reading a lot into that one initial sentence in 
your email. I think there were probably other things that helped build 
that view in my mind at the time but I can't find them right now.



That's why I got the feeing a lot of contributors are simply waiting
for more concrete details to emerge before deciding what to make of
Fedora.next; or they simply at all don't care to much what the higher
ups do, as getting involved on that level can cost quite a lot of time
and can be frustrating (that's not a complaint, that's simply how it
is often; wasn't much different in my days, but noticed that more when
I wasn't that active an more myself).



If they are waiting, what are they waiting for?  If they don't care,
and they just want to maintain a package or 30 packages, is there
anything that you see in Fedora.next that would prevent them from
doing that?  There will always be varied level of participation, and I
think we need to have a development model that encourages that and
allows for growth.  I don't think Fedora.next gets in the way of that,
but I would love to have other opinions.



To be honest my concerns are more with my user hat on than my contributor
hat - that we will lose the gold standard unified packaging standards and
single source and mechanism for installing packages.


I haven't seen anything from any WG that would suggest a deviation
from RPM packaging guidelines or using separate repositories.  It is a
valid concern and one we need to keep an eye on.


Once again the facts don't entirely seem to chime with my memory... My 
memory was that each WG had been explicitly told that they could propose 
alternative packaging guidelines for their products. In fact a review of 
the original call for WG nominations suggests that only the end and 
stacks group were given that freedom, specifically they were tasked:


  to work on policies and practices for software operating outside
   of Fedora's traditional packaging model

Of course if you see env and stacks as sitting between base and the 
three product groups then that effectively impacts on all the products 
because if they start encouraging alternative packaging and policies 
then the product groups may use that and render it effectively 
impossible to run anything beyond a barebones system using the 
traditional Fedora model.


A lot of the time I will have been reading all of these things coloured 
by knowing that they derive from the original Fedora.next proposal which 
appeared to be all about weakening packing guidelines and making it 
easier to shove stuff in and to encourage use of various upstream 
packaging systems in place of Fedora packaging. So there will have been 
an assumption in my mind that the real agenda all the time is to do that.


Certainly that is still pretty much how I see the env and stacks group 
and that is certainly where my major concerns lie.



The actual spins (or whatever you want to call them) aren't something that
bother me at all, as they are to my mind largely irrelevant for anybody
other than a new user. When I bring a new machine up I just want to get a
base OS on and access to the package repository and what packages are
installed by default doesn't really bother me.


So... Fedora.next is essentially irrelevant to you?  That's OK, it
doesn't have to be relevant to everyone.  And meeting the needs of
existing users is

Re: Fedora.next in 2014 -- Big Picture and Themes

2014-01-24 Thread Björn Persson

Colin Walters wrote:
People have been constantly confused by whether Fedora does DHCP by
default over the years, because we've flipped it several times.  When
we introduced it for clients/workstations, I consider it to have been a
*massive* win to be able to plug in an ethernet cable and have it Just
Work.

Absolutely. That's the whole point of DHCP.

But it's very much the wrong thing to do for traditional servers where
you have 4 or more physical NICs.

I don't see why. Either DHCP is the right thing, or else the admin is
going to configure the NICs immediately and then it doesn't matter what
the default is.

Björn Persson


signature.asc
Description: PGP signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Fedora.next in 2014 -- Big Picture and Themes

2014-01-24 Thread Eric Smith

On Jan 23, 2014 2:33 PM, Kevin Fenzi ke...@scrye.com wrote:

 On Thu, 23 Jan 2014 19:03:02 +0100
 Thorsten Leemhuis fed...@leemhuis.info wrote:
  I'm still undecided if I overall like Fedora.next or fear it. But more
  and more I tend to the latter position and wonder if it might be wise
  to slow things down: Do one more Fedora release the old style in round
  about June; that would give us more time to better discuss and work
  out Fedora.next and get contributors involved better in the planing.

 This is not practical. Lots of people are thinking about a
 fedora.next, qa folks are coding away, lots of people who normally
 would be working on the next release are not. If we tell them to stop
 all that and go back to normal, we could, but then fedora.next will
 likely never ever happen.
[...]
 The current problem I have with Fedora.next is that it's so abstract.

How are QA folks coding away for Fedora.next, rather than traditional
Fedora QA processes, if Fedora.next is so abstract?

I still don't understand what the Fedora.next Products accomplish that
Spins don't/can't.

Eric
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Fedora.next in 2014 -- Big Picture and Themes

2014-01-24 Thread Kevin Fenzi

On Fri, 24 Jan 2014 09:58:07 -0700
Eric Smith space...@gmail.com wrote:

 On Jan 23, 2014 2:33 PM, Kevin Fenzi ke...@scrye.com wrote:

  This is not practical. Lots of people are thinking about a
  fedora.next, qa folks are coding away, lots of people who normally
  would be working on the next release are not. If we tell them to
  stop all that and go back to normal, we could, but then fedora.next
  will likely never ever happen.
 [...]
  The current problem I have with Fedora.next is that it's so
  abstract.
 
 How are QA folks coding away for Fedora.next, rather than
 traditional Fedora QA processes, if Fedora.next is so abstract?

The things they are working on have been known for years, but our 6
month release cycle with no hope of being able to work on tooling
hasn't allowed them to do so. 

So, things like replacing autoqa with taskotron, investigating beaker
and other items are likely to be very helpful in both a fedora.next
and a 'traditional' fedora world. 

I'll stop talking for them, feel free to join them on the qa-devel
list and offer your help. 

kevin


signature.asc
Description: PGP signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Fedora.next in 2014 -- Big Picture and Themes

2014-01-24 Thread Eric Smith

On Jan 24, 2014 10:29 AM, Kevin Fenzi ke...@scrye.com wrote:
 The things they are working on have been known for years, but our 6
 month release cycle with no hope of being able to work on tooling
 hasn't allowed them to do so.

Thanks for the clarification. I'm certainly on board with lengthening a
release cycle to give them opportunity to improve the QA infrastructure,
irrespective of Fedora.next.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Fedora.next in 2014 -- Big Picture and Themes

2014-01-24 Thread Stephen Gallagher

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 01/23/2014 06:13 PM, Matthew Miller wrote:
 On Thu, Jan 23, 2014 at 02:16:23PM -0800, Adam Williamson wrote:
 Read all the above sequentially. My point is that although you
 are technically correct that no WG has proposed doing away with
 the repos, the RPM format, or yum/dnf, their plans - under a
 reasonable interpretation of the discussions so far - still
 invalidate the assumptions he is currently making: he can no
 longer assume that all he basically has to worry about is getting
 'Fedora' installed somehow and he can then install whatever he
 likes. Broadly stated, it will no longer be valid to conceive of
 Fedora as a large package repository with some installation
 methods attached to it, whereas currently that's a pretty 
 reasonable conceptual framework that I believe many people (not
 just Tom) employ.
 
 In other words, Tom was really correct. ;)
 
 Well, maybe. It really is the case that nothing is finalized and
 it's a legitimate concern. This is why we (and here I'm using we
 not in the royal sense but because it really wasn't just _me_) have
 the Base Design, not just three separate product working groups. I
 share the trepidation about adding more bureaucracy, but also seems
 pretty important to keep a coherent shared base.
 
 It's possible that eventually it'll be kind of hard to go from
 Fedora Workstation to Fedora Cloud, or from Fedora Cloud to Fedora
 Workstation -- but that's not _really_ so different from how it is
 now, where if you start from one of those and try to go to the
 other, you're going to have to tear down a bunch of things first.
 On the other hand, the Cloud WG made the ability to go from Fedora
 Cloud to Fedora Server an explicit goal.
 
 Either way, I think it's pretty likely that someone who wants to
 start with the base and build up will be able to with, with varying
 possible degrees of difficulty. It may also end up that it's easier
 to make and share specific, lightweight remixes, so that while you
 don't necessarily build up in an install, you do it in a tool of
 some sort -- that was part of Stephen Gallagher's original
 products idea, if I'm remembering right.
 

That was originally one of my moonshot ideas, yeah. I've subsequently
toned down on trying to push for that as I've been told from several
directions that this would put a significant strain on
release-engineering. I think it's still worth looking into way to
improve our existing tooling (and make spin-generation not suck so
that we could make it easier for spins to evolve to products), but
I've stopped trying to trumpet it as a primary objective.


 So yes, there may very well be different options.  That doesn't
 mean they can't also be the same if you choose not to use those
 different things.
 Is that going to be a reasonably sustainable approach, though?
 It's at least possible that it won't. What if the Desktop
 'product' starts caring much about shipping commonly-used desktop
 applications as 'app bundles' rather than packages? What if the
 Server 'product' implements Wordpress as a container image rather
 than a package?
 
 That might happen, although I would be shocked if anyone has
 anything near workable for F21 timeframe. Or F22. But, would it be
 so bad? People who are interested in packaging it in the
 traditional way still could... or, at least _I_ hope so -- that's
 been part of my version of the proposal since the beginning.
 

For what it's worth, I still want (personally) for us to be deploying
using RPM for its other abilities (like maintaining a useful inventory
of software on the system). However, I'm not ruling out the
possibility that we might be willing to start shipping RPMs inside the
Fedora Repositories that contain inside them essentially a docker or
qcow image that we then deploy into an isolated environment to
actually implement the Role functionality.

Yes, this would be a big divergence from our current guidelines and
would need serious discussion on feasibility. No, I'm not asserting
this is the right way to do things, merely one possible approach to
consider.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iEYEARECAAYFAlLitJAACgkQeiVVYja6o6ONLQCgneb9p7asfW8t7Nc1nO4eYhyP
xlsAniHrICryRNJ4A/2NXP62BD8/eJaG
=3S7P
-END PGP SIGNATURE-
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Fedora.next in 2014 -- Big Picture and Themes

2014-01-24 Thread Stephen Gallagher

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 01/23/2014 06:12 PM, Lars Seipel wrote:
 On Thu, Jan 23, 2014 at 05:07:16PM -0500, Josh Boyer wrote:
 Also possibly correct.  However, that doesn't preclude the repos
 as we know them today from still existing, with still the same
 quality.
 
 Server, desktop or embedded board, in today's Fedora it's all the
 same, just with a different package set installed. People (not all,
 obviously) consider this a good thing. I just have to put a minimal
 Fedora install on some machine and then build it from there.
 
 That's what Tom was getting at, I think. The discussions in the WGs
 so far have hinted that it's not necessarily a reasonable
 expectation that this will continue to be the case. An oft-cited
 reason was that RPMs apparently can't provide the 'integration'
 that is somehow wanted.
 
 I always considered it nice that there's only a single Fedora. I
 thought that split products were mostly an artefact of commercial 
 differentiation and so Fedora users don't have to deal with you
 can't use this filesystem unless you have the Ultra Enterprise
 Storage Edition or stuff like that. ☺
 


I agree with you. My stated (and oft-repeated) position in the Server
WG is that the available package sets should not diverge between the
Products so far as is feasible.

What I'd like to see is mainly that we allow a limited set of
intentionally-conflicting packages in the repository that allow us to
provide different default configurations for the products. So for any
package that has a configuration that might want different defaults
for Server vs. Workstation, we would have it produce two sub-packages,
one for each sensible default.

To take the DHCP example elsewhere in the thread, we could have:
dhcp-config-default-on
  Provides: dhcp-config
  Conflicts: dhcp-config-default-off

dhcp-config-default-off
  Provides: dhcp-config
  Conflicts: dhcp-config-default-on


The dhcp package would Requires: dhcp-config (and therefore not care
which one it gets). Then we would have a release package for Fedora
Server and Fedora workstation that would specifically Requires: the
appropriate one (so that when yum/dnf resolution occurs, the right one
gets selected).

e.g.
fedora-release-server-21
  Requires: dhcp-config-default-off

fedora-release-workstation-21
  Requires: dhcp-config-default-on



On a related note, I'd also strongly like to recommend that we start
using the fedora-release-*-VERSION packages as meta-packages that
contain strict Requires: defining a minimum set of packages necessary
to qualify as Fedora Server, Fedora Cloud or Fedora Workstation.

So for example in the Fedora Server, this might be the minimum set of
packages necessary to have a system with SSHD and the infrastructure
to deploy Fedora Server Roles. On Fedora Workstation, perhaps it
defines the set of packages conforming to GnomeOS 3.14.

The idea would be that you'd still have the option to reduce the set
of packages on the system, but at that point you would be voluntarily
exiting the set of tested functionality. (And this would be checkable
with a simple 'rpm -q' call)
-BEGIN PGP SIGNATURE-
Version: GnuPG v1
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iEYEARECAAYFAlLit/0ACgkQeiVVYja6o6ONGgCghQXjNgPDx7y0s482LpSSTBHz
vrYAn3YjuqAlh+jwi+08OqYsZL/k0B2G
=6pJp
-END PGP SIGNATURE-
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Fedora.next in 2014 -- Big Picture and Themes

2014-01-24 Thread Tim Flink

On Fri, 24 Jan 2014 09:58:07 -0700
Eric Smith space...@gmail.com wrote:

 On Jan 23, 2014 2:33 PM, Kevin Fenzi ke...@scrye.com wrote:
 
  On Thu, 23 Jan 2014 19:03:02 +0100
  Thorsten Leemhuis fed...@leemhuis.info wrote:
   I'm still undecided if I overall like Fedora.next or fear it. But
   more and more I tend to the latter position and wonder if it
   might be wise to slow things down: Do one more Fedora release the
   old style in round about June; that would give us more time to
   better discuss and work out Fedora.next and get contributors
   involved better in the planing.
 
  This is not practical. Lots of people are thinking about a
  fedora.next, qa folks are coding away, lots of people who normally
  would be working on the next release are not. If we tell them to
  stop all that and go back to normal, we could, but then fedora.next
  will likely never ever happen.
 [...]
  The current problem I have with Fedora.next is that it's so
  abstract.
 
 How are QA folks coding away for Fedora.next, rather than
 traditional Fedora QA processes, if Fedora.next is so abstract?

Kevin covered most of it, but the short answer is that we have so much
stuff in our backlog of qa tools and technical debt to pay off right
now that the details of fedora.next aren't required to make progress.

The primary focus for now is replacing autoqa with taskotron. There are
a lot of moving parts in a decent, generic automation system and the
base for those parts need to be replaced at the same time or not at
all. Regardless of what happens with Fedora.next, there is a real need
for better automation support to start running more checks on packages
and other output and the delay between f20 and f21 will give us the
time we need to at least get the basics in place.

As a concrete example, a package-level check was recently proposed to
help detect scriptlet errors like the one that caused the SELinux issue
with F20. That type of check is just not possible to run sanely in
autoqa due to its host-destructive nature. While destructive checks
aren't in scope for the initial deployment of taskotron, it is a
feature that we're planning on.

I believe that releng is in a similar position - lots of improvements
on the wishlist but the regular release cadence prevents work on
anything substantial. However, I can't speak to what their specific
plans are for the delay between f20 and f21.

Tim


signature.asc
Description: PGP signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Fedora.next in 2014 -- Big Picture and Themes

2014-01-24 Thread Adam Williamson

On Fri, 2014-01-24 at 09:58 -0700, Eric Smith wrote:
 On Jan 23, 2014 2:33 PM, Kevin Fenzi ke...@scrye.com wrote:
 
  On Thu, 23 Jan 2014 19:03:02 +0100
  Thorsten Leemhuis fed...@leemhuis.info wrote:
   I'm still undecided if I overall like Fedora.next or fear it. But
 more
   and more I tend to the latter position and wonder if it might be
 wise
   to slow things down: Do one more Fedora release the old style in
 round
   about June; that would give us more time to better discuss and
 work
   out Fedora.next and get contributors involved better in the
 planing.
 
  This is not practical. Lots of people are thinking about a
  fedora.next, qa folks are coding away, lots of people who normally
  would be working on the next release are not. If we tell them to
 stop
  all that and go back to normal, we could, but then fedora.next will
  likely never ever happen.
 [...]
  The current problem I have with Fedora.next is that it's so
 abstract.
 
 How are QA folks coding away for Fedora.next, rather than
 traditional Fedora QA processes, if Fedora.next is so abstract?

We're not really coding *for* Fedora.next, we're coding the new autoqa
system (taskotron) which we need whether Fedora.next happens or not (I'm
not suggesting seriously that it won't, I'm just making the point that
taskotron is not at all dependent on .next). Where .next comes into it
is that the longer cycle for F21 is kind of tied into the .next stuff,
and in turn, the longer cycle is what's affording QA's tools folks the
space and time to get taskotron into working order - our assessment was
that we could get taskotron ready for F21 on the delayed schedule, but
not on the 'regular' schedule.

I believe some of the ideas encompassed by .next more or less assume the
existence of a mature automated testing framework and certain tests
within that framework, so .next may consider itself dependent on
taskotron, but the dependency doesn't run the other way: we were working
on taskotron before .next became a Thing at all, and we'd still be
working on it if .next wasn't a Thing.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Fedora.next in 2014 -- Big Picture and Themes

2014-01-23 Thread Thorsten Leemhuis

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Hi!

On 03.01.2014 19:14, Matthew Miller wrote:
 […] So those are my things. What do you think about them? What
 else should be included? What different directions should we
 consider? How will we make Fedora more awesome than ever in the
 coming year?

Okay, I'll bite (after thinking whether writing this mail is worth it):

I'm still undecided if I overall like Fedora.next or fear it. But more
and more I tend to the latter position and wonder if it might be wise
to slow things down: Do one more Fedora release the old style in round
about June; that would give us more time to better discuss and work
out Fedora.next and get contributors involved better in the planing.

The main reason for that: Fedora.next is a huge effort that seems to
make everything even more complicated. It imho is also sold pretty
badly right now, as you have to invest quite a lot of time to
understand what Fedora.next actually is. And Fedora.next to me seems
like something the core contributors push forward without having
really abort those Fedora contributors who don't have Fedora as one of
their top priorities in life.


Verbose: Yes, I really think the Fedora needs changes -- at some point
a few years ago we mostly continued to do things as they have always
 been done (read: since Core and Extras merged), without thinking if
those ways are still the best.

So I welcomed Fedora.next in the beginning. But I, as someone that is
not involved very much in Fedora any more, still fail to fully grasp
it. Yes, there are many mailing list or blog posts and some docs in
the wiki. But most of them are really way too long for people that
have busy days; a lot of those docs are also quite meta,
nevertheless afaics failing to give a goal. Take
https://fedoraproject.org/wiki/Fedora.next for example. It more a
description of a vague idea without saying much concrete besides
design, build, and market three distinct Fedora products (what is a
Fedora product?). There are a few links there, but even
https://fedoraproject.org/wiki/Fedora.next/boardproposal is still
quite meta for something which is supposed to be the base for a
release that is eight months or so away. It doesn't explain what
problems are being solved or what happens to spins (KDE and such) or
how often (according to current plans) Fedora will be released in the
future.

What really gives me the creeps on those pages: sub-committees of
FESCo, with individual governance structures. Those afaics are three
Product Working Groups Workgroups, two Fedora Rings Working Groups and
the Inter-WG for coordination. That sounds like a awful lot of
overhead an even more bureaucracy than we already have. And we imho
have way to much already (part of it is my fault!) – something I had
hoped Fedora.next would try to fix.

I these days wouldn't start contributing to Fedora, as all those rules
and guidelines that the wiki provides would scare me off. That's what
Fedora.next should fix imo, as we afaics need more contributors: I
more often than a few years ago find packages in Fedora that are badly
maintained or outdated. Contributing must be as easy as editing a
wikipedia page. Further: kororaproject.org, fedorautils-installer and
similar project show that there are people that want to make Fedora
better. But they do their work outside of Fedora and RPM Fusion;
fixing the issues directly at the root would be better for all of us.

And I really wonder if Fedora.next is really backed by those community
contributors that are not involved in Fedora to deeply. One reason for
that: Fedora.next mails like the one I'm replying to seem to get very
few responses -- especially considering the fact that Fedora.next is
something really important and brought to a list where small details
quite often spawn very long discussions. Sometimes it's different --
like the ongoing and long 3rd party and non-free software
discussion. That shows that a lot of people still care, but don't
bother follow to closely what the workgroups discuss before it someone
gets to a point where it's more visible.

That's why I got the feeing a lot of contributors are simply waiting
for more concrete details to emerge before deciding what to make of
Fedora.next; or they simply at all don't care to much what the higher
ups do, as getting involved on that level can cost quite a lot of time
and can be frustrating (that's not a complaint, that's simply how it
is often; wasn't much different in my days, but noticed that more when
I wasn't that active an more myself).

I have many more thoughts in my head, but I'll stop here, as those are
basically the most important things that bother me right now when
looking at Fedora and Fedora.next.

CU
knurd

P.S.: Fixed subject (s/2013/2014/)
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBCgAGBQJS4VlWAAoJEHK25u9MWD0tjR0QAJAe7Z35vN90Moq1mXGRpiMJ

Re: Fedora.next in 2014 -- Big Picture and Themes

On Thu, Jan 23, 2014 at 1:03 PM, Thorsten Leemhuis fed...@leemhuis.info wrote:
 Verbose: Yes, I really think the Fedora needs changes -- at some point
 a few years ago we mostly continued to do things as they have always
  been done (read: since Core and Extras merged), without thinking if
 those ways are still the best.

 So I welcomed Fedora.next in the beginning. But I, as someone that is
 not involved very much in Fedora any more, still fail to fully grasp
 it. Yes, there are many mailing list or blog posts and some docs in
 the wiki. But most of them are really way too long for people that
 have busy days; a lot of those docs are also quite meta,
 nevertheless afaics failing to give a goal. Take
 https://fedoraproject.org/wiki/Fedora.next for example. It more a
 description of a vague idea without saying much concrete besides
 design, build, and market three distinct Fedora products (what is a
 Fedora product?). There are a few links there, but even
 https://fedoraproject.org/wiki/Fedora.next/boardproposal is still
 quite meta for something which is supposed to be the base for a
 release that is eight months or so away. It doesn't explain what
 problems are being solved or what happens to spins (KDE and such) or
 how often (according to current plans) Fedora will be released in the
 future.

You make a fair point.  There are many unanswered questions around
Fedora.next (like spins?).  Asking those questions or pointing out
inconsistencies does help though :).

 What really gives me the creeps on those pages: sub-committees of
 FESCo, with individual governance structures. Those afaics are three
 Product Working Groups Workgroups, two Fedora Rings Working Groups and
 the Inter-WG for coordination. That sounds like a awful lot of
 overhead an even more bureaucracy than we already have. And we imho
 have way to much already (part of it is my fault!) – something I had
 hoped Fedora.next would try to fix.

It is more overhead to a degree.  On the other hand, the idea is to
enable people that are interested in specific areas to go forth and
create a Fedora deliverable that they think meets the needs of those
areas best, without having to pass everything through FESCo.  FESCo
just doesn't scale like that.

 I these days wouldn't start contributing to Fedora, as all those rules
 and guidelines that the wiki provides would scare me off. That's what
 Fedora.next should fix imo, as we afaics need more contributors: I
 more often than a few years ago find packages in Fedora that are badly
 maintained or outdated. Contributing must be as easy as editing a

The packaging guidelines are very daunting.  Automating as much of
that as possible, either through spec creation tooling or package
review tooling would help.

 wikipedia page. Further: kororaproject.org, fedorautils-installer and
 similar project show that there are people that want to make Fedora
 better. But they do their work outside of Fedora and RPM Fusion;
 fixing the issues directly at the root would be better for all of us.

Small note:  The two projects you use as an example are required to do
what they're doing (in part) outside of Fedora for legal reasons.  I
don't believe Fedora.next will change how US law works, so it might
not be the best of examples.

(And we have a Board meeting to discuss related things that are not
legally prohibited.)

 And I really wonder if Fedora.next is really backed by those community
 contributors that are not involved in Fedora to deeply. One reason for

I wonder the same.  However, I don't think it's because we haven't
necessarily asked in all of the usual places, or haven't tried to
reach as many people as possible.  There has been very little response
from anyone and I can't tell if it's from indifference or from a lack
of them even being aware.  It's really hard to tell.

 that: Fedora.next mails like the one I'm replying to seem to get very
 few responses -- especially considering the fact that Fedora.next is
 something really important and brought to a list where small details
 quite often spawn very long discussions. Sometimes it's different --
 like the ongoing and long 3rd party and non-free software
 discussion. That shows that a lot of people still care, but don't
 bother follow to closely what the workgroups discuss before it someone
 gets to a point where it's more visible.

Yes, that thread shows a lot of people caring.  However, those people
are still people that I consider core contributors.

 That's why I got the feeing a lot of contributors are simply waiting
 for more concrete details to emerge before deciding what to make of
 Fedora.next; or they simply at all don't care to much what the higher
 ups do, as getting involved on that level can cost quite a lot of time
 and can be frustrating (that's not a complaint, that's simply how it
 is often; wasn't much different in my days, but noticed that more when
 I wasn't that active an more myself).

If they are waiting, what are they waiting for?  If

Re: Fedora.next in 2014 -- Big Picture and Themes

2014-01-23 Thread Tom Hughes


On 23/01/14 18:26, Josh Boyer wrote:

On Thu, Jan 23, 2014 at 1:03 PM, Thorsten Leemhuis fed...@leemhuis.info wrote:


And I really wonder if Fedora.next is really backed by those community
contributors that are not involved in Fedora to deeply. One reason for


I wonder the same.  However, I don't think it's because we haven't
necessarily asked in all of the usual places, or haven't tried to
reach as many people as possible.  There has been very little response
from anyone and I can't tell if it's from indifference or from a lack
of them even being aware.  It's really hard to tell.


Personally I think a lot of it has to do with the way the whole thing 
seemed to be a fait accompli such that there seemed to be little point 
doing anything other than sitting back and seeing what happened.


You know, the way one minute it was just a suggestion from one member of 
the community and the next minute it was all decided and people were 
busy forming working groups to sort out the details. Apparently that 
miraculous transition happened at Flock, but for anybody that wasn't 
there it was as if it was a god given edict that had been handed down on 
tablets of stone that Fedora.next was happening and we should all just 
be good little children and get on with it.


Even the formation of the working groups was odd - the original decision 
to form them, as I read it, was that they were to explore the idea of 
doing these three streams but within days it seemed that the question 
was no longer whether to do them but rather how to do them.



That's why I got the feeing a lot of contributors are simply waiting
for more concrete details to emerge before deciding what to make of
Fedora.next; or they simply at all don't care to much what the higher
ups do, as getting involved on that level can cost quite a lot of time
and can be frustrating (that's not a complaint, that's simply how it
is often; wasn't much different in my days, but noticed that more when
I wasn't that active an more myself).


If they are waiting, what are they waiting for?  If they don't care,
and they just want to maintain a package or 30 packages, is there
anything that you see in Fedora.next that would prevent them from
doing that?  There will always be varied level of participation, and I
think we need to have a development model that encourages that and
allows for growth.  I don't think Fedora.next gets in the way of that,
but I would love to have other opinions.


To be honest my concerns are more with my user hat on than my 
contributor hat - that we will lose the gold standard unified packaging 
standards and single source and mechanism for installing packages.


The actual spins (or whatever you want to call them) aren't something 
that bother me at all, as they are to my mind largely irrelevant for 
anybody other than a new user. When I bring a new machine up I just want 
to get a base OS on and access to the package repository and what 
packages are installed by default doesn't really bother me.


Tom

--
Tom Hughes (t...@compton.nu)
http://compton.nu/
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Fedora.next in 2014 -- Big Picture and Themes

2014-01-23 Thread Matthew Miller

On Thu, Jan 23, 2014 at 07:03:02PM +0100, Thorsten Leemhuis wrote:
 Okay, I'll bite (after thinking whether writing this mail is worth it):

Thanks. I hope that I can make you feel that it was.

 The main reason for that: Fedora.next is a huge effort that seems to
 make everything even more complicated. It imho is also sold pretty
 badly right now, as you have to invest quite a lot of time to
 understand what Fedora.next actually is. And Fedora.next to me seems
 like something the core contributors push forward without having
 really abort those Fedora contributors who don't have Fedora as one of
 their top priorities in life.

I've been in both of those positions over the years, and I certainly don't
want to leave out the more-casual contributor (or, highly committed
contributors who are just really busy right now). I understand your feeling
that it hasn't been documented in a way that's as helpful as could be -- I'm
trying to increase what I'm doing there, and could certainly use more help
from others who are good at explaining and visualizing things.

I will be giving a talk on Sunday, February 9th in at DevConf in Brno, CZ,
and I'll post slides from that (probably here as text as well), and I assume
there will be video. 

For many things, there hasn't been a whole lot to say because it's been in
planning -- the product descriptions are not completely approved yet even,
and we haven't started collectively talking about the big changes. (And we
will!)

 I these days wouldn't start contributing to Fedora, as all those rules
 and guidelines that the wiki provides would scare me off. That's what
 Fedora.next should fix imo, as we afaics need more contributors: I
 more often than a few years ago find packages in Fedora that are badly
 maintained or outdated. Contributing must be as easy as editing a
 wikipedia page. Further: kororaproject.org, fedorautils-installer and
 similar project show that there are people that want to make Fedora
 better. But they do their work outside of Fedora and RPM Fusion;
 fixing the issues directly at the root would be better for all of us.

I don't disagree with this, but I don't think they're directly related.
Because we started with the governance and somewhat formal product
descriptions, those are the primary visible artifacts. As we start working
with the website, documentation, and design teams, more naturally-accessible
starting points will take over in prominence.

 And I really wonder if Fedora.next is really backed by those community
 contributors that are not involved in Fedora to deeply. One reason for
 that: Fedora.next mails like the one I'm replying to seem to get very
 few responses -- especially considering the fact that Fedora.next is
[...]
 That's why I got the feeing a lot of contributors are simply waiting
 for more concrete details to emerge before deciding what to make of
 Fedora.next; or they simply at all don't care to much what the higher
 ups do, as getting involved on that level can cost quite a lot of time
 and can be frustrating (that's not a complaint, that's simply how it
 is often; wasn't much different in my days, but noticed that more when
 I wasn't that active an more myself).

I think that'll naturally solve itself as we get more concrete. But also,
just looking anecdotally at the Cloud SIG, this process has helped draw in
community contribution where we didn't have so much before. It gives a
framework to plug in, and as more details are worked out, I expect that to
snowball. So, I guess I kind of disagree with the basic premise.

But also, I want to go back to the first part of my message that you're
responding to. I don't think our current online communication structure
really works very well for the kind of contributor you're concerned about.
(Let alone working very well for more active contributors who still don't
have time to read every list or hang out on IRC 24/7.) I think we need to
fix that, whether we consider that part of Fedora.next or a separate big
initiative.

 I have many more thoughts in my head, but I'll stop here, as those are
 basically the most important things that bother me right now when
 looking at Fedora and Fedora.next.

I appreciate it. Does anything I've said help you feel better about it? I
know I glossed over the put it off for another release part. :) And what
we do with spins is still up in the air -- I have a suggestion which
parallels the primary arch / secondary arch mechanism (although probably
less strictly), and I need to finish fleshing that out for FESCo -- it will
be on a meeting agenda after FOSDEM/DevConf.

I would like to hear more of your thoughts, too.

 P.S.: Fixed subject (s/2013/2014/)

:) Thanks.

-- 
Matthew Miller--   Fedora Project--mat...@fedoraproject.org
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Fedora.next in 2014 -- Big Picture and Themes

2014-01-23 Thread Stephen John Smoogen

On 23 January 2014 11:48, Josh Boyer jwbo...@fedoraproject.org wrote:

 On Thu, Jan 23, 2014 at 1:38 PM, Tom Hughes t...@compton.nu wrote:

  Personally I think a lot of it has to do with the way the whole thing
 seemed
  to be a fait accompli such that there seemed to be little point doing
  anything other than sitting back and seeing what happened.
 
  You know, the way one minute it was just a suggestion from one member of
 the
  community and the next minute it was all decided and people were busy
  forming working groups to sort out the details. Apparently that
 miraculous
  transition happened at Flock, but for anybody that wasn't there it was
 as if
  it was a god given edict that had been handed down on tablets of stone
 that
  Fedora.next was happening and we should all just be good little children
 and
  get on with it.

 There _was_ a lot that was discussed and presented at Flock.  It's
 kind of the purpose of Flock (and FUDCon before that).  Get people
 together to have big discussions in a high bandwith fashion.  And yes,
 that can mean that those not in attendance are left to catch up a bit
 (though at least with Flock we tried to stream all the sessions to
 help with that).

 However, it wasn't decided at Flock.  It was presented after Flock to
 FESCo, in the normal, online FESCo meetings.  It went further from
 there to the Board via the usual channels.  All of this was done as
 any other proposal would normally be handled.  Perhaps the only
 unusual thing was the relative lack of debate and delay.


My view of the matter was pretty much the same as Tom's and I was at FLOCK.
The language at the sessions I attended was not one of We would like to do
this but that it was a done thing. I realize a lot of that is the 'get
shit done because we are all together' mentality which comes from
conferences but by the time I left FLOCK I was pretty sure this was all
done and either get in the boat or get out. I wasn't even aware of the
FESCO items until this email as I figured it had been done and decided at
FLOCK.

Fedora.NEXT became irrelevant to me when I realized the committees were
mostly hand-chosen versus elected like FESCO. I realize that was to get
stuff done versus having a bunch of bureaucratci elections, but it snuffed
whatever 'joy' I was going to have to participate in as a 'non-voting'
member of a committee. The best way for me to allow the people to get work
they wanted to get done was to get out of the way, and so I have. Now that
I am asked why I am not enthused, I am explaining.



-- 
Stephen J Smoogen.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Fedora.next in 2014 -- Big Picture and Themes

On Thu, Jan 23, 2014 at 3:53 PM, Stephen John Smoogen smo...@gmail.com wrote:



 On 23 January 2014 11:48, Josh Boyer jwbo...@fedoraproject.org wrote:

 On Thu, Jan 23, 2014 at 1:38 PM, Tom Hughes t...@compton.nu wrote:

  Personally I think a lot of it has to do with the way the whole thing
  seemed
  to be a fait accompli such that there seemed to be little point doing
  anything other than sitting back and seeing what happened.
 
  You know, the way one minute it was just a suggestion from one member of
  the
  community and the next minute it was all decided and people were busy
  forming working groups to sort out the details. Apparently that
  miraculous
  transition happened at Flock, but for anybody that wasn't there it was
  as if
  it was a god given edict that had been handed down on tablets of stone
  that
  Fedora.next was happening and we should all just be good little children
  and
  get on with it.

 There _was_ a lot that was discussed and presented at Flock.  It's
 kind of the purpose of Flock (and FUDCon before that).  Get people
 together to have big discussions in a high bandwith fashion.  And yes,
 that can mean that those not in attendance are left to catch up a bit
 (though at least with Flock we tried to stream all the sessions to
 help with that).

 However, it wasn't decided at Flock.  It was presented after Flock to
 FESCo, in the normal, online FESCo meetings.  It went further from
 there to the Board via the usual channels.  All of this was done as
 any other proposal would normally be handled.  Perhaps the only
 unusual thing was the relative lack of debate and delay.


 My view of the matter was pretty much the same as Tom's and I was at FLOCK.
 The language at the sessions I attended was not one of We would like to do
 this but that it was a done thing. I realize a lot of that is the 'get shit
 done because we are all together' mentality which comes from conferences but
 by the time I left FLOCK I was pretty sure this was all done and either get
 in the boat or get out. I wasn't even aware of the FESCO items until this
 email as I figured it had been done and decided at FLOCK.

If one is advocating for something they strongly believe in, they
definitely are not going to say I think maybe we should do this kinda
but it might be a crazy idea.  They advocate by saying I am going to
do this and I am going to drive it forward until I am told no.  That
doesn't mean they can just skip all the processes and steps required
to get their idea approved.

So yes, I think for this specific item it was the get stuff done
mentality that might have been misleading.  The ideas were still
carried forward per process though.

 Fedora.NEXT became irrelevant to me when I realized the committees were
 mostly hand-chosen versus elected like FESCO. I realize that was to get
 stuff done versus having a bunch of bureaucratci elections, but it snuffed
 whatever 'joy' I was going to have to participate in as a 'non-voting'
 member of a committee. The best way for me to allow the people to get work
 they wanted to get done was to get out of the way, and so I have. Now that I
 am asked why I am not enthused, I am explaining.

Boostrapping is hard.  I didn't come up with the idea and this might
not have been the best way to do it, but hindsight is 20/20.  I do
hope that if you are interested in a WG/Product that you do
participate because the governance for them is set up and will allow
different WG members going forward.  I've also seen lots of non-member
participation be really fruitful already.

josh
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Fedora.next in 2014 -- Big Picture and Themes

2014-01-23 Thread drago01

On Thu, Jan 23, 2014 at 7:03 PM, Thorsten Leemhuis fed...@leemhuis.info wrote:
 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA512

 Hi!

 On 03.01.2014 19:14, Matthew Miller wrote:
 […] So those are my things. What do you think about them? What
 else should be included? What different directions should we
 consider? How will we make Fedora more awesome than ever in the
 coming year?

 Okay, I'll bite (after thinking whether writing this mail is worth it):

 I'm still undecided if I overall like Fedora.next or fear it. But more
 and more I tend to the latter position and wonder if it might be wise
 to slow things down: Do one more Fedora release the old style in round
 about June; that would give us more time to better discuss and work
 out Fedora.next and get contributors involved better in the planing.

Actually this makes sense we are currently do not even have a schedule
because to many stuff is just undefined.
Maybe this should be a formal proposal for FESCo to consider.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Fedora.next in 2014 -- Big Picture and Themes

2014-01-23 Thread Kevin Fenzi

On Thu, 23 Jan 2014 19:03:02 +0100
Thorsten Leemhuis fed...@leemhuis.info wrote:

 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA512
 
 Hi!
 
 On 03.01.2014 19:14, Matthew Miller wrote:
  […] So those are my things. What do you think about them? What
  else should be included? What different directions should we
  consider? How will we make Fedora more awesome than ever in the
  coming year?
 
 Okay, I'll bite (after thinking whether writing this mail is worth
 it):

Hey Thorsten! Glad you did. ;) 

 I'm still undecided if I overall like Fedora.next or fear it. But more
 and more I tend to the latter position and wonder if it might be wise
 to slow things down: Do one more Fedora release the old style in round
 about June; that would give us more time to better discuss and work
 out Fedora.next and get contributors involved better in the planing.

This is not practical. Lots of people are thinking about a
fedora.next, qa folks are coding away, lots of people who normally
would be working on the next release are not. If we tell them to stop
all that and go back to normal, we could, but then fedora.next will
likely never ever happen. 
 
 The main reason for that: Fedora.next is a huge effort that seems to
 make everything even more complicated. It imho is also sold pretty
 badly right now, as you have to invest quite a lot of time to
 understand what Fedora.next actually is. And Fedora.next to me seems
 like something the core contributors push forward without having
 really abort those Fedora contributors who don't have Fedora as one of
 their top priorities in life.
...snip...

So, I'll share my thoughts on it here, seems like a good place. :) 

The current problem I have with Fedora.next is that it's so abstract. I
understand that people who like PRD's and TPS want high level
descriptions of what we want to do with goals and visions and such, and
thats great. However, I'm a technical person. I like concrete plans and
pushing what we can do with the technology we have at hand, or helping
to make new technology to do what we want. 

We are now down to the point where groups have written up their PRD
documents, and can get down to details. So, I am hopeful in the next
month or so we will gain a lot more interest in fedora.next and more
feedback as concrete deliverables are discussed, etc.

That is my hope at least... we will see. :) 

kevin


signature.asc
Description: PGP signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Fedora.next in 2014 -- Big Picture and Themes

On Thu, 2014-01-23 at 19:03 +0100, Thorsten Leemhuis wrote:
 Hi!
 
 On 03.01.2014 19:14, Matthew Miller wrote:
  […] So those are my things. What do you think about them? What
  else should be included? What different directions should we
  consider? How will we make Fedora more awesome than ever in the
  coming year?
 
 Okay, I'll bite (after thinking whether writing this mail is worth it):
 
 I'm still undecided if I overall like Fedora.next or fear it. But more
 and more I tend to the latter position and wonder if it might be wise
 to slow things down: Do one more Fedora release the old style in round
 about June;

NO NO NO NO NO NO OH CHRIST NO.

Actually, I agree with quite a lot of what you're saying; I think 21 is
too early for this .next stuff and have done for a while. But that
doesn't mean that if we punt .next we can release in June. Several teams
have been working on the explicit understanding - as agreed by FESCo at
an earlier meeting - that F21 will not be released until, at the
earliest, late August *no matter what happens*. We cannot change that to
June now. It would cause extreme inconvenience for QA and other teams,
which in turn would result in a bad release.

I'm fine with punting on .next, but I am absolutely not fine with
releasing in June. Even if F21 is an old-school release, it needs to be
in late August or later, as has already explicitly been stated.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Fedora.next in 2014 -- Big Picture and Themes

On Thu, 2014-01-23 at 19:03 +0100, Thorsten Leemhuis wrote:

 wikipedia page. Further: kororaproject.org, fedorautils-installer and
 similar project show that there are people that want to make Fedora
 better. But they do their work outside of Fedora and RPM Fusion;
 fixing the issues directly at the root would be better for all of us.

Those particular examples are very bad examples because they are doing
things Fedora explicitly chooses not to do, for *philosophical* not
*practical* reasons (a choice the Board has re-affirmed this morning).
Korora is hardly a 'Fedora is doing silly stuff, let's fork it' project
- as per this statement on their site:

Ultimately, we want people just like you to become useful members of
the Fedora community and we hope that trying Korora will be a catalyst
for this.

And the lead Korora dev is an active Fedora contributor.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Fedora.next in 2014 -- Big Picture and Themes

On Thu, 2014-01-23 at 13:48 -0500, Josh Boyer wrote:

  To be honest my concerns are more with my user hat on than my contributor
  hat - that we will lose the gold standard unified packaging standards and
  single source and mechanism for installing packages.
 
 I haven't seen anything from any WG that would suggest a deviation
 from RPM packaging guidelines or using separate repositories.  It is a
 valid concern and one we need to keep an eye on.

Um. As I read it, three out of four WGs - desktop, server, and cloud -
have at least discussed the possibility of implementing what are, in
essence, secondary package management layers. The details differ - 'app
bundles' for desktop, 'containers' or whatever for server and cloud -
but the effect is the same.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Fedora.next in 2014 -- Big Picture and Themes

On Thu, Jan 23, 2014 at 4:49 PM, Adam Williamson awill...@redhat.com wrote:
 On Thu, 2014-01-23 at 13:48 -0500, Josh Boyer wrote:

  To be honest my concerns are more with my user hat on than my contributor
  hat - that we will lose the gold standard unified packaging standards and
  single source and mechanism for installing packages.

 I haven't seen anything from any WG that would suggest a deviation
 from RPM packaging guidelines or using separate repositories.  It is a
 valid concern and one we need to keep an eye on.

 Um. As I read it, three out of four WGs - desktop, server, and cloud -
 have at least discussed the possibility of implementing what are, in
 essence, secondary package management layers. The details differ - 'app
 bundles' for desktop, 'containers' or whatever for server and cloud -
 but the effect is the same.

Secondary being the key word.  None of them are proposing alternate
RPM repositories or changing the Fedora packaging guidelines.  Tom was
expressing that he is concerned the Fedora repos would go away or be
of decreased quality.  None of the WG proposals are altering those
repos.  They will still exist, much as they do today.

josh
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Fedora.next in 2014 -- Big Picture and Themes

On Thu, 2014-01-23 at 16:54 -0500, Josh Boyer wrote:
 On Thu, Jan 23, 2014 at 4:49 PM, Adam Williamson awill...@redhat.com wrote:
  On Thu, 2014-01-23 at 13:48 -0500, Josh Boyer wrote:
 
   To be honest my concerns are more with my user hat on than my contributor
   hat - that we will lose the gold standard unified packaging standards and
   single source and mechanism for installing packages.
 
  I haven't seen anything from any WG that would suggest a deviation
  from RPM packaging guidelines or using separate repositories.  It is a
  valid concern and one we need to keep an eye on.
 
  Um. As I read it, three out of four WGs - desktop, server, and cloud -
  have at least discussed the possibility of implementing what are, in
  essence, secondary package management layers. The details differ - 'app
  bundles' for desktop, 'containers' or whatever for server and cloud -
  but the effect is the same.
 
 Secondary being the key word.  None of them are proposing alternate
 RPM repositories or changing the Fedora packaging guidelines.  Tom was
 expressing that he is concerned the Fedora repos would go away or be
 of decreased quality.  None of the WG proposals are altering those
 repos.  They will still exist, much as they do today.

The repos will still exist, but things will be different. At present,
the Fedora repos are the single unified official Fedora method for
deploying software on Fedora products. Any other method you can use to
deploy software is not an 'official Fedora' thing.

If these plans go ahead, we will have multiple official/blessed methods
for deploying software on Fedora, potentially with different policies
about what software they can include and how that software should be
arranged, how dependencies should be handled, and all the rest of it.
Some of these methods will be shared between products, and some will
either only exist in certain products, or at least be clearly associated
with and 'owned' by those products.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Fedora.next in 2014 -- Big Picture and Themes

2014-01-23 Thread Kevin Fenzi

On Thu, 23 Jan 2014 13:57:38 -0800
Adam Williamson awill...@redhat.com wrote:

 The repos will still exist, but things will be different. At present,
 the Fedora repos are the single unified official Fedora method for
 deploying software on Fedora products. Any other method you can use to
 deploy software is not an 'official Fedora' thing.
 
 If these plans go ahead, we will have multiple official/blessed
 methods for deploying software on Fedora, potentially with different
 policies about what software they can include and how that software
 should be arranged, how dependencies should be handled, and all the
 rest of it. Some of these methods will be shared between products,
 and some will either only exist in certain products, or at least be
 clearly associated with and 'owned' by those products.

Well, there's no details to see that yet. There's lots of ideas around
those things, but any detailed discussion I have seen has resulted in
thats implementation details, lets keep the PRD high level. 
Or we could use docker or SCLs or just rpms for this with no
proposal.

So, perhaps in the coming month we will actually see concrete proposals
around how to use these methods and can actually discuss them. ;) 

kevin


signature.asc
Description: PGP signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Fedora.next in 2014 -- Big Picture and Themes

2014-01-23 Thread Matthew Miller

On Thu, Jan 23, 2014 at 01:57:38PM -0800, Adam Williamson wrote:
 If these plans go ahead, we will have multiple official/blessed methods
 for deploying software on Fedora, potentially with different policies
 about what software they can include and how that software should be
 arranged, how dependencies should be handled, and all the rest of it.
 Some of these methods will be shared between products, and some will
 either only exist in certain products, or at least be clearly associated
 with and 'owned' by those products.

I think this is possible -- even hopeful -- but I also don't think it's in
the immediate future, because there's nothing in place to make it actually
really work, let alone work well.


-- 
Matthew Miller--   Fedora Project--mat...@fedoraproject.org
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Fedora.next in 2014 -- Big Picture and Themes

On Thu, Jan 23, 2014 at 4:57 PM, Adam Williamson awill...@redhat.com wrote:
 On Thu, 2014-01-23 at 16:54 -0500, Josh Boyer wrote:
 On Thu, Jan 23, 2014 at 4:49 PM, Adam Williamson awill...@redhat.com wrote:
  On Thu, 2014-01-23 at 13:48 -0500, Josh Boyer wrote:
 
   To be honest my concerns are more with my user hat on than my 
   contributor
   hat - that we will lose the gold standard unified packaging standards 
   and
   single source and mechanism for installing packages.
 
  I haven't seen anything from any WG that would suggest a deviation
  from RPM packaging guidelines or using separate repositories.  It is a
  valid concern and one we need to keep an eye on.
 
  Um. As I read it, three out of four WGs - desktop, server, and cloud -
  have at least discussed the possibility of implementing what are, in
  essence, secondary package management layers. The details differ - 'app
  bundles' for desktop, 'containers' or whatever for server and cloud -
  but the effect is the same.

 Secondary being the key word.  None of them are proposing alternate
 RPM repositories or changing the Fedora packaging guidelines.  Tom was
 expressing that he is concerned the Fedora repos would go away or be
 of decreased quality.  None of the WG proposals are altering those
 repos.  They will still exist, much as they do today.

 The repos will still exist, but things will be different. At present,
 the Fedora repos are the single unified official Fedora method for
 deploying software on Fedora products. Any other method you can use to
 deploy software is not an 'official Fedora' thing.

Correct.

 If these plans go ahead, we will have multiple official/blessed methods
 for deploying software on Fedora, potentially with different policies
 about what software they can include and how that software should be
 arranged, how dependencies should be handled, and all the rest of it.
 Some of these methods will be shared between products, and some will
 either only exist in certain products, or at least be clearly associated
 with and 'owned' by those products.

Also possibly correct.  However, that doesn't preclude the repos as we
know them today from still existing, with still the same quality.  As
far as I'm aware, the products are still planning on being built from
packages provided by the Fedora project, from the Fedora buildsystem.

So yes, there may very well be different options.  That doesn't mean
they can't also be the same if you choose not to use those different
things.  I understand your concern and it's something worth watching,
but I don't think it's a foregone conclusion that things will be
horrible or users will be forced to give up RPMs and repos.

josh
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Fedora.next in 2014 -- Big Picture and Themes

2014-01-23 Thread Stephen John Smoogen

On 23 January 2014 14:14, Josh Boyer jwbo...@fedoraproject.org wrote:

 On Thu, Jan 23, 2014 at 3:53 PM, Stephen John Smoogen smo...@gmail.com
 wrote:

  My view of the matter was pretty much the same as Tom's and I was at
 FLOCK.
  The language at the sessions I attended was not one of We would like to
 do
  this but that it was a done thing. I realize a lot of that is the 'get
 shit
  done because we are all together' mentality which comes from conferences
 but
  by the time I left FLOCK I was pretty sure this was all done and either
 get
  in the boat or get out. I wasn't even aware of the FESCO items until this
  email as I figured it had been done and decided at FLOCK.

 If one is advocating for something they strongly believe in, they
 definitely are not going to say I think maybe we should do this kinda
 but it might be a crazy idea.  They advocate by saying I am going to
 do this and I am going to drive it forward until I am told no.  That
 doesn't mean they can just skip all the processes and steps required
 to get their idea approved.


I would be a lot happier if people actually did have some humility and at
least went with 'this might be a crazy idea but I am doing the following
and I would like people to try it out' and actually listening to the people
who did try it out. Instead we have a lot of 'I have written X and it is
what we will be using in the next release'. and then wonder why the hell we
cut our install and contributor base after that next release.


 Boostrapping is hard.  I didn't come up with the idea and this might
 not have been the best way to do it, but hindsight is 20/20.  I do
 hope that if you are interested in a WG/Product that you do
 participate because the governance for them is set up and will allow
 different WG members going forward.  I've also seen lots of non-member
 participation be really fruitful already.


I do not doubt that non-member participation has been fruitful. At this
point of the proceedings most of my time is spent hitting the 'd' key
because my responses would not be fruitful and in a couple of cases, career
limiting. You people don't need any more of that negativity, you already
have enough. Once people get to the the technical side of how to accomplish
possibly 4 times the work with RPMS and alternate packages on the same or
less hardware and disk space.. then it becomes an interesting problem to me
where I can contribute.

-- 
Stephen J Smoogen.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Fedora.next in 2014 -- Big Picture and Themes

quoting simplified:  is Tom Hughes,  is me,  is Josh. Restored
part of Tom's original context.

  The actual spins (or whatever you want to call them) aren't something 
  that bother me at all, as they are to my mind largely irrelevant for 
  anybody other than a new user. When I bring a new machine up I just want 
  to get a base OS on and access to the package repository and what 
  packages are installed by default doesn't really bother me.

   To be honest my concerns are more with my user hat on than my contributor
   hat - that we will lose the gold standard unified packaging standards and
   single source and mechanism for installing packages.

  If these plans go ahead, we will have multiple official/blessed methods
  for deploying software on Fedora, potentially with different policies
  about what software they can include and how that software should be
  arranged, how dependencies should be handled, and all the rest of it.
  Some of these methods will be shared between products, and some will
  either only exist in certain products, or at least be clearly associated
  with and 'owned' by those products.
 
 Also possibly correct.  However, that doesn't preclude the repos as we
 know them today from still existing, with still the same quality.

Read all the above sequentially. My point is that although you are
technically correct that no WG has proposed doing away with the repos,
the RPM format, or yum/dnf, their plans - under a reasonable
interpretation of the discussions so far - still invalidate the
assumptions he is currently making: he can no longer assume that all he
basically has to worry about is getting 'Fedora' installed somehow and
he can then install whatever he likes. Broadly stated, it will no longer
be valid to conceive of Fedora as a large package repository with some
installation methods attached to it, whereas currently that's a pretty
reasonable conceptual framework that I believe many people (not just
Tom) employ.

In other words, Tom was really correct. ;)

   As
 far as I'm aware, the products are still planning on being built from
 packages provided by the Fedora project, from the Fedora buildsystem.
 
 So yes, there may very well be different options.  That doesn't mean
 they can't also be the same if you choose not to use those different
 things.

Is that going to be a reasonably sustainable approach, though? It's at
least possible that it won't. What if the Desktop 'product' starts
caring much about shipping commonly-used desktop applications as 'app
bundles' rather than packages? What if the Server 'product' implements
Wordpress as a container image rather than a package?

   I understand your concern and it's something worth watching,
 but I don't think it's a foregone conclusion that things will be
 horrible or users will be forced to give up RPMs and repos.
 
 josh

I certainly agree that it's not a foregone conclusion, and I don't think
I suggested it was, but your initial email seemed to more or less
entirely dismiss the possibility, and I don't think that's warranted.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net


-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Fedora.next in 2014 -- Big Picture and Themes

On Thu, Jan 23, 2014 at 5:16 PM, Adam Williamson awill...@redhat.com wrote:
 quoting simplified:  is Tom Hughes,  is me,  is Josh. Restored
 part of Tom's original context.

  The actual spins (or whatever you want to call them) aren't something
  that bother me at all, as they are to my mind largely irrelevant for
  anybody other than a new user. When I bring a new machine up I just want
  to get a base OS on and access to the package repository and what
  packages are installed by default doesn't really bother me.

   To be honest my concerns are more with my user hat on than my contributor
   hat - that we will lose the gold standard unified packaging standards and
   single source and mechanism for installing packages.

  If these plans go ahead, we will have multiple official/blessed methods
  for deploying software on Fedora, potentially with different policies
  about what software they can include and how that software should be
  arranged, how dependencies should be handled, and all the rest of it.
  Some of these methods will be shared between products, and some will
  either only exist in certain products, or at least be clearly associated
  with and 'owned' by those products.

 Also possibly correct.  However, that doesn't preclude the repos as we
 know them today from still existing, with still the same quality.

 Read all the above sequentially. My point is that although you are
 technically correct that no WG has proposed doing away with the repos,
 the RPM format, or yum/dnf, their plans - under a reasonable
 interpretation of the discussions so far - still invalidate the
 assumptions he is currently making: he can no longer assume that all he
 basically has to worry about is getting 'Fedora' installed somehow and
 he can then install whatever he likes. Broadly stated, it will no longer
 be valid to conceive of Fedora as a large package repository with some
 installation methods attached to it, whereas currently that's a pretty
 reasonable conceptual framework that I believe many people (not just
 Tom) employ.

 In other words, Tom was really correct. ;)

I don't see how you come to that conclusion, at least not without
making some large assumptions.  The addition of alternate solutions
for package installation and deployment doesn't preclude people from
being able to install Fedora and use the underlying tools to point to
the existing repos.


   As
 far as I'm aware, the products are still planning on being built from
 packages provided by the Fedora project, from the Fedora buildsystem.

 So yes, there may very well be different options.  That doesn't mean
 they can't also be the same if you choose not to use those different
 things.

 Is that going to be a reasonably sustainable approach, though? It's at
 least possible that it won't. What if the Desktop 'product' starts
 caring much about shipping commonly-used desktop applications as 'app
 bundles' rather than packages? What if the Server 'product' implements
 Wordpress as a container image rather than a package?

What if, what if, what if.  Yes, all possible.  Also possible is that
we punt on the whole idea.  This is the point where we diverge.  I do
not see value in somehow saying things will be different and one
_cannot_ still do things they do today with no indication that such a
world is even planned.  You seem to be very cautionary of the whole
thing.  Neither view is wrong.

   I understand your concern and it's something worth watching,
 but I don't think it's a foregone conclusion that things will be
 horrible or users will be forced to give up RPMs and repos.

 josh

 I certainly agree that it's not a foregone conclusion, and I don't think
 I suggested it was, but your initial email seemed to more or less
 entirely dismiss the possibility, and I don't think that's warranted.

I wasn't being dismissive.  I have seen no plans to alter the core of
how Fedora, at a package level, is built.  In fact, if I did see a
proposal that said we're not going to ship repositories or RPMs I'd
be pretty damned upset, and I wouldn't support that.

At this point I think our conversation is going to cease being
productive, but I do believe it's been productive thus far.  Thanks!

josh
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Fedora.next in 2014 -- Big Picture and Themes

On Thu, 2014-01-23 at 17:26 -0500, Josh Boyer wrote:

  Read all the above sequentially. My point is that although you are
  technically correct that no WG has proposed doing away with the repos,
  the RPM format, or yum/dnf, their plans - under a reasonable
  interpretation of the discussions so far - still invalidate the
  assumptions he is currently making: he can no longer assume that all he
  basically has to worry about is getting 'Fedora' installed somehow and
  he can then install whatever he likes. Broadly stated, it will no longer
  be valid to conceive of Fedora as a large package repository with some
  installation methods attached to it, whereas currently that's a pretty
  reasonable conceptual framework that I believe many people (not just
  Tom) employ.
 
  In other words, Tom was really correct. ;)
 
 I don't see how you come to that conclusion, at least not without
 making some large assumptions.  The addition of alternate solutions
 for package installation and deployment doesn't preclude people from
 being able to install Fedora and use the underlying tools to point to
 the existing repos.

No, I don't disagree with you there. But the repos don't exist in a
vacuum. Right now they are our way of shipping software in Fedora: our
*only* way. If you want to install the Fedora-y version of a particular
piece of software, you use the repositories. End of story.

All I'm saying is that the .next proposals at least seem to be
introducing the possibility that that will no longer be the case. i.e.,
the possibility that there will be software within the Fedora
(distribution, not project) ecosystem that you cannot deploy using our
package tools and package repositories.

It would of course be *possible* for someone to duplicate any work done
by any of the WGs in the repositories, but it is not *guaranteed* that
this happens. If the desktop WG decides to start shipping some apps as
bundles not packages, and no-one takes up the work of duplicating that
effort in the repositories, then the situation is different to how it is
now: you can no longer rely on the idea that all 'Fedora provided
software' is in the repository system. You must choose between doing
whatever it is you have to do to access the alternative/secondary
distribution methods - which I agree it's not worth speculating about
yet - or not having access to all 'Fedora provided software'. That's all
I'm saying. I'm not drawing any kinds of conclusions from this: my goal
is only to ensure that all implications of possible choices here are
considered.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Fedora.next in 2014 -- Big Picture and Themes

2014-01-23 Thread drago01

On Thu, Jan 23, 2014 at 11:34 PM, Adam Williamson awill...@redhat.com wrote:
 On Thu, 2014-01-23 at 17:26 -0500, Josh Boyer wrote:

  Read all the above sequentially. My point is that although you are
  technically correct that no WG has proposed doing away with the repos,
  the RPM format, or yum/dnf, their plans - under a reasonable
  interpretation of the discussions so far - still invalidate the
  assumptions he is currently making: he can no longer assume that all he
  basically has to worry about is getting 'Fedora' installed somehow and
  he can then install whatever he likes. Broadly stated, it will no longer
  be valid to conceive of Fedora as a large package repository with some
  installation methods attached to it, whereas currently that's a pretty
  reasonable conceptual framework that I believe many people (not just
  Tom) employ.
 
  In other words, Tom was really correct. ;)

 I don't see how you come to that conclusion, at least not without
 making some large assumptions.  The addition of alternate solutions
 for package installation and deployment doesn't preclude people from
 being able to install Fedora and use the underlying tools to point to
 the existing repos.

 No, I don't disagree with you there. But the repos don't exist in a
 vacuum. Right now they are our way of shipping software in Fedora: our
 *only* way. If you want to install the Fedora-y version of a particular
 piece of software, you use the repositories. End of story.

I can do gem install foo or pip install foo on current (and past)
fedora releases.
So no the story does not quite end here ;)
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Fedora.next in 2014 -- Big Picture and Themes

On Thu, 2014-01-23 at 23:37 +0100, drago01 wrote:

  No, I don't disagree with you there. But the repos don't exist in a
  vacuum. Right now they are our way of shipping software in Fedora: our
  *only* way. If you want to install the Fedora-y version of a particular
  piece of software, you use the repositories. End of story.
 
 I can do gem install foo or pip install foo on current (and past)
 fedora releases.
 So no the story does not quite end here ;)

Those are not Fedora-provided software. At the point you install and
invoke gem or pip, you are making an explicit decision to use non-Fedora
software. Which is, of course, perfectly fine: but it's not an analogous
situation to there being alternative distribution methods *within the
Fedora distribution*.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Fedora.next in 2014 -- Big Picture and Themes

2014-01-23 Thread drago01

On Thu, Jan 23, 2014 at 11:38 PM, Adam Williamson awill...@redhat.com wrote:
 On Thu, 2014-01-23 at 23:37 +0100, drago01 wrote:

  No, I don't disagree with you there. But the repos don't exist in a
  vacuum. Right now they are our way of shipping software in Fedora: our
  *only* way. If you want to install the Fedora-y version of a particular
  piece of software, you use the repositories. End of story.

 I can do gem install foo or pip install foo on current (and past)
 fedora releases.
 So no the story does not quite end here ;)

 Those are not Fedora-provided software. At the point you install and
 invoke gem or pip, you are making an explicit decision to use non-Fedora
 software. Which is, of course, perfectly fine: but it's not an analogous
 situation to there being alternative distribution methods *within the
 Fedora distribution*.

Sure but people do that. We can either pretend they don't or try to
somehow deal with it. Currently we are exploring ways to deal with it.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Fedora.next in 2014 -- Big Picture and Themes

2014-01-23 Thread Reindl Harald


Am 23.01.2014 23:49, schrieb drago01:
 On Thu, Jan 23, 2014 at 11:46 PM, Reindl Harald h.rei...@thelounge.net 
 wrote:

 Am 23.01.2014 23:37, schrieb drago01:
 On Thu, Jan 23, 2014 at 11:34 PM, Adam Williamson awill...@redhat.com 
 wrote:
 No, I don't disagree with you there. But the repos don't exist in a
 vacuum. Right now they are our way of shipping software in Fedora: our
 *only* way. If you want to install the Fedora-y version of a particular
 piece of software, you use the repositories. End of story.

 I can do gem install foo or pip install foo on current (and past)
 fedora releases.
 So no the story does not quite end here ;)

 there is a difference if you *want* do so or *forced* to do so
 because there is no longer a *single* and consistent package
 source what is over years and still *THE* greath strength of
 a linux *distribution*
 
 No one is proposing to force anyone to do anything so stop the FUD please

where in the world do you see FUD?

if a software is packed the new way and no longer available in the
classical repos as RPM you are forced to use whatever to install
the package this way instead of a single source like YUM

what about consider the result of changes over the long instead
insinuate someone is spreading FUD with no reason to do so



signature.asc
Description: OpenPGP digital signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Fedora.next in 2014 -- Big Picture and Themes

2014-01-23 Thread Lars Seipel

On Thu, Jan 23, 2014 at 05:07:16PM -0500, Josh Boyer wrote:
 Also possibly correct.  However, that doesn't preclude the repos as we
 know them today from still existing, with still the same quality.

Server, desktop or embedded board, in today's Fedora it's all the same,
just with a different package set installed. People (not all, obviously)
consider this a good thing. I just have to put a minimal Fedora install
on some machine and then build it from there.

That's what Tom was getting at, I think. The discussions in the WGs so
far have hinted that it's not necessarily a reasonable expectation that
this will continue to be the case. An oft-cited reason was that RPMs
apparently can't provide the 'integration' that is somehow wanted.

I always considered it nice that there's only a single Fedora. I thought
that split products were mostly an artefact of commercial
differentiation and so Fedora users don't have to deal with you can't
use this filesystem unless you have the Ultra Enterprise Storage
Edition or stuff like that. ☺
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Fedora.next in 2014 -- Big Picture and Themes

2014-01-23 Thread Matthew Miller

On Thu, Jan 23, 2014 at 02:16:23PM -0800, Adam Williamson wrote:
 Read all the above sequentially. My point is that although you are
 technically correct that no WG has proposed doing away with the repos,
 the RPM format, or yum/dnf, their plans - under a reasonable
 interpretation of the discussions so far - still invalidate the
 assumptions he is currently making: he can no longer assume that all he
 basically has to worry about is getting 'Fedora' installed somehow and
 he can then install whatever he likes. Broadly stated, it will no longer
 be valid to conceive of Fedora as a large package repository with some
 installation methods attached to it, whereas currently that's a pretty
 reasonable conceptual framework that I believe many people (not just
 Tom) employ.
 
 In other words, Tom was really correct. ;)

Well, maybe. It really is the case that nothing is finalized and it's a
legitimate concern. This is why we (and here I'm using we not in the royal
sense but because it really wasn't just _me_) have the Base Design, not just
three separate product working groups. I share the trepidation about adding
more bureaucracy, but also seems pretty important to keep a coherent shared
base. 

It's possible that eventually it'll be kind of hard to go from Fedora
Workstation to Fedora Cloud, or from Fedora Cloud to Fedora Workstation --
but that's not _really_ so different from how it is now, where if you start
from one of those and try to go to the other, you're going to have to tear
down a bunch of things first. On the other hand, the Cloud WG made the
ability to go from Fedora Cloud to Fedora Server an explicit goal.

Either way, I think it's pretty likely that someone who wants to start with
the base and build up will be able to with, with varying possible degrees of
difficulty. It may also end up that it's easier to make and share specific,
lightweight remixes, so that while you don't necessarily build up in an
install, you do it in a tool of some sort -- that was part of Stephen
Gallagher's original products idea, if I'm remembering right.

  So yes, there may very well be different options.  That doesn't mean
  they can't also be the same if you choose not to use those different
  things.
 Is that going to be a reasonably sustainable approach, though? It's at
 least possible that it won't. What if the Desktop 'product' starts
 caring much about shipping commonly-used desktop applications as 'app
 bundles' rather than packages? What if the Server 'product' implements
 Wordpress as a container image rather than a package?

That might happen, although I would be shocked if anyone has anything near
workable for F21 timeframe. Or F22. But, would it be so bad? People who are
interested in packaging it in the traditional way still could... or, at
least _I_ hope so -- that's been part of my version of the proposal since
the beginning.

-- 
Matthew Miller--   Fedora Project--mat...@fedoraproject.org
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Fedora.next in 2014 -- Big Picture and Themes