Re: Sponsor shortage
On 10.07.2015 15:43, Haïkel wrote: > 2015-07-10 15:31 GMT+02:00 Jonathan Underwood > mailto:jonathan.underw...@gmail.com>>: > > Hi, > > Today I happened to look at this page: > > http://fedoraproject.org/PackageReviewStatus/NEEDSPONSOR.html > > from which I can see we have potentially on the order of 100 new > potential contributors to Fedora whose efforts we're missing out on > due to a lack of sponsors. Some people seem to have been waiting to be > sponsored for a couple of years. This is quite an unfortunate > situation - what can we do to improve that situation? How many > *active* packaging sponsors do we currently have? > > > If someone had been waiting for that long, and tried to reached out on the > mailing-list or irc, then I'd like to hear you. > > I really advise people to start with smaller packages and/or reach out > the list > first because, we're having a more global shortage of reviewers. > > Moreover, people interested in comaintaining packages, especially *upstream* > maintainers should consider the comaintainership path. > > H. Hello, Thank you for touch this subject. I am waiting for sponsor from a few months, so far without success. I am reading mailing list, I am working on my project requested as feature request for make it better to review. I tried to help in one or two bugs. What else can I do? Thank you in advance for advise. Best regards. Marcin Haba > > > > Cheers, > Jonathan. > -- > devel mailing list > devel@lists.fedoraproject.org <mailto:devel@lists.fedoraproject.org> > https://admin.fedoraproject.org/mailman/listinfo/devel > Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct > > > > 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: Sponsor shortage
On 10.07.2015 16:10, Haïkel wrote: > I recommend you to start doing informal reviews and link them to your > own tickets. > By doing so, you'll be: > 1. showing your understanding/knowledge of RPM packaging/Fedora guidelines > 2. help reducing the workload => if applicants do good informal reviews, > I usually approve/finish them > AND that includes testing installation and that the package works ;) > > It should encourage a sponsor to sponsor you if you do so and do not > hesitate raising > attention on irc and the list! > > Even with people I work closely with, I insist into doing informal > reviews, as it's an action > of general interest. Show love to community, and it'll love you back ;) Hello, Thank you for recommendation and advises. I will try them. I think that these information could be more exposed, for example here: https://fedoraproject.org/wiki/Join_the_package_collection_maintainers Best regards. Marcin Haba > H. 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: Disk quota exceeded
On 23.07.2015 08:53, gil wrote: > hi > any ideas? > Konsole output > [gil@localhost SRPMS]$ scp jamm-0.3.1-1.fc22.src.rpm > fedorapeople.org:~/public_html/ > scp: /home/fedora/gil/public_html//jamm-0.3.1-1.fc22.src.rpm: Disk quota > exceeded > regards > gil Hello, Please look on first point here: http://fedoraproject.org/wiki/Infrastructure/fedorapeople.org#Common_Answers "Each Fedora contributor has 200 KiB (approximately 1954 MiB) of quota-controlled space." Probably you need to remove some files to take place for new upload to fedorapeople.org. Best regards. Marcin Haba (gani) 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
Question about profile.d scripts definition in Spec file
Hello, I am trying to make informal review following feature request: https://bugzilla.redhat.com/show_bug.cgi?id=1244353 One from warnings returned by rpmlint is: ossim-data.x86_64: W: non-conffile-in-etc /etc/profile.d/ossim.sh Because ossim.sh is not configuration file but shell script (as usual in profile.d/) I had a doubt about treating this warning. So I asked on fedora-review IRC channel and there I received answer that this warning is acceptable. In the bugzilla task I received answer that for the ossim.sh file should be used %config macro. My question is: what is valid answer for this case? Thanks in advance for your help. Best regards. Marcin Haba 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: Question about profile.d scripts definition in Spec file
On 02.08.2015 08:54, Ralf Corsepius wrote: > On 08/02/2015 08:39 AM, Marcin Haba wrote: >> Hello, >> >> I am trying to make informal review following feature request: >> >> https://bugzilla.redhat.com/show_bug.cgi?id=1244353 >> >> One from warnings returned by rpmlint is: >> >> ossim-data.x86_64: W: non-conffile-in-etc /etc/profile.d/ossim.sh >> >> Because ossim.sh is not configuration file but shell script (as usual in >> profile.d/) I had a doubt about treating this warning. > > Well, I sense a misinterpretation of "%config". > > In the context of the /etc file hierarchy "%config" means > "user-customizable", which means rpm/yum/dnf updates must not destroy > any changes a user may have applied and should backup instead. > >> So I asked on fedora-review IRC channel and there I received answer that >> this warning is acceptable. > Well, it's a minor issue, but it definitely is arguable. > >> In the bugzilla task I received answer that for the ossim.sh file should >> be used %config macro. >> >> My question is: what is valid answer for this case? > > My recommendation is to use %config. Hello Ralf, Thanks for your advise. I added the thread link to bugzilla ticket. If somebody has a different opinion in this matter, please answer in this thread. Best regards. Marcin Haba 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: Question about profile.d scripts definition in Spec file
On 02.08.2015 12:34, Michael Schwendt wrote: >> My question is: what is valid answer for this case? > > The explanation is given by "rpmlint -i …". > Hello, Not really. I read output from rpmlint and I am not sure if it is unambiguous for shell scripts placed in /etc location. Please look: ossim-data.x86_64: W: non-conffile-in-etc /etc/profile.d/ossim.sh A non-executable file in your package is being installed in /etc, but is not a configuration file. All non-executable files in /etc should be configuration files. Mark the file as %config in the spec file. Above rpmlint output text can be ambiguous because the 'executable' meaning may treat at least as: 1) have "execute" file permission 2) have "executable" scripting language code 3) ... others? In case 2) always can use interpreter to execute script. There is not need to mark "execute" permission on a file. It looks that exactly this situation we consider for profile.d/ scripts. Summary is that there are two meaning issues defined in these questions: A) if a shell script can be treated as configuration file? B) does in rpmlint aspect non-executable mean 'without execute permissions' or 'non-executable at all' (directly and by any interpreter) ? Since I known answer for this specific profile.d script (use %config macro), I have no longer doubt. Nevertheless the questions A) and B) still exist not answered for me, but I guess that it is subject to longer discussion and not here (off-topic). Best regards. Marcin Haba 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: Question about profile.d scripts definition in Spec file
On 02.08.2015 14:48, Michael Schwendt wrote: > On Sun, 2 Aug 2015 14:24:00 +0200, Marcin Haba wrote: > >>> The explanation is given by "rpmlint -i …". >>> >> >> Hello, >> >> Not really. I read output from rpmlint and I am not sure if it is >> unambiguous for shell scripts placed in /etc location. > > Well, it is the contents of the file that matter. The purpose of the > file, not the "type of file". You call them "shell scripts", but all > these files do, if sourced by the shell, is they alter the global > runtime _configuration_ by setting environment variables for a program > that may evaluate those variables. Hello Michael, Thanks for your comments. >> A) if a shell script can be treated as configuration file? > > Certainly. It's a cheap way to set a program's runtime configuration > instead of implementing a full config file loader/parser. My image of configuration files is that they are files for read/write purpose by design, because they enables _configure_ something (application, service, single program, script...whatever). If they are dedicated only for reading then from my point of view they lose "configuration" meaning (something like WORM storage ;-) ). > And don't forget, there is a difference between marking files as > %config and %config(noreplace). Yes, I remember about it. Thanks. >> B) does in rpmlint aspect non-executable mean 'without execute >> permissions' or 'non-executable at all' (directly and by any interpreter) ? > > It refers to the exec permission bit. Executables files in /etc being > marked as %config would be another mistake. If rpmlint refers 'non-executable' only to the exec permission, what I believe takes place, and the contents of the file that matter for determine 'executable/non-executable' type, it means that rpmlint search 'executable' property not there where it should search. Partially I understand this searching for executable files because it might be difficult clearly qualify some file to some specific type of files basing on a file content or just interpreter definition. However I believe that exist some tools or libraries that can do this content analyze for rpmlint. > It's some sort of white-list to assume that files in /etc meant to be > executed (such as initscripts related files) are not configuration > files in any way. Admin may decide to edit such executables nevertheless > (for reasons unknown), but the next update would overwrite the changes. Good to know that mentioned white-list exists. Could you indicate me where can I find this white-list? > Also not forget, rpmlint only warns about it. Not marking them %config > would not be a severe mistake. It's just better to mark them %config > because of the contents of these files. Yes, right. Best regards. Marcin Haba 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: Question about profile.d scripts definition in Spec file
On 02.08.2015 23:15, Michael Schwendt wrote: > On Sun, 2 Aug 2015 16:29:06 +0200, Marcin Haba wrote: > >>>> A) if a shell script can be treated as configuration file? >>> >>> Certainly. It's a cheap way to set a program's runtime configuration >>> instead of implementing a full config file loader/parser. >> >> My image of configuration files is that they are files for read/write >> purpose by design, because they enables _configure_ something >> (application, service, single program, script...whatever). If they are >> dedicated only for reading then from my point of view they lose >> "configuration" meaning (something like WORM storage ;-) ). > > Why would you say that? Hello Michael, I trying to express my opinion about my understanding 'configuration files' meaning. > There are read-only config files to set the system-wide default for > everyone. The program reads them first before looking for user's local > config files to override the defaults. The program would never write > the system-wide file file in /etc, but at most the user's local file. In my opinion that this type of files can be classified as pre-defined settings files, not configuration files. In any case, it looks that we have different understanding configuration files and it causes cross over our opinions. I think also that better could be set the environment variables values in /etc/defaults/ and use these values by shell scripts instead using hard-coded values in shell scripts. Coming back to profile.d sample, when somebody try to modify profile.d file marked as %config [not %config(noreplace)] then after upgrade package with new profile.d file version, the file will be overwritten and user will lose introduced changes. It seems that all this situation uncovers bigger problem :-) > And in general, whether a program can write its own config files is purely > a question of design. Clearly, over the years there have been programs that > only read config files somebody [or some tool] can create. > > /etc/bashrc, /etc/profile are examples of %config files where the file > format is shell language code to be interpreted by a shell. >> However I believe that exist some tools or libraries that can do this >> content analyze for rpmlint. > > What would be the benefit? rpmlint cannot get it 100% right > anyway. There could be corner-cases, where a config file gets executed > instead of being "sourced" like a shell include file. Yes, rpmlint cannot get it 100% right, but it can report potential executable files more accurate. If something can offload person, that for example do review request, from manual checking content of files, why not use it? >>> It's some sort of white-list to assume that files in /etc meant to be >>> executed (such as initscripts related files) are not configuration >>> files in any way. Admin may decide to edit such executables nevertheless >>> (for reasons unknown), but the next update would overwrite the changes. >> >> Good to know that mentioned white-list exists. Could you indicate me >> where can I find this white-list? > > With "some sort of white-list" I mean the simplification -- the > simplified assumption -- that files with execute permission are > believed to be executables and not configuration files. And vice > versa. Real configuration files being marked executable are believed > to be mistakes. OK. Thanks for clarify. Best regards. Marcin Haba 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: Question about profile.d scripts definition in Spec file
On 02.08.2015 23:58, Jonathan Underwood wrote: > On 2 August 2015 at 22:57, Jonathan Underwood > wrote: >> On 2 August 2015 at 15:29, Marcin Haba wrote: >>> My image of configuration files is that they are files for read/write >>> purpose by design, because they enables _configure_ something >>> (application, service, single program, script...whatever). If they are >>> dedicated only for reading then from my point of view they lose >>> "configuration" meaning (something like WORM storage ;-) ). >>> >> >> This is probably an argument for having shell configuration fragments >> packaged under /usr/lib/bash/profile.d rather than /etc/profile.d. > > .. or /usr/share/bash/profile.d, perhaps. Hello Jonathan, That is also good idea, I think. Thanks. Best regards. Marcin Haba 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: Question about profile.d scripts definition in Spec file
Hello Michael, W dniu 03.08.2015 o 13:09, Michael Schwendt pisze: >> In my opinion that this type of files can be classified as pre-defined >> settings files, not configuration files. In any case, it looks that we >> have different understanding configuration files and it causes cross >> over our opinions. > > So, a configuration file, which contains constants or is not changed for a > very long time, becomes a "settings file"? And a settings file that gets > modified by an admin to customise the defaults becomes a "configuration > file"? I did not say that. The only one message that I am trying to say in this point is: configuration files for me should be designed to configure/modify by administrator or directly by application. If some files are designed only for reading values like auto-generated files or mentioned by you pre-defined variables or just scripts, I do not treat them in configuration files aspect at all. And better when they are marked special clause in comment. As long the types calling is not standardized in a official common specification and it is used at the discretion, as long we can talk about it. As I wrote in one from my first mail in this thread: "I guess that it is subject to longer discussion and not here (off-topic)." > There are more names one could use for such a file, such as "preferences > file, defaults file, initialization file, setup file". > > I don't think there is not even a subtle difference. It depends on a > definition of how such a file is supposed to be used. Indeed. Unfortunately we do not have any common definition. >> I think also that better could be set the environment variables values >> in /etc/defaults/ and use these values by shell scripts instead using >> hard-coded values in shell scripts. > > Files in /etc/default are configuration files, too, and are to be marked > as such in RPM packages. > >> Coming back to profile.d sample, when somebody try to modify profile.d >> file marked as %config [not %config(noreplace)] then after upgrade >> package with new profile.d file version, the file will be overwritten >> and user will lose introduced changes. >> >> It seems that all this situation uncovers bigger problem :-) > > Which problem do you see? I am seeing problem overwriting files if somebody hastily use %config on script instead %config(noreplace) only because rpmlint returns warning on package. Then it can result unexpected overwriting this file during update the package. If this overrwrite action will cause that for example offline blog application nothing big is happening. If it will cause move offline large 24/7 service, it can result troubles. > If marked as %config or %config(noreplace), RPM will create .rpmsave or > .rpmnew files the admin/user will need to review. Yes, but for some services triggering offline can be more painful than configuration lost. On files always can do backup, on services downtime cannot. >> Yes, rpmlint cannot get it 100% right, but it can report potential >> executable files more accurate. > > It could only _try to_ and would print even more guesses and false > positives. Such as checking for shebang values in files lacking execute > permission bits. And still it could be intentional that the files are > not executable by default (-> examples, templates, stubs). Yes, I did not think about this cases. You are right. > >> If something can offload person, that >> for example do review request, from manual checking content of files, >> why not use it? > > Wishful thinking. A tool like rpmlint will never develop a better > understanding for an RPM package than the person, who created that package > and will maintain it. Reviewing packages is not rocket science. In most > cases a "just do it" mentality during package review phase would be > extremely helpful instead of trying to complicate matters. Thanks for your opinions and valuable discussion. Best regards. Marcin Haba 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: Question about profile.d scripts definition in Spec file
Hello Michael, On 03.08.2015 20:15, Michael Schwendt wrote: > On Mon, 3 Aug 2015 19:02:26 +0200, Marcin Haba wrote: > >> The only one message that I am trying to say in this point is: >> configuration files for me should be designed to configure/modify by >> administrator or directly by application. > > A moot point, too. It is my opinion, so it can seem to be a moot point :-) > First of all, if not installing prebuilt RPM packages, usually it's the > admin who compiles and installs the software from sources. That involves a > first configuration step already. The admin makes choices where to install > (e.g. /usr vs. /usr/local), which features to enable, and possibly > influences other configuration defaults, too. After installation, the > admin would edit available config file as necessary. Yes, true. It is normal administrator matter: use binary packages or compile something self. > When installing from a distributor's RPM package collection, some of those > steps are handled by the package maintainer. Other steps are postponed. > Again, the admin likely needs to review the prebuilt config files and > apply modifications. Yes, it is also normal. I am not sure why are you writing about it. If it is to text about configuration files modification by administrator or application I this sentence I did not mean neither compilation self nor binary packages way, but just general using configuration files independent on installation method. Very simple examples: - Modification by administrator a config file: # vi /etc/httpd/conf.d/my_favourite_website.conf [save config after modification] - Modification by application: # hostname home.lan > Back to ossim-data: > > if [ -z "$OSSIM_INSTALL_PREFIX" ]; then > export OSSIM_INSTALL_PREFIX=/usr > fi > > if [ -z "$OSSIM_PREFS_FILE" ]; then > export > OSSIM_PREFS_FILE=$OSSIM_INSTALL_PREFIX/share/ossim/ossim_preferences > fi > > The program could simply hardcode those paths at compile-time. What's the > benefit of using env vars? Clearly it's the option to reconfigure the > program at runtime. If not via extra command-line options when running the > program, the user or the admin could point the program at different paths > with modifications to these configuration files. > > During an update of the packages, the files would be reset to the > distribution default and break the user's/admin's customisation. That is not good. > The package user will be annoyed, because /etc specifically is for > configuration files. If the packager will not mark the files as configuration > files, the admin will likely override those env vars elsewhere or > abandon using the packages. I would be annoyed either. >> If some files are designed only for reading values like auto-generated >> files or mentioned by you pre-defined variables or just scripts, I do >> not treat them in configuration files aspect at all. And better when >> they are marked special clause in comment. >> >> As long the types calling is not standardized in a official common >> specification and it is used at the discretion, as long we can talk >> about it. As I wrote in one from my first mail in this thread: >> >> "I guess that it is subject to longer discussion and not here (off-topic)." > > The alternative list is packaging@ for Fedora packaging related topics. > I only would like to understand why you would not treat such files as > configuration. That's the only motivation for my replies so far. ;-) That is nice :-) The reason is simple: from my point of view "configuration files" phrase does not refer its 'configuration' word to action "configure something by my content" but "configure something by editing my content". The same way README files do not say "read my name", but "read my content"...etc. :-) I am sorry if my explanation is unclear. My English is still on low level and sometimes I am not able to explain something. Specially this type of "word game". >>> Which problem do you see? >> >> I am seeing problem overwriting files if somebody hastily use %config on >> script instead %config(noreplace) only because rpmlint returns warning >> on package. Then it can result unexpected overwriting this file during >> update the package. > > How would that be different from not marking the same file %config? I do not claim that not using %config is better solution. Also from this reason I am here in this thread, because my main question was what can I do with the rpmlint warning about profile.d script definition in Spec. Up till know I learned that %config is more suitable for config.d scripts.
Re: Question about profile.d scripts definition in Spec file
On 04.08.2015 19:38, Michael Schwendt wrote: > On Mon, 3 Aug 2015 22:16:39 +0200, Marcin Haba wrote: >>> Btw, rpmlint does not override Fedora's packaging guidelines: >>> https://fedoraproject.org/wiki/Packaging:Guidelines#Configuration_files >> >> Not override, but good when rpmlint follows on packaging guidelines as >> much as possible and reasonable. > > You could open a RFE in rpmlint upstream tracker. > Or try to get Fedora's rpmlint to point at the packaging guidelines > section instead of mentioning %config directly. Thanks for the tip. Your idea seems OK, however I am not sure if I really want go in this direction. Best regards. Marcin Haba 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: package-cleanup after F21
On 11.08.2015 19:00, Reindl Harald wrote: > > > Am 11.08.2015 um 18:12 schrieb Michael Schwendt: >> On Tue, 11 Aug 2015 18:02:49 +0200, Reindl Harald wrote: > it *is not* a replacement because "yum autoremove" existed and is a > completly different beast > >> Now, whether the replacements works or is broken, that's not what you >> had asked > > Uh, come on, Michael! People usually ask for working things Hello, Well, I have a opposed opinion from experience. When something is working, people usually do not write anything :-) When something is not working, then they have so much things to say. And at the end, when they bought this not working thing... then people can even bite :-) I say it generally, without having on mind anybody concrete. Best regards. Marcin Haba 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: package-cleanup after F21
On 11.08.2015 20:22, Reindl Harald wrote: > > > Am 11.08.2015 um 20:03 schrieb Marcin Haba: >> On 11.08.2015 19:00, Reindl Harald wrote: >>> >>> >>> Am 11.08.2015 um 18:12 schrieb Michael Schwendt: >>>> On Tue, 11 Aug 2015 18:02:49 +0200, Reindl Harald wrote: >>> it *is not* a replacement because "yum autoremove" existed and is a >>> completly different beast >>> >>>> Now, whether the replacements works or is broken, that's not what you >>>> had asked >>> >>> Uh, come on, Michael! People usually ask for working things >> >> Hello, >> >> Well, I have a opposed opinion from experience. When something is >> working, people usually do not write anything :-) > Hello, > where is the opposed opinion here? > maybe you just did not understand "People usually ask for working > things" by miss the context "whether the replacements works or is > broken, that's not what you had asked" I am not sure if saying general opinions is connected with any context. It is just subjective opinion, such like "People usually like driving cars" or "The best diet is eating a lot of salad.". Opposed opinions are here: Your: "People usually ask for working things" Mine: "People usually ask for not working things". I did not have nothing bad on mind. I noticed your opinion and I thought that I can share my opposed opinion here. OK. stop. The thread becomes off-topic :-) Best regards. Marcin Haba 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: Sponsors - who does (not) work on FE-NEEDSPONSOR tickets
On 17.08.2015 15:18, Josh Boyer wrote: > On Mon, Aug 17, 2015 at 9:07 AM, Miroslav Suchý wrote: >> Dne 17.8.2015 v 14:47 Josh Boyer napsal(a): >>> I would recommend removing all of the above people from the sponsors group. >> >> -1 >> There is nothing wrong on being inactive. At least as long as others are >> active. >> If they would want, they can return any time they want. > > There is a problem though. It makes the sponsors list larger than it > actually is, and gives the impression that we have more people > available for sponsoring than we actually do. From a new packager > perspective, it is even more frustrating to see a larger list and > still have no sponsor. Yes, exactly! I am waiting from March 2015. I am active in a few Fedora areas (informal reviews, bugs requests, preparing new features requests, small patch preparation to fedora-review tool, mailing list sent from time to time). My feeling as new person in Fedora devel community is that something does not work here. From my point of view it looks that at least these new persons' activities are not noticed or are ignored. I do not write it for forcing my being sponsored. I am not expecting that and even I would not be sponsored now. I prefer to be sponsored in natural way, not by recalling about me. I am writing about it for share with you my feedback as new person that is trying to be sponsored. > At the very least, we need to have a way to mark these people as > inactive so they are accurately reflected. I am very curious the output from script that will recognize this situation. Best regards. Marcin Haba 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: Sponsors - who does (not) work on FE-NEEDSPONSOR tickets
Hello, On 17.08.2015 16:33, Michael Schwendt wrote: > On Mon, 17 Aug 2015 15:50:26 +0200, Marcin Haba wrote: > >> Yes, exactly! I am waiting from March 2015. > > Waiting for what? For sponsoring me by somebody. Please read context. And this thread title either ;-) > There may be a misunderstanding of the How To Get Sponsored Wiki page. If everything works fine with sponsoring, so why does this subject exist? It is not first thread here about sponsoring. >> I am active in a few Fedora >> areas (informal reviews, bugs requests, preparing new features requests, >> small patch preparation to fedora-review tool, mailing list sent from >> time to time). > > That sounds like quite some activity which you should mention when > contacting a potential sponsor. In your package review requests you > have met some potential sponsors already. Yes, I have met a potential sponsor. But it did not cause that I started to be sponsored. It is not my intention to ask every sponsor about sponsoring me. For this purpose is used FE-NEEDSPONSOR ticket and I am there already. > Please don't expect *every* sponsor to observe *everyone* everywhere > within the Fedora Project or even beyond that. I do not expect every sponsor to observe every everywhere. But sponsors that are not only two or three persons ;-) > Sponsors usually take a look at the queue, and if there is no name they > have seen before, or if there is only a single package submitted by > somebody, that's not much input. However, a single package review > ticket is a great place where to point at reviews you've done, or to > give sponsors a hint about any other activity (such as packages in Copr > or a private repo). Sponsors cannot know that. I do not have only single package ticket. And in near feature I am going to provide more packages to review. It is also required for unbundle one my big package that I am trying to contribute Fedora. >> My feeling as new person in Fedora devel community is that something >> does not work here. From my point of view it looks that at least these >> new persons' activities are not noticed or are ignored. > > As above. Waiting is the biggest pitfall of the needsponsor review queue. > The worst is not responding to reviewer's comments and waiting inactively > for months (without even maintaining the submitted packages). Please show me ticket where I did not response in reasonable time? In ticket for, which I am doing informal reviews, that I remind people that ticket does not move forward. > The Wiki also suggests doing some things _in advance_ (such as a few > reviews, and weeks to months give plenty of time to attempt at doing a > few reviews), so if a potential sponsor takes a look at the single > package somebody may have added to the queue, there is more input in the > ticket than just a single (and possibly flawed/broken) package. In which place packages added by my are broken? I am not going to continue this discussion because as I wrote in previous mail, it was only feedback from my side. It is not my intention to gain something by this feedback. It is just feedback to potential consideration if it is useful. Thanks. Best regards. Marcin Haba 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: Sponsors - who does (not) work on FE-NEEDSPONSOR tickets
On 17.08.2015 17:40, Pete Travis wrote: > On Aug 17, 2015 10:07 AM, "Marcin Haba" wrote: >> >> Hello, > > *snip* > >> I am not going to continue this discussion because as I wrote in >> previous mail, it was only feedback from my side. It is not my intention >> to gain something by this feedback. It is just feedback to potential >> consideration if it is useful. >> >> Thanks. >> >> Best regards. >> Marcin Haba > > This is the misunderstanding. Your feedback is welcome and helpful, that's > how the Fedora community operates. Someone might debate with you, but that > is how ideas change and grow. > > If you are sharing your experience, and sharing your progress, you *should* > expect to gain something from it. The theme of the thread is about > improving that experience for you, the prospective packager. I encourage > you to start a new, public thread detailing your progress and goals. Hello Pete, You are right. The thread is targeted on sponsors, not sponsored. I read a sentence which touched my current feeling and I really wanted to comment it. And this way I jumped here in this thread. Sorry, if I broke this discussion and thanks for your advises. > (And I apologize if you've already done that. Part of the problem is that > activity on both sides is not easily discoverable, so you might have to > help sponsors discover your efforts. That's not begging for special > attention, only participating in the process.) I am not sure if I try this. Nevertheless thanks for this tip. Best regards. Marcin Haba 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
Self Introduction: Marcin Haba
Hello, I am going to try join to Fedora packagers. My experience with GNU/Linux I started about 14 years ago. I do not have favorite GNU/Linux distribution. Depending on my needs, I install specific distribution on VM environment or on physical host. I like learning new things from operating systems area, I believe that here I get to know a lot of new things. I created and I develop Baculum tool. It is web interface to Bacula Community services. In RedHat Bugzilla I added Package Review ticket for Fedora. Thank you in advance for look in this ticket and help with Baculum packaging. Regards. Marcin -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
