Learn more about these different git repos.
Other Git URLs
I would prefer SCL packages in branches of the main package (eg ruby). We used the same approach in some internal projects and it worked well with koji, composes, everything...
I suggest name of branches:
scl-f21
scl-f22
The branch names will need to include the name of the scl and the name of the fedora release they're being built for since different scls will need to have different files in the minimal buildroot. We could use something like:
{{{ fdr-ruby1.9.3-f21 fdr-ruby1.9.3-f22 fdr-ruby2.0-f21 fdr-ruby2.0-f22 }}}
What is "fdr-" in those suggested branch names? If it's short for Fedora, it seems weird and redundant. The disttag at the end already implies Fedora, and which version of Fedora.
we are going to have to use different tags and targets as the minimal buildroot contents will have to be different. fedpkg uses <gitbranch>-candidate for the target. so the git branches will have to match the target name we will need a different -build tag that has different group packages to meet the needs for building scls. as to if its done via a different branch in an existing repo or a new repo releng has no strong preference. either way you will need pkgdb work to support scls and teh different branches. assuming we tag the resulting packages into the standard tags there should be no need for work on bodhi for updates. there may be work if we want to push out scls in their own repos.
so I'm envisioning: {{{ f21-scl-ruby193 git branch in some repo f21-scl-ruby193-build tag inheriting from f21-override f21-scl-ruby193-candidate target that tags resulting builds into f21 (when bodhi is enabled builds will go to f21-update-candidate) }}} as to what repo is used, I will go with the FPC recommendation.
we will need to work with pkgdb devs on whats needed to support branches for scls.
ausil's proposal looks good. We were using something similar in the past.
fdr is from the scl name. It does stand for the vendor in that context but it's not direct. Since all the scls should be provided by fedora we could likely remove it.
ausil's proposal of branch names looks good too.
If we do this as a branch rather than a new repository, how do we ensure that SCL packages are reviewed before they are built?
I thought collection will be a feature for Fedora not a new review. I don't see as much probable that people will prepare review for normal package and than go through the process again for scl package. We already have a problem with long queue of reviews without reviewer and this won't improve it.
Maybe we don't understand each other. The situation is same like Fedora review for new package, which can have also branches for EPEL and there is also no new review needed. I think scl is in the same category. There are needed some changes, but nothing big, which needs new review.
If package is going only into scl, and it wasn't in Fedora before, then there should be a review.
No, SCLs are more like mingw packages which do get a new review. Each SCL package will need a new review in order to get into Fedora.
Replying to [comment:10 toshio]:
Can we perhaps plan a FAD in order to expedite that review?
Replying to [comment:11 mattdm]:
Replying to [comment:10 toshio]: No, SCLs are more like mingw packages which do get a new review. Each SCL package will need a new review in order to get into Fedora. Can we perhaps plan a FAD in order to expedite that review?
My understanding is that, in many cases, a SCL version of an existing package can be created with simple changes. Here is an example from the documentation:
http://docs.fedoraproject.org/en-US/Fedora_Contributor_Documentation/1/html/Software_Collections_Guide/sect-Converting_a_Conventional_Spec_File.html
I don't think the effort of a full review for such changes is worthwhile, and seems needlessly onerous on the developer. It makes more sense that, as long as changes are limited to those like the ones that appear in the docs, a minimal review of the spec patch should suffice. Doing laborious checks for license, checksums, and many other factors that don't change at all isn't a good use of contributor time.
In https://fedorahosted.org/fesco/ticket/812 (where an exception to re-review was granted for a mingw rename), Kevin notes that the reasoning for re-review is that people often screw up provides:/obsoletes: for the new packages. Toshio, is that the concern here? (Maybe we should branch this into a FESCo ticket?)
So the approval process and early lifetime of an SCL will look like this:
In cases where the SCL package differs only trivially from the non-SCL (so not the metapackage, but the essential component packages), why not have a reduced review of some sort? Also, apologies (and send pointers) if this is going OT for the ticket.
@mattdm: A FAD is a fine idea. There have been FADs for packaging of many sets of packages. (The CMS that docs was looking at using, the Merge Review FAD that dgilmore is presently looking at doing, etc).
The re-review for rename is a good example. You can take it as a lower boundary on changes that require a new review. (there could be an even lower boundary -- but none has ever been presented to fesco). There are many more changes needed to create an scl version of a package than the changes to create a package rename. More of those changes are totally new to the package maintainer (for a rename, the only change that they likely haven't encountered before is the Obsoletes/Provides additions. For SCLs, there are many things not encountered outside of SCL packaging. For example, Addition of %scl_prefix, filtering of autoprovides and autorequires, manual specification of dependencies on things that rpm autodeps would pick up in a non-scl package, changes to the install dir macros and when to use the %root*dir macros instead of the scl overridden ones.)
The effect of failure is also slightly higher here than in the rename case. When a package rename does obsoletes and provides wrong it generally means that the renamed package fails to remove the pre-rename version of that package. In many cases, the end users' systems continue to function in that case but the package in question stays at the old version until someone realizes the provides and obsoletes need to be adjusted. For SCLs, getting things wrong means that the SCL could replace a system package or a system package could replace an SCL. Either one will lead to breakage of apps which depend on the other version of that package.
Other examples that we could take a look at in increasing order of difference from the already reviewed package are:
As for fesco ticket -- I'm not sure -- it's in the grey area between FPC and FESCo. I think it's probably a "what to package" question rather than a "how to package" question so it probably belongs to fesco. However, FPC has been assuming that the packages would undergo new package review as normal (we've talked about which things in the guidelines would belong with reviewing of the SCL for approval vs which things would belong in the review of the packages themselves) so we might want to have a recommendation from the FPC. From previous discussions close to the topic, though, I think they're likely to recommend that the packages undergo new package review.
@pfrields: Having created SCLs, the differences between the non-SCL and the SCL packages are non-trivial and prone to errors. Someone fluent in creating non-SCL packages will have to learn a large amount of new information in order to create a proper SCL. Two separate python modules have spec files that are more similar than an SCL and non-SCL version of the same and the knowledge that applies to one python module will carry over to the other python module whereas the knowledge of how to create an SCL is in addition to the knowledge needed to create the python module.
The license, checksums, and other factors do change as well. Just last month people on devel list were complaining that packages don't get reviewed once they are built. New upstream releases are just as likely to introduce changes that break licensing, require new dependencies, For SCLs we're very deliberately shipping separate upstream versions of software to our users. Different build dependencies, different build flags, different included files, different installed files, or even different build scripts will come into play with these different versions. Since we already need to review the packages for the changes that being an SCL introduces, we will also be able to review to catch these issues as well.
The example SCL in the documentation is a simplistic case (it's also wrong. The less.sh and less.csh files are configuring bash, not less. Therefore they have to be renamed and placed in %{_root_sysconfdir}/profile.d/ rather than in the SCL's private %{_sysconfdir}. The example also doesn't make clear that the code inside of less.sh and less.csh has to be modified from the non-SCL package [If you take a look at /etc/profile.d/less.sh on your system, you'll see that it hardcodes /usr/bin/lesspipe.sh and sets an env variable. The SCL version would need to detect the lesspipe from the SCL. There would have to be some thought put into how to handle the env variable. Perhaps, the upstream code would have to be patched to use a different env var. Perhaps the env var could be set to lesspipe without a full path (so that if the user scl enabled the less SCL then they would get the SCL lesspipe, otherwise they would get the non-scl lesspipe) See why SCL packages should get reviewed? ;-) Here's a diff between an scl and non-scl version of python2.4 to show some of the other issues that could arise with SCLs: http://toshio.fedorapeople.org/scls/python-scl.diff
Re: reduced review. That's a bad idea for SCLs since they are pretty high on the complexity scale.
Replying to [comment:18 toshio]:
How about: "review focused on the changes"?
I hear what you're saying about packages not being re-reviewed enough, but couldn't that be kept as a separate issue?
We need it anyways because the SCL is targetting a different version than the mainstream package.
And really... reviews should not be the bottleneck here. Reviews just need two people who care about the package. For getting SCLs that solve real-world problems (I have an old rails app that I don't want to port, etc) into Fedora that shouldn't be a problem. The reason we have a long queue of packages is because there are a great many niche packages out there that the package submitter cares about but no one else.
We'll likely have more of an issue with bugs that get missed during review and we aren't able to get fixed afterwards (some bugs because of fear of breaking compat guarantees. Other bugs because fixing bugs in packaging that aren't breaking your own packages but are breaking other people's is never as high priority.)
What about using step 4 (the metapackage is approved via the new package process) to decide if (all) packages should go through the re-review or not? It would be pretty nice compromise. With some strict rules like packages never packaged in Fedora has to go though the review same way as non-SCL ones. But if the only change is SCL-ization of package, reviewed a few months ago - there's probably no need to go through the full review or just a subset of packages would be required to go through review (big changes). With help of GIT, it could be pretty easy for metapackage reviewer to see scope of changes.
Otherwise back to the topics - I think the proposal by Dennis makes sense. Has anyone already contacted Pkdb guys? Marcela? If not, I can do it.
@toshio: Thanks for the extra information. This makes it clearer to me why reviews aren't as cut and dried as I previously thought for SCLs. Sorry to steer the ticket away. I'll work with @mattdm to figure out how we can help with organization of any backlog of reviews needed.
@jreznik Yes, I like Denis proposal of name of branches. No, I didn't speak to pkgdb, and I'm not exactly sure what should I ask. Can you do it?
@jreznik: there's a couple reasons that doesn't work. (1) The set of packages within the SCL is open ended. A contributor who was not necessarily part of the initial proposal for the SCL can add packages to it several releases later. So there's no way to decide whether the changes to those unknown packages should be reviewed or not. (2) If you're trying to decide that the changes to a package are trivial enough that you don't have to review it, you have to have the completed spec file for that package in order to evaluate that. If we make metapackage approval hinge on doing that evaluation we're creating a bottleneck for the metapackage that didn't exist before.
@all: I think there's also a general thought here that we can evaluate a diff between the mainstream package and the scl version of the package and then we'll know whether the package is ready or not. This is false. We have to also evaluate the things that have not changed because there's a very real chance that those things need to be adapted for an SCL environment. Just for example, we have to make sure that all of the Provides in the package have been namespaced. We have to make sure that the Requires and BuildRequires that reference other SCL packages have been adapted so they aren't getting the mainstream packages instead. We have to check that files have been moved to their correct locations. We have to check that paths inside of binaries, config files, and scripts reference the correct locations.... Catching these requires checking things that the packager did not change for correctness.
@toshio: I agree with you that there are things worth checking even if we do not change spec file -- Provides, Requires, file locations. But I don't think we need to check the other stuff that has already been checked during initial package review (license, bundling, conformity to Guidelines) -- in case we do not do it for non-SCL packages when we do rebase, build for epel, etc.
And checks like Provides, Requires and file locations can be done automatically. So what I'd like to see is some AutoQA-like check that would be performed in Bodhi.
@hhorak: But we do do it for non-SCL packages. In comment 17 I listed some of these: package renames, parallel installable packages, mingw packages, and forks. I kind of hinted at this but to make it explicit: deciding to relax the review requirement for all of these types of packages might be a way forward. I'm not sure I would support it but I'd be more likely to than to support something that solely targets SCLs and leaves these other packages that have the same criteria out.
We might be able to do Provides checking automatically but we would not be able to do Requires or file location automatically. SCLs need to Require both things within the SCL's namespace and things in the general package namespace. SCLs need to place some files in SCL directories and others in the general file system namespace (files that add configuration to an external service, for instance.) In terms of doing things automatically, I do not want to bottleneck SCLs on having a working autoqa that can check these things in order to get SCLs into the distro. It seems better to take the same direction here as with other packages: People manually review these items. Once an autoqa check is written and deployed we decide that manual review of that item is no longer needed. That way we can proceed independently of autoqa's deployment and optimize once it's available.
@toshio: I'm totally fine with manual -> automatic transition period. More comments in-line:
Replying to [comment:28 toshio]:
SCLs need to Require both things within the SCL's namespace and things in the general package namespace.
Right, but as soon as the requirements are sane (there are no requirements on non-existing symbols), we should be fine. I still think this can be checked by a script (or by trying to install the packages manually in case of human reviewer).
SCLs need to place some files in SCL directories and others in the general file system namespace (files that add configuration to an external service, for instance.)
I know about cases like that, but there are not many of them, so we should rather white-list those -- not only for making it easily script-able (rpmlint already has a module for SCL, so the white-list can be used there as well) but also to limit spoiling the main root. What is more, all such filenames outside of sclroot need to include the collection name anyway, so again -- it should be possible to check it automatically (some day).
Replying to [comment:29 hhorak]:
@toshio: I'm totally fine with manual -> automatic transition period. More comments in-line: Replying to [comment:28 toshio]: SCLs need to Require both things within the SCL's namespace and things in the general package namespace. Right, but as soon as the requirements are sane (there are no requirements on non-existing symbols), we should be fine. I still think this can be checked by a script (or by trying to install the packages manually in case of human reviewer).
That doesn't cover the cases: (1) not all autodeps are based around elf symbols. perl and ruby have autodep generators now. (2) all symbols can be provided but you can still not have what you actually want. For instance, an API might be compatible enough to provide the symbols the program needs but a wire protocol or file format that the library creates is not compatible.
What is more, all such filenames outside of sclroot need to include the collection name anyway, so again -- it should be possible to check it automatically (some day).
Including collection name in part of the filepath is a good point. You might be able to craft something that works in all cases with that.
Even though we're slowly approaching some compromise, we've got quite a lot out from the original issue, which was the way how branches will be done. Can we agree with having some limited review that will be done manually for start and will be able to be done automatically in the future?
No. Counter proposal: Can we agree (1) that some sort of package review is necessary. (2) that we'll work to automate all types of package reviews (3) that we'll sort out whether certain types of packages can undergo less than a full review at a later time (4) that sorting that out doesn't block this ticket?
At the moment the last question is the only one that I have an outstanding question about. It still needs an answer to "how do we ensure that SCL packages are reviewed before they are built? " from comment:7
I would hate to spend more time arguing about whether we need reviews than just doing the reviews would take. :)
I'm volunteering to help coordinate a review day, including finding people from outside of the SCL team to do a good portion of the work.
@mattdm - thanks!
@all - If anyone is going to press forward with a plan to revamp what needs to be reviewed, another class of packages that is also more trivial than this case and so should be included in the revamp is retired packages. Currently, unless a package is retired by mistake it goes through a full re-review. Previous FESCo decision was to require this even for packages which had been freshly retired (it came up in the context of the every-release-cycle-cleanup-of-packages).
@toshio, personally I'm ok with your counter proposal - and I agree it should not block this ticket - so let's move it to the right places (FPC, QA). Making reviews as easy as possible helps both Fedora main repos and SCLs.
@marcela, I'll take a look on pkgdb requirements.
Back to pkgdb, it was reassigned to pkgdb2 https://fedorahosted.org/pkgdb2/ticket/2#comment:1
Past few days I've had a comaintainer on a package committing SCL work destined for Copr into a "nightly" branch of the package. I've been getting commit email about it. I've told him to stop but he's said he wants it there because it's destined for copr. I think that having SCL packages in the same repo, just in a different branch is problematic for people mentally. They're thinking of the SCL conceptually as the same package when it needs to be thought of as a different package. Taking mingw packages as a the model again:
Replying to [comment:38 toshio]:
Past few days I've had a comaintainer on a package committing SCL work destined for Copr into a "nightly" branch of the package. I've been getting commit email about it. I've told him to stop but he's said he wants it there because it's destined for copr. I think that having SCL packages in the same repo, just in a different branch is problematic for people mentally. They're thinking of the SCL conceptually as the same package when it needs to be thought of as a different package. Taking mingw packages as a the model again: the primary package maintainers do not see commit email for changes to the mingw package or bug reports. That's not the case if we only use a separate branch. the mingw package maintainer can opt-in or opt-out of getting commit and bug mail about the primary package if the packages have diverged. That's not the case here. (And should be more important here as the version of an SCL stays behind the main package whereas the mingw package attempts to keep up with the version in Fedora). mingw packages that have not been approved plainly do not belong in the Fedora git repo as they're an unreviewed package. That's apparently not clear with SCL as branch.
Could you point me to the package and commiter? I'm aware of commits for python nightly stuff, but that's not related to SCL at all.
I've seen many changes in specfiles, which I didn't like, it's not happening only with SCL. People just have different views about content of specs.
Replying to [comment:39 mmaslano]:
Replying to [comment:38 toshio]: Past few days I've had a comaintainer on a package committing SCL work destined for Copr into a "nightly" branch of the package. I've been getting commit email about it. I've told him to stop but he's said he wants it there because it's destined for copr. I think that having SCL packages in the same repo, just in a different branch is problematic for people mentally. They're thinking of the SCL conceptually as the same package when it needs to be thought of as a different package. Taking mingw packages as a the model again:
As I came up with the idea of doing Python nightly rebuilds in Copr, let me explain a bit:
the primary package maintainers do not see commit email for changes to the mingw package or bug reports. That's not the case if we only use a separate branch. the mingw package maintainer can opt-in or opt-out of getting commit and bug mail about the primary package if the packages have diverged. That's not the case here. (And should be more important here as the version of an SCL stays behind the main package whereas the mingw package attempts to keep up with the version in Fedora).
Not true, at least not for what we intend to do with Python nightly builds - we actually want to stay ahead of Fedora, ideally sync every day with upstream master branch.
mingw packages that have not been approved plainly do not belong in the Fedora git repo as they're an unreviewed package. That's apparently not clear with SCL as branch. Could you point me to the package and commiter? I'm aware of commits for python nightly stuff, but that's not related to SCL at all.
mingw packages that have not been approved plainly do not belong in the Fedora git repo as they're an unreviewed package. That's apparently not clear with SCL as branch.
I believe we're talking about python-setuptools and the commiter who did this was Miro Hroncok (a.k.a. churchyard). It's true that this branch uses SCL macros, but if/when we merge this back to Fedora, we won't actually build as SCLs.
I'd also like to add that I don't see why we couldn't use unofficial side branches in dist-git for this kind of work. It's not against any guidelines and it will be useful to both Fedora and Python community.
I'm also about to create topic branches to keep SCL spec for few packages and I still don't see anything wrong about that. Actually, I like that idea and it does make sense to me to use topic branches in that way.
The concerns about unwanted mails don't seem like an issue to me, since in most cases the primary package maintainers care about changes done to the SCL branch, or at least they don't care about some more mails. In the rest cases we have mailbox filters.
As for the content not suitable for Fedora -- that's actually purpose of the topic branches, that there is some content not suitable for Fedora yet. I see no problem here either.
Replying to [comment:41 hhorak]:
This would be the crux of the disagreement. In the past, the postiion has been content not suitable for Fedora does not belong in the Fedora pkgs git repo.
Replying to [comment:42 toshio]:
Replying to [comment:41 hhorak]: As for the content not suitable for Fedora -- that's actually purpose of the topic branches, that there is some content not suitable for Fedora yet. I see no problem here either. This would be the crux of the disagreement. In the past, the postiion has been content not suitable for Fedora does not belong in the Fedora pkgs git repo.
Really? I regularly used in the past special branches for development of RC releases, which I merged later. Nightly branches are for prototype of the Continuous Integration. See PRD of Env and Stacks WG, which you co-created https://fedoraproject.org/wiki/Env_and_Stacks/Product_Requirements_Document#Continuous_integration_.28CI.29
If you believe that nightly branches for Continuous Integration are wrong and shouldn't exist without explicit approval, then Env WG can write Change for F22 about it and ask FESCo. Usage of SCL in those branches is minor here. They are used because in this case it's easier to install nightly builds. Nigthly branches are all about Continuous Integration, which means attracting more developers because Fedora will support it and easier development of those components.
As was pointed above those nightly will be merged without SCL into the main branch.
What is unsuitable about the nightly branches? The only thing that I see might be problematic for someone are the SCL macros. It's true that guidelines say that there should be a comment on top of the specfile about this [1], but the SCL macros can actually be present in the specfile, if they're turned of in official builds. If you want us to add the comment, just say so - otherwise I don't see anything unsuitable in the nightly branches.
[1] https://fedoraproject.org/wiki/Packaging:Guidelines#Software_Collection_Macros
@bkarbrda: If you want to do nightly rebuilds of fedora packages in coprs, then do nightly rebuilds of fedora packages in coprs. However, that is not what we're looking at here. Here we're looking at doing builds in coprs of unapproved packages and storing the sources for those in the Fedora package git repo. That's not a clean way of doing things. Might as well give orion comaintainership of the python3 package so that he can work on the python3.4 package for EPEL in the existing git tree. And the mingw packages, and so on.
Replying to [comment:44 bkabrda]:
What is unsuitable about the nightly branches? The only thing that I see might be problematic for someone are the SCL macros. It's true that guidelines say that there should be a comment on top of the specfile about this [1], but the SCL macros can actually be present in the specfile, if they're turned of in official builds. If you want us to add the comment, just say so - otherwise I don't see anything unsuitable in the nightly branches. [1] https://fedoraproject.org/wiki/Packaging:Guidelines#Software_Collection_Macros
As part of the FPC discussion of making SCLs official and this ticket, the decision has been made that SCL macros are not allowed in the mainstream spec files.
Replying to [comment:46 toshio]:
Replying to [comment:44 bkabrda]: What is unsuitable about the nightly branches? The only thing that I see might be problematic for someone are the SCL macros. It's true that guidelines say that there should be a comment on top of the specfile about this [1], but the SCL macros can actually be present in the specfile, if they're turned of in official builds. If you want us to add the comment, just say so - otherwise I don't see anything unsuitable in the nightly branches. [1] https://fedoraproject.org/wiki/Packaging:Guidelines#Software_Collection_Macros As part of the FPC discussion of making SCLs official and this ticket, the decision has been made that SCL macros are not allowed in the mainstream spec files.
Nightly branch is not mainstream. Are you against continuous integration project?
When has this decision been made and where is it in guidelines? AFAIK it is customary to write specfiles according to current guidelines and when new guidelines come in effect, old-style specfiles are "grandfathered" (I believe that is the term for "they don't need to be touched assuming they still work"). At the time the python-nightly branches were created I didn't see (and I still don't see) any part of guidelines that they'd break. Therefore I don't see why I should remove them.
Also, as a reply to comment 45: - "Here we're looking at doing builds in coprs of unapproved packages" - unapproved in what sense? - "storing the sources for those in the Fedora package git repo" - no, we don't store sources anywhere, just downstream patches and specfiles - "That's not a clean way of doing things." - that's your opinion, not a fact. In my opinion, it is a clear way, since it allows us to keep variants of specfile of a single package in one git repo, therefore centralizing it's development and getting benefits from it (e.g. merging branches etc). - "Might as well give orion comaintainership of the python3 package so that he can work on the python3.4 package for EPEL in the existing git tree." - I don't see why I wouldn't. I explicitly announced that I myself won't build and maintain python3 for EPEL, but I also announced that I'll gladly leave this burden to anyone who will want it.
I just want to say that I had a previous e-mail discussion with Toshio about this. After an exchange of opinions, I asked him to express if he still is against it, I can move my nightly branch to some other repository on Github or such, although I consider it weird.
I didn't get any reply form him and now I see it is discussed here without my knowledge. I find that very unfair and I am sad that a fellow Fedora contributor acts behind my back instead of discussing first with me, or at least letting me know.
I find that very unfair and I am sad that a fellow Fedora contributor acts behind my back instead of discussing first with me, or at least letting me know.
You will probably want to check who opened that ticket, it is not who you seem to think.
Going one step back to sum it up a bit, I see a real demand for some git repo that would store bits that: are not intended directly for proper Fedora are legally OK for Fedora, but not OK technically in every aspect (i.e. what copr allows to build) * are usually used for building copr builds So we generally talk about a git repo for Copr. Thus, shouldn't we rather thing how to deliver this part of the infrastructure and accept current way (branches; sometimes already used) as a temporary solution until we have something better?
Replying to [comment:50 pingou]:
I find that very unfair and I am sad that a fellow Fedora contributor acts behind my back instead of discussing first with me, or at least letting me know. You will probably want to check who opened that ticket, it is not who you seem to think.
I was reacting on [comment:38 comment 38], following discussion and corresponding ticket https://fedorahosted.org/fesco/ticket/1321
I am well aware of who opened this ticket, but that has nothing to do with my shock and disappointment about this lack of communication from Toshio.
Replying to [comment:49 churchyard]:
I just want to say that I had a previous e-mail discussion with Toshio about this. After an exchange of opinions, I asked him to express if he still is against it, I can move my nightly branch to some other repository on Github or such, although I consider it weird. I didn't get any reply form him and now I see it is discussed here without my knowledge. I find that very unfair and I am sad that a fellow Fedora contributor acts behind my back instead of discussing first with me, or at least letting me know.
I'm sorry -- I did reply to you and did not receive a reply back -- just more commits of the same. That, in part, prompted me to escalate this to fesco.
If my reply didn't make it to you through spam filtering or some mailer daemon snafu somewhere else, I'm sorry for the escalating tension. Still, it's good that the base issue was decided upon at fesco so that we can move on from here.
Replying to [comment:48 bkabrda]:
Replying to [comment:46 toshio]: As part of the FPC discussion of making SCLs official and this ticket, the decision has been made that SCL macros are not allowed in the mainstream spec files. When has this decision been made and where is it in guidelines? AFAIK it is customary to write specfiles according to current guidelines and when new guidelines come in effect, old-style specfiles are "grandfathered" (I believe that is the term for "they don't need to be touched assuming they still work"). At the time the python-nightly branches were created I didn't see (and I still don't see) any part of guidelines that they'd break. Therefore I don't see why I should remove them.
FPC had discussed this and quickly decided that separation was going to be the foundation of the way SCLs would be managed in Fedora. Since you want it to be official, I made a draft and it was approved at last week's FPC meeting. Guidelines have been updated to reflect that.
Replying to [comment:54 toshio]:
I'm sorry -- I did reply to you and did not receive a reply back -- just more commits of the same. That, in part, prompted me to escalate this to fesco. If my reply didn't make it to you through spam filtering or some mailer daemon snafu somewhere else, I'm sorry for the escalating tension. Still, it's good that the base issue was decided upon at fesco so that we can move on from here.
I'm terribly sorry, that's my fault, I indeed found the mail form you saying you'd rather not get commit messages to the mail.
However I still feel quite unconformable when you discuss my actions on rel-eng and fesco tracs without my knowledge = without giving me the opportunity to defend my actions and argue.
Replying to [comment:55 toshio]:
Replying to [comment:48 bkabrda]: Replying to [comment:46 toshio]: As part of the FPC discussion of making SCLs official and this ticket, the decision has been made that SCL macros are not allowed in the mainstream spec files. When has this decision been made and where is it in guidelines? AFAIK it is customary to write specfiles according to current guidelines and when new guidelines come in effect, old-style specfiles are "grandfathered" (I believe that is the term for "they don't need to be touched assuming they still work"). At the time the python-nightly branches were created I didn't see (and I still don't see) any part of guidelines that they'd break. Therefore I don't see why I should remove them. FPC had discussed this and quickly decided that separation was going to be the foundation of the way SCLs would be managed in Fedora. Since you want it to be official, I made a draft and it was approved at last week's FPC meeting. Guidelines have been updated to reflect that.
What you're saying here is completely independent of what FPC voted on. Separation is IMO not fine, but given FPC (for reasons I can't see) decided that we have to go with separate repos, I'll live with that.
What puzzles me is how this affects putting/not putting SCL macros in mainline packages. I went through FPC meeting log and I can't see a single argument that would say why putting SCL macros in mainline packages is bad. On the other hand, using the macros in mainline packages has advantages, most importantly minimal diff between SCL and mainline package. This results in easier merging of changes/patches between the two. I'd really like FPC members to give their reasons for voting for that proposal. If I should move this discussion to a new/existing FPC ticket, please just say so.
Thanks.
Replying to [comment:4 ausil]:
as to what repo is used, I will go with the FPC recommendation. FPC voted last week on a recommendation:
as to what repo is used, I will go with the FPC recommendation.
FPC voted last week on a recommendation:
Recommend to releng to use separate git repos PASSED: (+1:5, 0:3, -1:0) SmootherFrOgZ did not vote.
https://fedorahosted.org/fpc/ticket/444
Replying to [comment:57 bkabrda]:
Replying to [comment:55 toshio]: Replying to [comment:48 bkabrda]: Replying to [comment:46 toshio]: As part of the FPC discussion of making SCLs official and this ticket, the decision has been made that SCL macros are not allowed in the mainstream spec files. When has this decision been made and where is it in guidelines? AFAIK it is customary to write specfiles according to current guidelines and when new guidelines come in effect, old-style specfiles are "grandfathered" (I believe that is the term for "they don't need to be touched assuming they still work"). At the time the python-nightly branches were created I didn't see (and I still don't see) any part of guidelines that they'd break. Therefore I don't see why I should remove them. FPC had discussed this and quickly decided that separation was going to be the foundation of the way SCLs would be managed in Fedora. Since you want it to be official, I made a draft and it was approved at last week's FPC meeting. Guidelines have been updated to reflect that. What you're saying here is completely independent of what FPC voted on.
What you're saying here is completely independent of what FPC voted on.
Incorrect. FPC took two votes on SCLs. The one approving separation was to approve this: https://fedoraproject.org/wiki/User:Toshio/SCL_Macros_Change
Separation is IMO not fine, but given FPC (for reasons I can't see) decided that we have to go with separate repos, I'll live with that. What puzzles me is how this affects putting/not putting SCL macros in mainline packages. I went through FPC meeting log and I can't see a single argument that would say why putting SCL macros in mainline packages is bad. On the other hand, using the macros in mainline packages has advantages, most importantly minimal diff between SCL and mainline package. This results in easier merging of changes/patches between the two. I'd really like FPC members to give their reasons for voting for that proposal. If I should move this discussion to a new/existing FPC ticket, please just say so.
Separation is IMO not fine, but given FPC (for reasons I can't see) decided that we have to go with separate repos, I'll live with that.
This has been discussed to death in FPC for months and months. I first raised this question here:
http://meetbot.fedoraproject.org/fedora-meeting-1/2013-10-31/fedora-meeting-1.2013-10-31-16.04.log.html
Whoever cares would need to check the SCL section from all of the meeting logs from that point forward to see the many reasons that FPC's thinking on the subject has solidified to this over time.
Replying to [comment:59 toshio]:
Replying to [comment:57 bkabrda]: Replying to [comment:55 toshio]: Replying to [comment:48 bkabrda]: Replying to [comment:46 toshio]: As part of the FPC discussion of making SCLs official and this ticket, the decision has been made that SCL macros are not allowed in the mainstream spec files. When has this decision been made and where is it in guidelines? AFAIK it is customary to write specfiles according to current guidelines and when new guidelines come in effect, old-style specfiles are "grandfathered" (I believe that is the term for "they don't need to be touched assuming they still work"). At the time the python-nightly branches were created I didn't see (and I still don't see) any part of guidelines that they'd break. Therefore I don't see why I should remove them. FPC had discussed this and quickly decided that separation was going to be the foundation of the way SCLs would be managed in Fedora. Since you want it to be official, I made a draft and it was approved at last week's FPC meeting. Guidelines have been updated to reflect that. What you're saying here is completely independent of what FPC voted on. Incorrect. FPC took two votes on SCLs. The one approving separation was to approve this: https://fedoraproject.org/wiki/User:Toshio/SCL_Macros_Change
I know that FPC took two votes on SCLs. What I'm saying is that how SCLs are going to be managed in Fedora is completely unrelated to whether one can or cannot keep SCL macros in specfiles for standard branches.
Separation is IMO not fine, but given FPC (for reasons I can't see) decided that we have to go with separate repos, I'll live with that. What puzzles me is how this affects putting/not putting SCL macros in mainline packages. I went through FPC meeting log and I can't see a single argument that would say why putting SCL macros in mainline packages is bad. On the other hand, using the macros in mainline packages has advantages, most importantly minimal diff between SCL and mainline package. This results in easier merging of changes/patches between the two. I'd really like FPC members to give their reasons for voting for that proposal. If I should move this discussion to a new/existing FPC ticket, please just say so. This has been discussed to death in FPC for months and months. I first raised this question here: http://meetbot.fedoraproject.org/fedora-meeting-1/2013-10-31/fedora-meeting-1.2013-10-31-16.04.log.html Whoever cares would need to check the SCL section from all of the meeting logs from that point forward to see the many reasons that FPC's thinking on the subject has solidified to this over time.
I checked a lot of them (not all, I admit) and I still see no reasoning behind the decision to prohibit putting SCL macros to mainline specfiles (which is different from actually building packages as SCL packages). Would you care to share the list of reasons here? It doesn't have to be full, but I'd really like to see why keeping the macros in mainline specfiles should be prohibited.
Replying to [comment:60 bkabrda]:
On the other hand, there indeed is a reason why SCL macros should be allowed in the mainline specfiles: code duplication -- having almost the same spec files on two different places means double effort when fixing things, resulting in non-consistent or outdated spec files.
Also, in cases where SCL and non-SCL maintainers wouldn't be same persons, the communication between them about back-porting fixes will consume another time, while having only one spec file would allow to work with much better efficiency.
We must try to make the live of maintainers easier, not the opposite.
I don't believe the reasoning for "not having SCL macros, which do nothing, in the mainline" may justify so much maintainers work more.
Replying to [comment:61 hhorak]:
Replying to [comment:60 bkabrda]: I checked a lot of them (not all, I admit) and I still see no reasoning behind the decision to prohibit putting SCL macros to mainline specfiles (which is different from actually building packages as SCL packages). Would you care to share the list of reasons here? It doesn't have to be full, but I'd really like to see why keeping the macros in mainline specfiles should be prohibited. On the other hand, there indeed is a reason why SCL macros should be allowed in the mainline specfiles: code duplication -- having almost the same spec files on two different places means double effort when fixing things, resulting in non-consistent or outdated spec files. Also, in cases where SCL and non-SCL maintainers wouldn't be same persons, the communication between them about back-porting fixes will consume another time, while having only one spec file would allow to work with much better efficiency. We must try to make the live of maintainers easier, not the opposite. I don't believe the reasoning for "not having SCL macros, which do nothing, in the mainline" may justify so much maintainers work more.
I never implied we should force anyone to put SCL macros in specfiles. I merely want to have the option, since I personally find it very practical. It makes marging patches easier, because most of the time, you're going to merge patches that are not SCL related, so having almost identical specfiles would help you. This would make maintainers lives easier.
Replying to [comment:62 bkabrda]:
Replying to [comment:61 hhorak]: Replying to [comment:60 bkabrda]: I checked a lot of them (not all, I admit) and I still see no reasoning behind the decision to prohibit putting SCL macros to mainline specfiles (which is different from actually building packages as SCL packages). Would you care to share the list of reasons here? It doesn't have to be full, but I'd really like to see why keeping the macros in mainline specfiles should be prohibited. On the other hand, there indeed is a reason why SCL macros should be allowed in the mainline specfiles: code duplication -- having almost the same spec files on two different places means double effort when fixing things, resulting in non-consistent or outdated spec files. Also, in cases where SCL and non-SCL maintainers wouldn't be same persons, the communication between them about back-porting fixes will consume another time, while having only one spec file would allow to work with much better efficiency. We must try to make the live of maintainers easier, not the opposite. I don't believe the reasoning for "not having SCL macros, which do nothing, in the mainline" may justify so much maintainers work more. I never implied we should force anyone to put SCL macros in specfiles. I merely want to have the option, since I personally find it very practical. It makes marging patches easier, because most of the time, you're going to merge patches that are not SCL related, so having almost identical specfiles would help you. This would make maintainers lives easier.
Please disregard my previous comment, I read "should not" instead of "should" and mixed it all up. +1 to what hhorak is saying :)
Are you really going to contest every single decision the FPC makes? And then wonder why it's taking so long?
You may disagree with a decision, you may argue your point at the meeting, on the ticket but here the question has been debated since last October. Can you agree to disagree and deal with the grief?
This is getting quite ridiculous. Not everyone agrees with the guidelines, but that's why we have guidelines so that we know what we should and must do. The FPC as a committee has taken a decision on what they believe is best for Fedora. You may disagree with it, you may want to do it differently elsewhere, but it would be nice to move on once a decision is made.
Replying to [comment:64 pingou]:
No, I certainly didn't contest every single one - or did I? In fact, I haven't contested any of FPC's decision for quite some time now.
You may disagree with a decision, you may argue your point at the meeting, on the ticket but here the question has been debated since last October. Can you agree to disagree and deal with the grief? This is getting quite ridiculous. Not everyone agrees with the guidelines, but that's why we have guidelines so that we know what we should and must do. The FPC as a committee has taken a decision on what they believe is best for Fedora. You may disagree with it, you may want to do it differently elsewhere, but it would be nice to move on once a decision is made.
This is not about my grief nor about agreeing on disagreeing, it's a matter of principle. We're seeking the optimal solution here. If FPC makes something harder for packagers and I see no good reason for it, I feel obliged to speak up.
I think this ticket is about "git branches vs git repo", which is really releng related.
Having 2 repo didn't forbid to cherry-pick between them.
The SCL macro is obviously something different, but which is absolutely out of topic here (for releng).
lets be sure to get this implemented by 23 Alpha
Metadata Update from @mmaslano: - Issue set to the milestone: Fedora 23 Alpha - Issue tagged with: planning
Since no one is working on this or has driven this in a long time, I am closing. Feel free to reopen or open a new issue if this becomes desired again
Metadata Update from @ausil: - Issue close_status updated to: Insufficient data - Issue status updated to: Closed (was: Open)
Login to comment on this ticket.