12:23 p.m.
Okay, I started a requirements document for the playground repository:
https://fedoraproject.org/wiki/Env_and_Stacks/Playground_repository_%28dr...
There's three things that we need to do with this to make it useful for FESCo:
1) Add other things we need to decide on to the Open Questions. We
especially need things that will affect the work needed to implement
the repository but we can decide which things those are later.
2) Decide which features from the Open Questions we want to apply to
the Playground repository. Update the description section as we make
decisions.
3) Analyze what will be needed to implement the features we've decided
the Playground repository needs to have and fill in the Identified
Needs sections with that information.
-Toshio
9:40 a.m.
On 02/25/2014 07:23 PM, Toshio Kuratomi wrote:
Okay, I started a requirements document for the playground
repository:
https://fedoraproject.org/wiki/Env_and_Stacks/Playground_repository_%28dr...
There's three things that we need to do with this to make it useful for FESCo:
1) Add other things we need to decide on to the Open Questions. We
especially need things that will affect the work needed to implement
the repository but we can decide which things those are later.
2) Decide which features from the Open Questions we want to apply to
the Playground repository. Update the description section as we make
decisions.
3) Analyze what will be needed to implement the features we've decided
the Playground repository needs to have and fill in the Identified
Needs sections with that information.
-Toshio
_______________________________________________
env-and-stacks mailing list
env-and-stacks(a)lists.fedoraproject.org
https://lists.fedoraproject.org/mailman/listinfo/env-and-stacks
Thanks for the draft. I left comments to some points, but I'd rather
discuss it on next meeting, but because you probably won't be there...
My opinions on Open Questions:
* signing - sure we need to sign (copr requirement)
* I would prefer rolling updates and no testing repository. It's
Playground, bugs can be there.
* I don't know what's mirrormanager. Mirroring to all Fedora mirrors? I
guess we don't need it at start.
* self hosting - no, I guess we don't have to ship BuildRequires in
Playground repo. It can do shipping of some packages easier.
* no reviews! It should be quick and easy. Maybe someone else than owner
of copr repo should approve new projects, which will go into Playground.
Maybe cla+1 could mean automatic push into Playground if user click on
button Playground.
Marcela
11:54 a.m.
On Wed, Feb 26, 2014 at 04:40:40PM +0100, Marcela Mašláňová wrote:
>
Thanks for the draft. I left comments to some points, but I'd rather
discuss it on next meeting, but because you probably won't be
there...
Some notes on the comments:
The Legal comment. I think you and I agree. If the language is unclear,
could you rerite it? I basically am wanting to duplicate the guidelines for
copr as theoretically, the requirements for this repo and copr repos can
differ (the requirement that a non-free software but distributable license
is not okay in copr is a fesco policy, not a RH Legal requirement.
Similarly, the decision that Fedora itself doesn't ship non-free software is
a Board decision.
The Conflicts and replace comments. I thought it had been decided that
conflicts and replacements should not be allowed. If that wasn't
a decision we should probably kick those choices back down to the open
questions. I've done so now and we can discuss that on the Open Questions
part of this thread/the next meeting.
-Toshio
6:53 a.m.
On 02/26/2014 06:54 PM, Toshio Kuratomi wrote:
On Wed, Feb 26, 2014 at 04:40:40PM +0100, Marcela Mašláňová wrote:
>>
> Thanks for the draft. I left comments to some points, but I'd rather
> discuss it on next meeting, but because you probably won't be
> there...
>
Some notes on the comments:
The Legal comment. I think you and I agree. If the language is unclear,
could you rerite it? I basically am wanting to duplicate the guidelines for
copr as theoretically, the requirements for this repo and copr repos can
differ (the requirement that a non-free software but distributable license
is not okay in copr is a fesco policy, not a RH Legal requirement.
Similarly, the decision that Fedora itself doesn't ship non-free software is
a Board decision.
What if we check licenses by licorice (scanning licenses)? It can't find
every strange licence, but enough to pass legal requirement. My team
tested it on bigger set of packages and output was quite good. We could
set legal flag if bad license occurred in package and rest could go into
repo without manual review.
https://github.com/tradej/licorice
The Conflicts and replace comments. I thought it had been decided
that
conflicts and replacements should not be allowed. If that wasn't
a decision we should probably kick those choices back down to the open
questions. I've done so now and we can discuss that on the Open Questions
part of this thread/the next meeting.
-Toshio
You are right we reached some conclusion on conflicts and replace, but
what if we want for example new v8? We have terribly old v8 in current
Fedora and conflicts might be a good solution in this case.
Marcela
8:26 a.m.
On Thu 27 Feb 2014 01:53:06 PM CET Marcela Mašláňová wrote:
On 02/26/2014 06:54 PM, Toshio Kuratomi wrote:
> The Conflicts and replace comments. I thought it had been decided that
> conflicts and replacements should not be allowed. If that wasn't
> a decision we should probably kick those choices back down to the open
> questions. I've done so now and we can discuss that on the Open Questions
> part of this thread/the next meeting.
>
> -Toshio
>
You are right we reached some conclusion on conflicts and replace, but
what if we want for example new v8? We have terribly old v8 in current
Fedora and conflicts might be a good solution in this case.
This would be just a simple update. No conflicts required if I am not
mistaken right?
--
Stanislav Ochotnicky <sochotnicky(a)redhat.com>
Software Engineer - Developer Experience
PGP: 7B087241
Red Hat Inc. http://cz.redhat.com
8:36 a.m.
On 02/27/2014 03:26 PM, Stanislav Ochotnicky wrote:
On Thu 27 Feb 2014 01:53:06 PM CET Marcela Mašláňová wrote:
> On 02/26/2014 06:54 PM, Toshio Kuratomi wrote:
>> The Conflicts and replace comments. I thought it had been decided that
>> conflicts and replacements should not be allowed. If that wasn't
>> a decision we should probably kick those choices back down to the open
>> questions. I've done so now and we can discuss that on the Open Questions
>> part of this thread/the next meeting.
>>
>> -Toshio
>>
> You are right we reached some conclusion on conflicts and replace, but
> what if we want for example new v8? We have terribly old v8 in current
> Fedora and conflicts might be a good solution in this case.
This would be just a simple update. No conflicts required if I am not
mistaken right?
--
Stanislav Ochotnicky <sochotnicky(a)redhat.com>
Software Engineer - Developer Experience
PGP: 7B087241
Red Hat Inc. http://cz.redhat.com
It depends what we want. Maybe updates are fine if users know Playground
means your system could be updated more than you thought.
Marcela
8:50 a.m.
----- Original Message -----
On 02/26/2014 06:54 PM, Toshio Kuratomi wrote:
> On Wed, Feb 26, 2014 at 04:40:40PM +0100, Marcela Mašláňová wrote:
> The Conflicts and replace comments. I thought it had been decided that
> conflicts and replacements should not be allowed. If that wasn't
> a decision we should probably kick those choices back down to the open
> questions. I've done so now and we can discuss that on the Open Questions
> part of this thread/the next meeting.
>
> -Toshio
>
You are right we reached some conclusion on conflicts and replace, but
what if we want for example new v8? We have terribly old v8 in current
Fedora and conflicts might be a good solution in this case.
It's Copr use case... Really, let's not try to invent "every single use
case anybody can think about" repo that suits no one.
Jaroslav
Marcela
_______________________________________________
env-and-stacks mailing list
env-and-stacks(a)lists.fedoraproject.org
https://lists.fedoraproject.org/mailman/listinfo/env-and-stacks
1:43 p.m.
On Thu, Feb 27, 2014 at 01:53:06PM +0100, Marcela Mašláňová wrote:
On 02/26/2014 06:54 PM, Toshio Kuratomi wrote:
>On Wed, Feb 26, 2014 at 04:40:40PM +0100, Marcela Mašláňová wrote:
>>>
>>Thanks for the draft. I left comments to some points, but I'd rather
>>discuss it on next meeting, but because you probably won't be
>>there...
>>
>Some notes on the comments:
>
>The Legal comment. I think you and I agree. If the language is unclear,
>could you rerite it? I basically am wanting to duplicate the guidelines for
>copr as theoretically, the requirements for this repo and copr repos can
>differ (the requirement that a non-free software but distributable license
>is not okay in copr is a fesco policy, not a RH Legal requirement.
>Similarly, the decision that Fedora itself doesn't ship non-free software is
>a Board decision.
>
What if we check licenses by licorice (scanning licenses)? It can't
find every strange licence, but enough to pass legal requirement. My
team tested it on bigger set of packages and output was quite good.
We could set legal flag if bad license occurred in package and rest
could go into repo without manual review.
https://github.com/tradej/licorice
Yes, I might not have been clear -- we don't necessarily have to check that
packages comply with the policy before the packages can get into the
repository. The License policy, for instance, could be applied if people
notice and complain, for instance (because this is what spot has okay'd
for coprs in general).
Having an automated tool would be even nicer :-)
Conflicts and replacement policy might be something that needs checking
before it goes in (as we can't take a package off of endusers' systems so
we might want to make sure that these play nicely before pulling them in).
However, that might be something we can automate...If possible, we really
should automate as we could then run it everytime we're merging in new
builds. Given that packagesets will vary over time,
>The Conflicts and replace comments. I thought it had been
decided that
>conflicts and replacements should not be allowed. If that wasn't
>a decision we should probably kick those choices back down to the open
>questions. I've done so now and we can discuss that on the Open Questions
>part of this thread/the next meeting.
>
>-Toshio
>
You are right we reached some conclusion on conflicts and replace,
but what if we want for example new v8? We have terribly old v8 in
current Fedora and conflicts might be a good solution in this case.
<nod> I'm perfectly willing for us to reopen this discussion.
There's pros and cons to each idea. Allowing replacement might be better
than Conflicts for the case you mention, though. With replacement, there's
the chance that the end user can continue to use Fedora software that was
built with the older version of v8 in mind. With Conflicts, chances are
that the users would always have to choose whether to install the set of
packages that were built against the Fedora Main Repo version or the set of
packages that were built against the Fedora Playground Repo.
-Toshio
12:10 p.m.
On Thu, 2014-02-27 at 13:53 +0100, Marcela Mašláňová wrote:
>
You are right we reached some conclusion on conflicts and replace, but
what if we want for example new v8? We have terribly old v8 in current
Fedora and conflicts might be a good solution in this case.
I think the Playground repo is not the right place to start providing
newer versions of existing packages in Fedora's main repository.
My arguments are:
1) The package in the main repo went through a proper package review.
The replacing package didn't.
2) The package's maintainer probably has reasons why he hasn't updated
the package (we should trust maintainers by default and not over-ride
them).
The way to approach this, in my opinion, is to talk to the maintainer of
the package in the main repository and work out if it is reasonable to
update the package in the desired Fedora version or not.
If the reason why the maintainer hasn't updated the package is lack of
time, applying for co-maintenance is the way to go.
There will be cases when the maintainer doesn't want to update the
package in the main repository and a newer version is needed/desired.
In case the package is:
1) some leaf package (e.g. an application), it would be sensible to just
create a COPR repo for it.
2) part of a software stack (e.g. a library), it would be sensible to
create a SCL with the required versions of the packages of the software
stack and provide it in the Playgroud repo. This SCL could then be
required by the applications needing this particular versions.
Tadej
1:42 p.m.
On 01/03/14 19:10, Tadej Janež wrote:
On Thu, 2014-02-27 at 13:53 +0100, Marcela Mašláňová wrote:
>>
> You are right we reached some conclusion on conflicts and replace, but
> what if we want for example new v8? We have terribly old v8 in current
> Fedora and conflicts might be a good solution in this case.
I think the Playground repo is not the right place to start providing
newer versions of existing packages in Fedora's main repository.
My arguments are:
1) The package in the main repo went through a proper package review.
The replacing package didn't.
2) The package's maintainer probably has reasons why he hasn't updated
the package (we should trust maintainers by default and not over-ride
them).
The way to approach this, in my opinion, is to talk to the maintainer of
the package in the main repository and work out if it is reasonable to
update the package in the desired Fedora version or not.
If the reason why the maintainer hasn't updated the package is lack of
time, applying for co-maintenance is the way to go.
There will be cases when the maintainer doesn't want to update the
package in the main repository and a newer version is needed/desired.
In case the package is:
1) some leaf package (e.g. an application), it would be sensible to just
create a COPR repo for it.
2) part of a software stack (e.g. a library), it would be sensible to
create a SCL with the required versions of the packages of the software
stack and provide it in the Playgroud repo. This SCL could then be
required by the applications needing this particular versions.
Tadej
_______________________________________________
env-and-stacks mailing list
env-and-stacks(a)lists.fedoraproject.org
https://lists.fedoraproject.org/mailman/listinfo/env-and-stacks
I was afraid to say "you should use SCL" :) There are many use-cases for
additional repositories and we have to pick the most sane, therefore I
agree with your points.
Marcela
5:16 a.m.
On 03/01/2014 07:10 PM, Tadej Janež wrote:
On Thu, 2014-02-27 at 13:53 +0100, Marcela Mašláňová wrote:
>>
> You are right we reached some conclusion on conflicts and replace, but
> what if we want for example new v8? We have terribly old v8 in current
> Fedora and conflicts might be a good solution in this case.
I think the Playground repo is not the right place to start providing
newer versions of existing packages in Fedora's main repository.
My arguments are:
1) The package in the main repo went through a proper package review.
The replacing package didn't.
2) The package's maintainer probably has reasons why he hasn't updated
the package (we should trust maintainers by default and not over-ride
them).
The way to approach this, in my opinion, is to talk to the maintainer of
the package in the main repository and work out if it is reasonable to
update the package in the desired Fedora version or not.
If the reason why the maintainer hasn't updated the package is lack of
time, applying for co-maintenance is the way to go.
There will be cases when the maintainer doesn't want to update the
package in the main repository and a newer version is needed/desired.
In case the package is:
1) some leaf package (e.g. an application), it would be sensible to just
create a COPR repo for it.
2) part of a software stack (e.g. a library), it would be sensible to
create a SCL with the required versions of the packages of the software
stack and provide it in the Playgroud repo. This SCL could then be
required by the applications needing this particular versions.
Right, that makes sense for me; allowing conflicts and updates seems
like allow creating too big mess.
I can also see another cases:
3) introducing a new package under a different name --say we want to
prepare a new un-stable/dirty version of a package foo, which is already
in Fedora and we'd like to introduce it in Playground (which would mean
the package foo would be updated for every user who has enabled
Playground). If we introduce the new package under featurex-foo or
userx-foo, we can safely add it into Playground.
4) We have a stack of packages that I want to deliver to Fedora users,
but the stack would update some packages from Fedora base repo and/or we
do not want to use SCLs. Then we can get a Copr repository as a RPM
package and include this RPM in the Playground, so people installing
this RPM package would actually say: "Yes, I want to enable these
packages and I agree to get some of my Fedora-base packages updated".
Honza
8:14 p.m.
On 03.03.2014 13:16, Honza Horak wrote:
Right, that makes sense for me; allowing conflicts and updates seems
like allow creating too big mess.
I can also see another cases:
3) introducing a new package under a different name --say we want to
prepare a new un-stable/dirty version of a package foo, which is already
in Fedora and we'd like to introduce it in Playground (which would mean
the package foo would be updated for every user who has enabled
Playground). If we introduce the new package under featurex-foo or
userx-foo, we can safely add it into Playground.
4) We have a stack of packages that I want to deliver to Fedora users,
but the stack would update some packages from Fedora base repo and/or we
do not want to use SCLs. Then we can get a Copr repository as a RPM
package and include this RPM in the Playground, so people installing
this RPM package would actually say: "Yes, I want to enable these
packages and I agree to get some of my Fedora-base packages updated".
I think all 3 paragraphs above are very wise. Few more humble opinions:
3) could be extended with different (not only newer). If the packager is
able to get the older version coherently regarding Fedora+Playground -
why not.
4) will be really nice, but I think that for the playground .repo RPMs
should exist some form of review (e.g. from Fedora packager or by
env-and-stacks WG?)
I think that Playground could also play a nice role as a training camp
for some potential Fedora packagers and if so, which elements from the
standard process would be good to be presented in lightest possible
variant? Random thoughts:
- github.com/fedora-playground organizational account managed by
env-and-stacks and used as dist-git
- ~/index/wiki analog of the guidelines, containing also some important
excerpts of the real guidelines as friendly recommendations for possible
improvements
- ~/index/issues analog of the review request BZ, but with very easy
ticket creation e.g. filled by web interface at playground.fp.o
requiring just source COPR with successful builds for the requested
arch/branch matrix. Then our machinery should check the package for the
basic requirements: licenses, no f updates, build requires in f+p,
coherency against f+p.
- ~/package/issues as package bugtracker synced by the github api when
abrt or an user fills a bug against the package into the central Bugzilla.
Kind regards,
Alek
P.S. Weather someone already works on JS interface (local web app) for
generating/supporting .specs files based on local yumdb and the .spec
grammar?. Is this a good idea? Showing rpmbuild and copr-cli command
lines to the future packager?
6:09 a.m.
On 03/04/2014 03:14 AM, Alek Paunov wrote:
P.S. Weather someone already works on JS interface (local web app)
for
generating/supporting .specs files based on local yumdb and the .spec
grammar?. Is this a good idea? Showing rpmbuild and copr-cli command
lines to the future packager?
Hm, it seems like your imagination is on a higher level, in comparison
with mine -- could you elaborate a bit, please?
Honza
4:14 p.m.
On 04.03.2014 14:09, Honza Horak wrote:
On 03/04/2014 03:14 AM, Alek Paunov wrote:
> P.S. Weather someone already works on JS interface (local web app) for
> generating/supporting .specs files based on local yumdb and the .spec
> grammar?. Is this a good idea? Showing rpmbuild and copr-cli command
> lines to the future packager?
Hm, it seems like your imagination is on a higher level, in comparison
with mine -- could you elaborate a bit, please?
Sure, hope something bellow makes sense:
- Formal .spec grammar [1] including system macros and Lua libs
as subgrammars
- Work area: Structure editor following the above grammar
- Flying palette:
- .spec sections, macros and snippets
- dependency points by searching/browsing yumdb.provides,
requires, etc.
- The user drag/drops things from the palette to the structure
- After dropping a construct, the user fills the blanks:
- using the upstream build instructions
- ideally, consulting the same sections from Fedora packages
belonging to the same stack (browsing existing specs parts)
- Change log in own view, automatic change log entry
- Iteration:
- spec save
- instead of directly issuing the commands, tool interactively
construct command lines (with educational goal behind) based
on their grammars
- rpmbuild -b.. --...
- createrepo
- .repo file
- copr-cli ...
- ...
- Feature for parsing and reusing existing .spec as template instead
of blank page start
Motivation:
Regarding the classic - RPM based distribution mechanism, we are going
to have 3-levels:
1. COPR owner
2. Playground contributor
3. Fedora packager
Such a easy .spec editor would be mostly targeted towards the entry
point: COPR owner. The Fedora packagers, thousands of experienced
corporate developers and sysadmins are all used with the .spec format
and it's ugliness, but for a new (let's say node.js generation,
otherwise relatively knowledgeable) potential contributor .spec could be
disappointing.
Why JS - In my eyes, a structure editor would be easier to be build
using the new browser technologies in comparison with the classic widget
kits; Will looks equally (non :-) ) native under both KDE and Gnome or
even (parts of) as a fp.o page.
If it managed to be concept-proved on .specs (based solely on grammars
and queries) may be will be possible to be reused for kikstarts and
systemd units too (e.g. other basic Fedora artifacts)?
Kind regards,
Alek
[1] https://lists.fedoraproject.org/pipermail/devel/2013-May/183195.html
3:45 a.m.
Dne 4.3.2014 23:14, Alek Paunov napsal(a):
On 04.03.2014 14:09, Honza Horak wrote:
> On 03/04/2014 03:14 AM, Alek Paunov wrote:
>> P.S. Weather someone already works on JS interface (local web app) for
>> generating/supporting .specs files based on local yumdb and the .spec
>> grammar?. Is this a good idea? Showing rpmbuild and copr-cli command
>> lines to the future packager?
>
> Hm, it seems like your imagination is on a higher level, in comparison
> with mine -- could you elaborate a bit, please?
>
Sure, hope something bellow makes sense:
- Formal .spec grammar [1] including system macros and Lua libs
as subgrammars
- Work area: Structure editor following the above grammar
- Flying palette:
- .spec sections, macros and snippets
- dependency points by searching/browsing yumdb.provides,
requires, etc.
- The user drag/drops things from the palette to the structure
- After dropping a construct, the user fills the blanks:
- using the upstream build instructions
- ideally, consulting the same sections from Fedora packages
belonging to the same stack (browsing existing specs parts)
- Change log in own view, automatic change log entry
- Iteration:
- spec save
- instead of directly issuing the commands, tool interactively
construct command lines (with educational goal behind) based
on their grammars
- rpmbuild -b.. --...
- createrepo
- .repo file
- copr-cli ...
- ...
- Feature for parsing and reusing existing .spec as template instead
of blank page start
Motivation:
Regarding the classic - RPM based distribution mechanism, we are going
to have 3-levels:
1. COPR owner
2. Playground contributor
3. Fedora packager
Such a easy .spec editor would be mostly targeted towards the entry
point: COPR owner. The Fedora packagers, thousands of experienced
corporate developers and sysadmins are all used with the .spec format
and it's ugliness, but for a new (let's say node.js generation,
otherwise relatively knowledgeable) potential contributor .spec could
be disappointing.
Why JS - In my eyes, a structure editor would be easier to be build
using the new browser technologies in comparison with the classic
widget kits; Will looks equally (non :-) ) native under both KDE and
Gnome or even (parts of) as a fp.o page.
If it managed to be concept-proved on .specs (based solely on grammars
and queries) may be will be possible to be reused for kikstarts and
systemd units too (e.g. other basic Fedora artifacts)?
This sounds like fun project for GSoC. Have you considered to propose
this idea [1]? Of course there is OBS which does some of this already.
Vít
[1] http://fedoraproject.org/wiki/Summer_coding_ideas_for_2014
Kind regards,
Alek
[1] https://lists.fedoraproject.org/pipermail/devel/2013-May/183195.html
_______________________________________________
env-and-stacks mailing list
env-and-stacks(a)lists.fedoraproject.org
https://lists.fedoraproject.org/mailman/listinfo/env-and-stacks
7:01 a.m.
On Mon, 2014-03-03 at 12:16 +0100, Honza Horak wrote:
I can also see another cases:
3) introducing a new package under a different name --say we want to
prepare a new un-stable/dirty version of a package foo, which is already
in Fedora and we'd like to introduce it in Playground (which would mean
the package foo would be updated for every user who has enabled
Playground). If we introduce the new package under featurex-foo or
userx-foo, we can safely add it into Playground.
I agree with that.
I also agree with what Alek Paunov wrote, that this could be extended to
providing old/compat packages of some software.
4) We have a stack of packages that I want to deliver to Fedora
users,
but the stack would update some packages from Fedora base repo and/or we
do not want to use SCLs. Then we can get a Copr repository as a RPM
package and include this RPM in the Playground, so people installing
this RPM package would actually say: "Yes, I want to enable these
packages and I agree to get some of my Fedora-base packages updated".
Well, this is certainly a creative idea, but I currently have mixed
feelings about it. What's the gain in creating a RPM package with
the .repo file and somehow telling the user what will happen (e.g. "Be
warned, some Fedora packages from the main repo will get updated"),
compared to just pointing users at a COPR repo with the appropriate
description on its web site?
Tadej
8:02 a.m.
On 03/04/2014 02:01 PM, Tadej Janež wrote:
On Mon, 2014-03-03 at 12:16 +0100, Honza Horak wrote:
>
> I can also see another cases:
>
> 3) introducing a new package under a different name --say we want to
> prepare a new un-stable/dirty version of a package foo, which is already
> in Fedora and we'd like to introduce it in Playground (which would mean
> the package foo would be updated for every user who has enabled
> Playground). If we introduce the new package under featurex-foo or
> userx-foo, we can safely add it into Playground.
I agree with that.
I also agree with what Alek Paunov wrote, that this could be extended to
providing old/compat packages of some software.
> 4) We have a stack of packages that I want to deliver to Fedora users,
> but the stack would update some packages from Fedora base repo and/or we
> do not want to use SCLs. Then we can get a Copr repository as a RPM
> package and include this RPM in the Playground, so people installing
> this RPM package would actually say: "Yes, I want to enable these
> packages and I agree to get some of my Fedora-base packages updated".
Well, this is certainly a creative idea, but I currently have mixed
feelings about it. What's the gain in creating a RPM package with
the .repo file and somehow telling the user what will happen (e.g. "Be
warned, some Fedora packages from the main repo will get updated"),
compared to just pointing users at a COPR repo with the appropriate
description on its web site?
Right, I don't remember which use case I had on my mind with the 4th
point, so let's just stay with the 1, 2 and 3 ;)
Honza
1:10 p.m.
On 04.03.2014 16:02, Honza Horak wrote:
On 03/04/2014 02:01 PM, Tadej Janež wrote:
> On Mon, 2014-03-03 at 12:16 +0100, Honza Horak wrote:
>> 4) We have a stack of packages that I want to deliver to Fedora users,
>> but the stack would update some packages from Fedora base repo and/or we
>> do not want to use SCLs. Then we can get a Copr repository as a RPM
>> package and include this RPM in the Playground, so people installing
>> this RPM package would actually say: "Yes, I want to enable these
>> packages and I agree to get some of my Fedora-base packages updated".
>
> Well, this is certainly a creative idea, but I currently have mixed
> feelings about it. What's the gain in creating a RPM package with
> the .repo file and somehow telling the user what will happen (e.g. "Be
> warned, some Fedora packages from the main repo will get updated"),
> compared to just pointing users at a COPR repo with the appropriate
> description on its web site?
Right, I don't remember which use case I had on my mind with the 4th
point, so let's just stay with the 1, 2 and 3 ;)
I think, I have a real use case: Samba AD - The AD functionality is
disabled in Fedora proper, due to the incompatibility between the
bundled (heimdal) and system MIT Kerberos implementations.
The incompatibility is dangerous in the general case, but is harmless
when e.g. Samba will be deployed as a single server in container or
dedicated instance. OTOH, AD functionality is very good selling point
:-). Possible solution: Samba with enabled AD in COPR, reviewed Samba AD
.repo package in Playground.
Why in the Playground? - Discoverability. How otherwise the user will
find that given COPR? How to choose between several alternative COPRs?
Yes, we do not have UX centric package searching tools (possibly except
apps.fp.o/packages up to some degree), but we have amounts of priceless
data - the rest is a matter of reasonable platforms and work and will be
here someday :-)
I think we could generalize - .repo in the Playground - 2-steps
(enabling playground + installing the .repo) easy mechanism to change
the sane defaults of the system for these who know what they doing or
just want to experiment.
Kind regards,
Alek
1:04 p.m.
On Wed, Feb 26, 2014 at 04:40:40PM +0100, Marcela Mašláňová wrote:
Thanks for the draft. I left comments to some points, but I'd
rather
discuss it on next meeting, but because you probably won't be
there...
My opinions on Open Questions:
* signing - sure we need to sign (copr requirement)
Okay, so is this a blocker for this repository? (Necessary) or (Very nice to
have)?
* I would prefer rolling updates and no testing repository. It's
Playground, bugs can be there.
I would prefer rolling release as well. One clarification, by this we mean
there will be a Playground yum repo per Fedora release-arch. Within each of
those repos, we'll have rolling updates. Correct?
* I don't know what's mirrormanager. Mirroring to all Fedora
mirrors?
I guess we don't need it at start.
Basically, yes. mirrormanager helps our mirrors coordinate where to get the
bits (only a few mirror directly from us. the others mirror from each
other. So they need to know that the one they're mirroring from will have
the bits they need.) mirrormanager needs to be configured with each
repository that we want mirrored as not all mirrors will mirror all packages
(for instance, few mirrors want the obsolete fedora releases that are on the
archives server).
So let's add mirroring in general as Optional. coordinate with infra
* self hosting - no, I guess we don't have to ship BuildRequires
in
Playground repo. It can do shipping of some packages easier.
I would vote the opposite. self-hosting has been a fundamental guarantee of
Fedora for a long time and even in the playground repo I wouldn't break
that. (For those who might not know the term it means: The Fedora release
repo + Fedora updates repo + playground repo should contain all the packages
needed to build any package in the Playground repo).
* no reviews! It should be quick and easy. Maybe someone else than
owner of copr repo should approve new projects, which will go into
Playground. Maybe cla+1 could mean automatic push into Playground if
user click on button Playground.
I'd like to go the no review route but... some other policies like conflicts
and replacement of packages might need it... I think I'd defer this until
after we decide what policies we are going to have for the packages in the
repo.
-Toshio
7 a.m.
On 02/26/2014 08:04 PM, Toshio Kuratomi wrote:
On Wed, Feb 26, 2014 at 04:40:40PM +0100, Marcela Mašláňová wrote:
> Thanks for the draft. I left comments to some points, but I'd rather
> discuss it on next meeting, but because you probably won't be
> there...
>
> My opinions on Open Questions:
> * signing - sure we need to sign (copr requirement)
>
Okay, so is this a blocker for this repository? (Necessary) or (Very nice to
have)?
Again, I don't how signing work. Mirek was discussing signing some time
ago. Couldn't we sign only packages, which will make it into the
repository? They don't have to be signed by copr, don't they?
> * I would prefer rolling updates and no testing repository.
It's
> Playground, bugs can be there.
I would prefer rolling release as well. One clarification, by this we mean
there will be a Playground yum repo per Fedora release-arch. Within each of
those repos, we'll have rolling updates. Correct?
Um, we probably need repo per Fedora release.
> * I don't know what's mirrormanager. Mirroring to all Fedora mirrors?
> I guess we don't need it at start.
Basically, yes. mirrormanager helps our mirrors coordinate where to get the
bits (only a few mirror directly from us. the others mirror from each
other. So they need to know that the one they're mirroring from will have
the bits they need.) mirrormanager needs to be configured with each
repository that we want mirrored as not all mirrors will mirror all packages
(for instance, few mirrors want the obsolete fedora releases that are on the
archives server).
So let's add mirroring in general as Optional. coordinate with infra
Agreed.
> * self hosting - no, I guess we don't have to ship
BuildRequires in
> Playground repo. It can do shipping of some packages easier.
I would vote the opposite. self-hosting has been a fundamental guarantee of
Fedora for a long time and even in the playground repo I wouldn't break
that. (For those who might not know the term it means: The Fedora release
repo + Fedora updates repo + playground repo should contain all the packages
needed to build any package in the Playground repo).
Packaging some dependencies might take a lot of time. I can't think
about good example now, but I remember Big Data SIG didn't want to
maintain Scala, but they depend on it.
> * no reviews! It should be quick and easy. Maybe someone else
than
> owner of copr repo should approve new projects, which will go into
> Playground. Maybe cla+1 could mean automatic push into Playground if
> user click on button Playground.
>
I'd like to go the no review route but... some other policies like conflicts
and replacement of packages might need it... I think I'd defer this until
after we decide what policies we are going to have for the packages in the
repo.
-Toshio
Policies should be easy to check manually, so we don't have a another
huge pile of unfinished reviews.
I concur we need to define policies first.
Marcela
8:31 a.m.
On 02/27/2014 02:00 PM, Marcela Mašláňová wrote:
Again, I don't how signing work. Mirek was discussing signing
some time ago. Couldn't we sign only packages, which will
make it into the repository? They don't have to be signed by copr, don't they?
Signing in Copr would means to create another instance of Sigul for Copr, which mean some
HW, update code (e.g. rebase
to pgp2), integrate it. That is dozen of weeks of work.
Or you can download the repo and sign pkgs manually. Which is one hour of work, but it is
occurring event.
Choose what you like more and for what you have resources :)
--
Miroslav Suchy, RHCE, RHCDS
Red Hat, Senior Software Engineer, #brno, #devexp, #fedora-buildsys
7:20 a.m.
On Thu, 2014-02-27 at 14:00 +0100, Marcela Mašláňová wrote:
On 02/26/2014 08:04 PM, Toshio Kuratomi wrote:
>> * signing - sure we need to sign (copr requirement)
>>
> Okay, so is this a blocker for this repository? (Necessary) or (Very nice to
> have)?
I think we would all agree that signed packages bring many benefits and
it would be very nice to have the packages signed. I'm not sure whether
it should be a mandatory requirement of the Playground repo or not.
Couldn't we sign only packages, which will make it into the
repository?
They don't have to be signed by copr, don't they?
I agree that this is a separate thing from COPR. We'll need a service
that will do the gating / policy enforcement and then feeding the
packages to the Playground repo anyway. The signing could be a part of
this service.
Or do you think we could live without this service and somehow implement
things into COPR + semi-automatically populate (and sign) the Playground
repo?
Also, should we estimate the development time needed by the needs we
will identify for this repo (e.g. how long it will take to develop the
signing with sigul, 'build from a git repo url and revision hash'
feature in COPR, etc.) so we can see what should go into the "minimal
viable product"?
>> * I would prefer rolling updates and no testing repository.
It's
>> Playground, bugs can be there.
>
> I would prefer rolling release as well. One clarification, by this we mean
> there will be a Playground yum repo per Fedora release-arch. Within each of
> those repos, we'll have rolling updates. Correct?
+1.
> I would vote the opposite. self-hosting has been a fundamental
guarantee of
> Fedora for a long time and even in the playground repo I wouldn't break
> that. (For those who might not know the term it means: The Fedora release
> repo + Fedora updates repo + playground repo should contain all the packages
> needed to build any package in the Playground repo).
>
Packaging some dependencies might take a lot of time. I can't think
about good example now, but I remember Big Data SIG didn't want to
maintain Scala, but they depend on it.
I agree with Toshio here.
The argument that some dependencies might take a lot of time to package
could be mitigated by the fact that the packaging guidelines for the
Playgroud repo will be greatly simplified compared to the current FPG.
Hence, it will be easier to package up all the dependencies.
Also, since library bundling will be allowed, the packager could at
first just bundle all the dependencies in the package of interest and
later, if it would be practical, separate them out into independent
packages.
Tadej
2:04 a.m.
On 03/02/2014 02:20 PM, Tadej Janež wrote:
Also, should we estimate the development time needed by the needs we
will identify for this repo (e.g. how long it will take to develop the
signing with sigul, 'build from a git repo url and revision hash'
feature in COPR, etc.) so we can see what should go into the "minimal
viable product"?
I estimate it to 4 months.
--
Miroslav Suchy, RHCE, RHCDS
Red Hat, Senior Software Engineer, #brno, #devexp, #fedora-buildsys
9:11 a.m.
On Tue 25 Feb 2014 07:23:24 PM CET Toshio Kuratomi wrote:
Okay, I started a requirements document for the playground
repository:
https://fedoraproject.org/wiki/Env_and_Stacks/Playground_repository_%28dr...
There's three things that we need to do with this to make it useful for FESCo:
1) Add other things we need to decide on to the Open Questions. We
especially need things that will affect the work needed to implement
the repository but we can decide which things those are later.
I added another question which needs to be answered IMO:
How do we deal with multiple versions of same package provided by different coprs?
This wouldn't be a problem if we had structure similar to coprs where
people just enable 1 repo/feature. We could just say "these two features
are XOR, you can't have both". But if we mash all these coprs together
there will be clashes IMO.
What we probably need is make consumption of a lot of playground repos
From copr easy so that people can pick and choose. For example:
"I want new Gnome, but that doesn't mean I want new XYZ as well"
If we mash everything into one big repo, above will be hard(er) to do
with yum. Once you enable repo you'd have to manually enable/disable
various rpms and who knows how that'd turn out...
--
Stanislav Ochotnicky <sochotnicky(a)redhat.com>
Software Engineer - Developer Experience
PGP: 7B087241
Red Hat Inc. http://cz.redhat.com
6:33 a.m.
On 02/25/2014 07:23 PM, Toshio Kuratomi wrote:
Okay, I started a requirements document for the playground
repository:
https://fedoraproject.org/wiki/Env_and_Stacks/Playground_repository_%28dr...
There's three things that we need to do with this to make it useful for FESCo:
1) Add other things we need to decide on to the Open Questions. We
especially need things that will affect the work needed to implement
the repository but we can decide which things those are later.
2) Decide which features from the Open Questions we want to apply to
the Playground repository. Update the description section as we make
decisions.
3) Analyze what will be needed to implement the features we've decided
the Playground repository needs to have and fill in the Identified
Needs sections with that information.
-Toshio
_______________________________________________
env-and-stacks mailing list
env-and-stacks(a)lists.fedoraproject.org
https://lists.fedoraproject.org/mailman/listinfo/env-and-stacks
We need to create Change proposal for additional repository as soon as
we have some basic rules. Already started rumours the repository will
contain even proprietary software, so I've added "no bad licenses, no
proprietary software, no patented software" on top of the page ;-)
Very early Change draft is here:
https://fedoraproject.org/wiki/Env_and_Stacks/Changes_Drafts/Playground_r...
We can fill it when we have more information.
Marcela
3711
days inactive
3719
days old
env-and-stacks@lists.fedoraproject.org
24 comments
9 participants
participants (9)
-
Alek Paunov -
Honza Horak -
Jaroslav Reznik -
Marcela Mašláňová -
Miroslav Suchý -
Stanislav Ochotnicky -
Tadej Janež -
Toshio Kuratomi -
Vít Ondruch