Make upstream release monitoring (the service formerly known as FEVer) opt-out?

[Till Maas]

Hiyas,

currently upstream release monitoring[0] bug filing is opt-in, which
means that it will be only performed for packages that have been activly
added by probably a maintainer of the package. There is at least one
maintainer that does not like having these bugs filed for his packages,
so he can remove his packages from the list.

It might be easily possible in the future to monitor a bunch more
packages and create bugs in case there are newer versions available at
upstream.

Would it be ok, to do this and allow maintainers to add there package to
a black list, so that no bugs will be filed or should it continue to be
opt-in? Then the packags will still be checked, but only reported by
other, non intrusive ways, e.g. via a website.

Regards
Till

[0] https://fedoraproject.org/wiki/Upstream_Release_Monitoring

[Rakesh Pandit]

2009/8/7 Till Maas wrote:
[..]
>  Would it be ok, to do this and allow maintainers to add there package to
>  a black list, so that no bugs will be filed or should it continue to be
>  opt-in? Then the packags will still be checked, but only reported by
>  other, non intrusive ways, e.g. via a website.
>  
IMO, ideally it would be best to get new version information for all
packages, but file bugs only against those maintainers who opt for it
and keep the information available some place.

Information about current_version -> new_version_available will be
helpful to package maintainers.

>  [0] https://fedoraproject.org/wiki/Upstream_Release_Monitoring
>  
--
Regards,
Rakesh Pandit

[Eric Sandeen]

Till Maas wrote:
>  Hiyas,
>  
>  currently upstream release monitoring[0] bug filing is opt-in, which
>  means that it will be only performed for packages that have been activly
>  added by probably a maintainer of the package. There is at least one
>  maintainer that does not like having these bugs filed for his packages,
>  so he can remove his packages from the list.
>  
>  It might be easily possible in the future to monitor a bunch more
>  packages and create bugs in case there are newer versions available at
>  upstream.
>  
>  Would it be ok, to do this and allow maintainers to add there package to
>  a black list, so that no bugs will be filed or should it continue to be
>  opt-in? Then the packags will still be checked, but only reported by
>  other, non intrusive ways, e.g. via a website. 
Speaking just for myself, I'd be happy to have it automatic for my
packages.  But wow, who's going to key in all those regexps and keep it
up to date?

-eric

>  Regards
>  Till
>  
>  [0] https://fedoraproject.org/wiki/Upstream_Release_Monitoring
>

[Till Maas]

On Thu, Aug 06, 2009 at 11:27:23PM -0500, Eric Sandeen wrote:

>  Speaking just for myself, I'd be happy to have it automatic for
> my
>  packages.  But wow, who's going to key in all those regexps and keep it
>  up to date? 
On source of normalized data is Oswatershed[0]. My long time vision
would be to manage this data in a central place like there and to
coordinate the management of the data also with other distributions.

Regards
Till


[0]http://oswatershed.org/

[Ralf Corsepius]

On 08/06/2009 09:33 PM, Till Maas wrote:
>  Hiyas,
>
>  currently upstream release monitoring[0] bug filing is opt-in, which
>  means that it will be only performed for packages that have been activly
>  added by probably a maintainer of the package. There is at least one
>  maintainer that does not like having these bugs filed for his packages,
>  so he can remove his packages from the list. 
I'd prefer this system to be kept opt-in, because I think

a) A system can only be made opt-out, if a system can handle the 
overwhelming number of cases automatically. However, [0] indicates this 
does not (yet?) apply. Conversely it explicitly asks for manual interaction.


b) You seem to be presuming all upstreams to apply one single "newer 
metric" (Versioning scheme). This doesn't apply, there exist several 
different versioning schemes, e.g. pre-/bugfix-release versionings, 
perl-versioning vs. rpm versioning etc. Also, many projects occasionally 
change their versioning schemes or don't even apply one.

How do you plan to handle this?


c) Some upstreams occasionally change their download URLs or use 
non-permanent URLs or some "more or less unstable" URL-redirection.

How do you want to hangle this?


>  Would it be ok, to do this and allow maintainers to add there package
> to
>  a black list, so that no bugs will be filed or should it continue to be
>  opt-in? Then the packags will still be checked, but only reported by
>  other, non intrusive ways, e.g. via a website. 
<alarm bell ring/> Website? ==
yet more bureaucracy ????

>  [0] https://fedoraproject.org/wiki/Upstream_Release_Monitoring

Ralf

[Till Maas]

On Fri, Aug 07, 2009 at 06:35:14AM +0200, Ralf Corsepius wrote:
>  On 08/06/2009 09:33 PM, Till Maas wrote: 
> > currently upstream release monitoring[0] bug filing is opt-in,
> which
> > means that it will be only performed for packages that have been activly
> > added by probably a maintainer of the package. There is at least one
> > maintainer that does not like having these bugs filed for his packages,
> > so he can remove his packages from the list.
>
>  I'd prefer this system to be kept opt-in, because I think 
Do I understand it corretly, that if you won't get any false bug
reports, then you don't have any objection?

>  a) A system can only be made opt-out, if a system can handle the  
>  overwhelming number of cases automatically. However, [0] indicates this  
>  does not (yet?) apply. Conversely it explicitly asks for manual 
>  interaction. 
I am not sure what's the problem you are seeing here. Maybe it was a bad
use of the word "opt-out". If the monitoring system does not check a
package, the maintainer obviously does not need to opt out, but also it
does not create any more problems. Or what are the cases you are
referring to?

>  b) You seem to be presuming all upstreams to apply one single
> "newer  
>  metric" (Versioning scheme). This doesn't apply, there exist several  
>  different versioning schemes, e.g. pre-/bugfix-release versionings,  
>  perl-versioning vs. rpm versioning etc. Also, many projects occasionally  
>  change their versioning schemes or don't even apply one.
>
>  How do you plan to handle this? 
I plan to handle it on a case to case basis, e.g. either make the
version comparison work or ignore the package. Also the data source that
can might be added, already normalises the data for the affected
packages.
Currently the monitoring system supports some rc/pre releases
and checks whether or not the upstream version can be found in the CVS
sources file to avoid bogus bug reports.
If you have some ideas, which versions may cause problems, please
provide some examples. I will then add them to the unittests and see,
how well they are handled. For this I need at least one upstream
version, one rpm version/release pair and an expected result (which
should be newer or are both the same).

>  c) Some upstreams occasionally change their download URLs or use  
>  non-permanent URLs or some "more or less unstable" URL-redirection.
>
>  How do you want to hangle this? 
The options are to ignore the package or to update the URL when they
change.

> > Would it be ok, to do this and allow maintainers to add there
> package to
> > a black list, so that no bugs will be filed or should it continue to be
> > opt-in? Then the packags will still be checked, but only reported by
> > other, non intrusive ways, e.g. via a website.
>  <alarm bell ring/> Website? == yet more bureaucracy ???? 
I don't get how you might even expect more bureaucracy from some status
website. What do you think this website might be? It will not require
anybody to look at it, but provide the information to interested people.

Regards
Till

[Pierre-Yves Chibon]

On Fri, 2009-08-07 at 10:48 +0200, Till Maas wrote:
>  >> Would it be ok, to do this and allow maintainers to add
> there package to
>  >> a black list, so that no bugs will be filed or should it continue to be
>  >> opt-in? Then the packags will still be checked, but only reported by
>  >> other, non intrusive ways, e.g. via a website.
>  > <alarm bell ring/> Website? == yet more bureaucracy ????
>  
>  I don't get how you might even expect more bureaucracy from some status
>  website. What do you think this website might be? It will not require
>  anybody to look at it, but provide the information to interested people. 
It remembers me a website made by Remi[1] which list for all the package
available, for all the branch what version are in the repo.
It also provides comparison between upstream and repo for some packages
such as the PECL, PEAR and R packages.

[1] http://rpms.famillecollet.com/rpmphp/

Regards,
Pierre

[Till Maas]

On Fri, Aug 07, 2009 at 10:56:03AM +0200, Pierre-Yves wrote:

>  It remembers me a website made by Remi[1] which list for all the
> package
>  available, for all the branch what version are in the repo.
>  It also provides comparison between upstream and repo for some packages
>  such as the PECL, PEAR and R packages.
>  
>  [1] http://rpms.famillecollet.com/rpmphp/ 
Thx, I added it to the list of these kind of projects:

https://fedoraproject.org/wiki/Upstream_Release_Monitoring#Related_Projects

Regards
Till

[José Abílio Matos]

On Friday 07 August 2009 09:56:03 Pierre-Yves wrote:
>  It remembers me a website made by Remi[1] which list for all the
> package
>  available, for all the branch what version are in the repo.
>  It also provides comparison between upstream and repo for some packages
>  such as the PECL, PEAR and R packages. 
We should warn Remi about the numbering in R packages where . and - are 
equivalent in releases.

The practical consequence of this is that most of our packages are up to date 
instead of the brown warning shown in the table. :-)

>  [1] http://rpms.famillecollet.com/rpmphp/
>
>  Regards,
>  Pierre 
-- 
José Abílio

[Pierre-Yves Chibon]

On Fri, 2009-08-07 at 10:23 +0100, José Matos wrote:
>  On Friday 07 August 2009 09:56:03 Pierre-Yves wrote:
>  > It remembers me a website made by Remi[1] which list for all the package
>  > available, for all the branch what version are in the repo.
>  > It also provides comparison between upstream and repo for some packages
>  > such as the PECL, PEAR and R packages.
>  
>  We should warn Remi about the numbering in R packages where . and - are 
>  equivalent in releases.
>  
>  The practical consequence of this is that most of our packages are up to date 
>  instead of the brown warning shown in the table. :-) 
Request done ;-)

P.Yves

[Ralf Corsepius]

On 08/07/2009 10:48 AM, Till Maas wrote:
>  On Fri, Aug 07, 2009 at 06:35:14AM +0200, Ralf Corsepius wrote:
> > On 08/06/2009 09:33 PM, Till Maas wrote:
>
> >> currently upstream release monitoring[0] bug filing is opt-in, which
> >> means that it will be only performed for packages that have been activly
> >> added by probably a maintainer of the package. There is at least one
> >> maintainer that does not like having these bugs filed for his packages,
> >> so he can remove his packages from the list.
> >
> > I'd prefer this system to be kept opt-in, because I think
>
>  Do I understand it corretly, that if you won't get any false bug
>  reports, then you don't have any objection? 
Correct. Such a system may be useful for some people and applicable to 
some cases, therefore I don't see many reasons why people in such 
situations shouldn't be using it (== opt-in).

> > a) A system can only be made opt-out, if a system can handle the
> > overwhelming number of cases automatically. However, [0] indicates this
> > does not (yet?) apply. Conversely it explicitly asks for manual
> > interaction.
>
>  I am not sure what's the problem you are seeing here. 
Package maintainers (e.g.
me) are not interested in more Fedora 
bureaucracy nor in having to cope with "yet another" system
(besides bugzilla, trac, kojo, bodhi, packagedb, cvs, repos, steering 
organs (FPB, FESCO, FPC, Fedora <committee de jour etc.).

>  Maybe it was a bad
>  use of the word "opt-out". If the monitoring system does not check a
>  package, the maintainer obviously does not need to opt out, but also it
>  does not create any more problems. Or what are the cases you are
>  referring to? 
I sense a miscommunication. As I understood your mail and [0], you
are 
offering a service, maintainers can opt-in to use. Now you would like to 
make your service "the default" (== opt-out) and are asking for opinions.

Did I misunderstand?

> > b) You seem to be presuming all upstreams to apply one single
> "newer
> > metric" (Versioning scheme). This doesn't apply, there exist several
> > different versioning schemes, e.g. pre-/bugfix-release versionings,
> > perl-versioning vs. rpm versioning etc. Also, many projects occasionally
> > change their versioning schemes or don't even apply one.
> >
> > How do you plan to handle this?
>
>  I plan to handle it on a case to case basis, e.g. either make the
>  version comparison work or ignore the package. Also the data source that
>  can might be added, already normalises the data for the affected
>  packages.
>  Currently the monitoring system supports some rc/pre releases
>  and checks whether or not the upstream version can be found in the CVS
>  sources file to avoid bogus bug reports. 
I am not sure if this can ever be
achieved, because there exist many 
varients of versioning schemes and because it's not uncommon for 
upstreams switch between several.

>  If you have some ideas, which versions may cause problems,  please
>  provide some examples. 
Some classic cases:

* 1.2pre .. "pre release ", 1.2 "release", 1.2a "bugfix a".
* 1.2a .. "1.2a release", 1.2b "1.2b" release.
* 1.2pre .. "pre release", 1.2. "release", 1.2.1 "successor of
1.2"
* 1.2 ... latest release, 1.3 "successor of 1.2" (GNU versioning)
* 1.1, 1.2a, 1.2b, 1.2 (A variant of the GNU versioning,
   releases are using numerical versions,
   versions with suffix "a,b,c..." are prereleases)
* 1.18, 1.1901, 1.1902, 1.20 (Perl versioning ... X.20 > X.1900 !)
* Frequent builds using the same version (replacing the same tarball), 
e.g. daily snapshots.

...
Now imagine upstreams switching between these .. No idea, how you would 
want to handle this.

>  I will then add them to the unittests and see,
>  how well they are handled. For this I need at least one upstream
>  version, one rpm version/release pair and an expected result (which
>  should be newer or are both the same). 
> > c) Some upstreams occasionally change their download URLs or use
> > non-permanent URLs or some "more or less unstable" URL-redirection.
> >
> > How do you want to hangle this?
>
>  The options are to ignore the package or to update the URL when they
>  change. 
How? For your service to be helpful, you would have to do this 
automatically. I don't see, how this could be achieved.

> >> Would it be ok, to do this and allow maintainers to add there
> package to
> >> a black list, so that no bugs will be filed or should it continue to be
> >> opt-in? Then the packags will still be checked, but only reported by
> >> other, non intrusive ways, e.g. via a website.
> > <alarm bell ring/>  Website? == yet more bureaucracy ????
>
>  I don't get how you might even expect more bureaucracy from some status
>  website. What do you think this website might be? It will not require
>  anybody to look at it, but provide the information to interested people. 
[0] says
"write a regex", "opt-out" would mean forced interaction with 
your website, "opt-in" would mean "registration".

All in all, I read this as "bureaucracy".

Ralf

[Till Maas]

On Fri, Aug 07, 2009 at 12:28:50PM +0200, Ralf Corsepius wrote:
>  On 08/07/2009 10:48 AM, Till Maas wrote:
> > On Fri, Aug 07, 2009 at 06:35:14AM +0200, Ralf Corsepius wrote:
> >> On 08/06/2009 09:33 PM, Till Maas wrote:
> >
> >>> currently upstream release monitoring[0] bug filing is opt-in, which
> >>> means that it will be only performed for packages that have been activly
> >>> added by probably a maintainer of the package. There is at least one
> >>> maintainer that does not like having these bugs filed for his packages,
> >>> so he can remove his packages from the list.
> >>
> >> I'd prefer this system to be kept opt-in, because I think
> >
> > Do I understand it corretly, that if you won't get any false bug
> > reports, then you don't have any objection?
>
>  Correct. Such a system may be useful for some people and applicable to  
>  some cases, therefore I don't see many reasons why people in such  
>  situations shouldn't be using it (== opt-in). 
The question is, wether there are more people benefiting from it than
are are being disturbed by it. If more people are benefiting, then imho
opt-out is ok, if not, then it should be opt-in. But I am mainly
interested in whether people are disturbed by such bug reportes, even if
the bug report is valid, i.e. if the package really has a newer upstream
version available.

> >> a) A system can only be made opt-out, if a system can handle
> the
> >> overwhelming number of cases automatically. However, [0] indicates this
> >> does not (yet?) apply. Conversely it explicitly asks for manual
> >> interaction.
> >
> > I am not sure what's the problem you are seeing here.
>  Package maintainers (e.g. me) are not interested in more Fedora  
>  bureaucracy nor in having to cope with "yet another" system
>  (besides bugzilla, trac, kojo, bodhi, packagedb, cvs, repos, steering  
>  organs (FPB, FESCO, FPC, Fedora <committee de jour etc.). 
Nobody will be forced to use it and opting-out would be less work then
writing this mail btw. But don't worry. In case there will be a consesus
to make this opt-out, I will add you myself to the blacklist, so you
won't be bothered.

>  > Maybe it was a bad
> > use of the word "opt-out". If the monitoring system does not check a
> > package, the maintainer obviously does not need to opt out, but also it
> > does not create any more problems. Or what are the cases you are
> > referring to?
>  I sense a miscommunication. As I understood your mail and [0], you are  
>  offering a service, maintainers can opt-in to use. Now you would like to  
>  make your service "the default" (== opt-out) and are asking for opinions.
>
>  Did I misunderstand? 
No, but I did not understand "A system _can_ only be made opt-out,
if..". Do you maybe mean "should" instead of "can" there? But
there is
also the restriction that the service will only be provided in cases
where I do not expect bogus bug reports, so there may be still be
packages that are not yet monitored. The opt-in/out mainly addresses of
whether or not accurate bug reports should filed automatically.

> >> b) You seem to be presuming all upstreams to apply one single
> "newer
> >> metric" (Versioning scheme). This doesn't apply, there exist several
> >> different versioning schemes, e.g. pre-/bugfix-release versionings,
> >> perl-versioning vs. rpm versioning etc. Also, many projects occasionally
> >> change their versioning schemes or don't even apply one.
> >>
> >> How do you plan to handle this?
> >
> > I plan to handle it on a case to case basis, e.g. either make the
> > version comparison work or ignore the package. Also the data source that
> > can might be added, already normalises the data for the affected
> > packages.
> > Currently the monitoring system supports some rc/pre releases
> > and checks whether or not the upstream version can be found in the CVS
> > sources file to avoid bogus bug reports.
>  I am not sure if this can ever be achieved, because there exist many  
>  varients of versioning schemes and because it's not uncommon for  
>  upstreams switch between several.
>
> > If you have some ideas, which versions may cause problems,  please
> > provide some examples.
>
>  Some classic cases:
>
>  * 1.2pre .. "pre release ", 1.2 "release", 1.2a "bugfix
> a".
>  * 1.2a .. "1.2a release", 1.2b "1.2b" release.
>  * 1.2pre .. "pre release", 1.2. "release", 1.2.1 "successor of
> 1.2"
>  * 1.2 ... latest release, 1.3 "successor of 1.2" (GNU versioning) 
Above are all handled correctly now, it did not yet handle "1.2pre"
correctly, but this could be fixed with adding a questionmark to the
regex, because I expected a number after the pre.

>  * 1.1, 1.2a, 1.2b, 1.2 (A variant of the GNU versioning,
>    releases are using numerical versions,
>    versions with suffix "a,b,c..." are prereleases) 
These are not handled correctly, i.e. from this list of versions it is
not possible to determine the latest version. But since there won't be
any new pre-releases after 1.2 was released, it would currently result
in 1.2 being silently ignored if the system would have reported all
other releases. If there is a way to only get the latest release using
the regex, e.g. because upstream publishes something like "the latest
release is: 1.2b" and the tarball contains the version as a verbatim
string, then the CVS lookup will prevent the system to file bogus
reports afaics. E.g. rpm NVR is foo-1.2-0.1.b.fc12 and upstream tarball
is foo-1.2b.tar.gz, there is no problem currenlty.

>  * 1.18, 1.1901, 1.1902, 1.20 (Perl versioning ... X.20 > X.1900 !)
This causes problems, too. How are these mapped to rpm NVRs? Here the
script will currently report 1.20 as beeing the latest. If it was
already reported once, it won't be reported, but for the remaining
actions I need to know how the rpm would look like.

>  * Frequent builds using the same version (replacing the same
> tarball),   
This will currently result in silent ignorance, so no bogus bug reports.

>  e.g. daily snapshots. 
This depends on how the snapshot is created. If it is done by upstream
and included in the reported upstream version, there should be no
problem.

>  Now imagine upstreams switching between these .. No idea, how you
> would  
>  want to handle this. 
If the system ran long enough, the main problem will be ignored upstream
releases, because it won't report the same upstream version twice. But
the question is also how often this will happen in reality.

> >> c) Some upstreams occasionally change their download URLs or
> use
> >> non-permanent URLs or some "more or less unstable" URL-redirection.
> >>
> >> How do you want to hangle this?
> >
> > The options are to ignore the package or to update the URL when they
> > change.
>  How? For your service to be helpful, you would have to do this  
>  automatically. I don't see, how this could be achieved. 
Imho it is already helpful if only a subset of packages are checked.
It would be enough for the service to notice that something is wrong and
require manual intervention. But this is a problem that also a package
maintainer has, that wants to check manually whether or not there are
new releases.

> >>> Would it be ok, to do this and allow maintainers to add
> there package to
> >>> a black list, so that no bugs will be filed or should it continue to be
> >>> opt-in? Then the packags will still be checked, but only reported by
> >>> other, non intrusive ways, e.g. via a website.
> >> <alarm bell ring/>  Website? == yet more bureaucracy ????
> >
> > I don't get how you might even expect more bureaucracy from some status
> > website. What do you think this website might be? It will not require
> > anybody to look at it, but provide the information to interested people.
>  [0] says "write a regex", "opt-out" would mean forced interaction
> with  
>  your website, "opt-in" would mean "registration".
>
>  All in all, I read this as "bureaucracy". 
Up until now I felt like I undertood you, because as I understand you
here, you are agains anything being opt-out, even if the majority of
package maintainers would use the service?

Regards
Till

[Jesse Keating]

On Fri, 2009-08-07 at 14:25 +0200, Till Maas wrote:
>  >> I don't get how you might even expect more bureaucracy
> from some status
>  >> website. What do you think this website might be? It will not require
>  >> anybody to look at it, but provide the information to interested people.
>  > [0] says "write a regex", "opt-out" would mean forced
> interaction with  
>  > your website, "opt-in" would mean "registration".
>  >
>  > All in all, I read this as "bureaucracy".
>  
>  Up until now I felt like I undertood you, because as I understand you
>  here, you are agains anything being opt-out, even if the majority of
>  package maintainers would use the service? 
Just simple misunderstanding.

Ralf, this entire service is informational only.  Maintainers don't need
to do anything with this information, particularly if it isn't being
filed as bugs and only provided on a webpage.  They can simply ignore
the information or even pretend that the website doesn't exist.  The
"opt-out" that Till is talking about is that by default, his service
would manage every package it is capable of.  A maintainer would have to
opt-out of having their package monitored.  But again, even if the
package /is/ monitored, they don't have to do anything with that
information.

There is no bureaucracy here, just potentially useful information a
maintainer can choose to look at or not.

-- 
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating

[Bill Nottingham]

Jesse Keating (jkeating(a)redhat.com) said: 
>  Ralf, this entire service is informational only.  Maintainers
> don't need
>  to do anything with this information, particularly if it isn't being
>  filed as bugs and only provided on a webpage.  They can simply ignore
>  the information or even pretend that the website doesn't exist.  The
>  "opt-out" that Till is talking about is that by default, his service
>  would manage every package it is capable of.  A maintainer would have to
>  opt-out of having their package monitored.  But again, even if the
>  package /is/ monitored, they don't have to do anything with that
>  information.
>  
>  There is no bureaucracy here, just potentially useful information a
>  maintainer can choose to look at or not. 
My concerns are twofold:

- BZ seems the wrong place. It's the only push mechanism we have other
  than raw e-mail, though.
- Not to generalize too much, but we have maintainers:

  - who maintain only a few packages
  Likely, these people are already plugged into their upstreams and don't
  need the extra notification.

  - who maintain a lot of packages (woo, 100 perl modules)
  These people are more likely to need it.

  Which of these groups do we want to optimize for by default?

Bill

[Till Maas]

On Fri, Aug 07, 2009 at 10:56:10AM -0400, Bill Nottingham wrote:

>  - BZ seems the wrong place. It's the only push mechanism we have
> other
>    than raw e-mail, though. 
Pushing messages to maintainers is not the only necessary feature. The
maintainers also need to be able to easily coordinate who will work on
this or comment why this update won't take place or is delayed, e.g.
because of bugs in other packages or missing dependencies.

>  - Not to generalize too much, but we have maintainers:
>  
>    - who maintain only a few packages
>    Likely, these people are already plugged into their upstreams and don't
>    need the extra notification. 
Or they are not that well organised, that they may not notice upstream
features. If the request was not declined, I was about to gather some
statistics for the currently monitored packages, but this is moot now.

>    - who maintain a lot of packages (woo, 100 perl modules)
>    These people are more likely to need it. 
Or they have already their procedures to do this. Who knows?
Nevertheless, both do not provide a public interace that can be consumed
by other people than the package maintainers.

Regards
Till

[Ralf Corsepius]

On 08/07/2009 04:56 PM, Bill Nottingham wrote:
>  Jesse Keating (jkeating(a)redhat.com) said:
> > Ralf, this entire service is informational only.  Maintainers don't need
> > to do anything with this information, particularly if it isn't being
> > filed as bugs and only provided on a webpage.  They can simply ignore
> > the information or even pretend that the website doesn't exist.  The
> > "opt-out" that Till is talking about is that by default, his service
> > would manage every package it is capable of.  A maintainer would have to
> > opt-out of having their package monitored.  But again, even if the
> > package /is/ monitored, they don't have to do anything with that
> > information.
> >
> > There is no bureaucracy here, just potentially useful information a
> > maintainer can choose to look at or not. 
Well, I doubt this.

My concerns are about
* getting flooded and swamped with false "update alerts" and the 
administrational overhead related to "fix them".

* the technology being applied. I am having doubts Till's approach 
(regex's) is sufficient.

* I am also "burnt" by negative experiences when other comparable 
systems had been introduced to Fedora, such as bodhi, koji and the 
packagedb - They all cause additional overhead and so far all have seen 
close to zero effort to improve the situation.

Conversely, the situation is gradually worsening.

>  My concerns are twofold:
>
>  - BZ seems the wrong place. It's the only push mechanism we have other
>     than raw e-mail, though.
>  - Not to generalize too much, but we have maintainers:
>
>     - who maintain only a few packages
>     Likely, these people are already plugged into their upstreams and don't
>     need the extra notification. 
ACK, for these folks such Till's service is not of much use.

>     - who maintain a lot of packages (woo, 100 perl modules)
>     These people are more likely to need it. 
Being one of these, I can't avoid
telling you Till's service also
is not of much use, because esp. Perl has other communication channels 
to notify people about updates (CPAN) -- Otherwise it would not have 
been possible to maintain them.

That said, Till's system has few benefits - It's essentially "just yet 
another" system.

>     Which of these groups do we want to optimize for by default?
IMO, Till's service is suitable for "occasional packagers" who package

few "non-essential/minor" packages with infrequent releases (Packages 
with "zero traffic" mailing lists; packages, maintainers forget about to 
check for updates).

However, it's exactly this family of packages, who suffer from the 
technical issues Till's system is likely not able to cope with.


Ralf

[Rahul Sundaram]

On 08/07/2009 01:03 AM, Till Maas wrote:

>  
>  Would it be ok, to do this and allow maintainers to add there package to
>  a black list, so that no bugs will be filed or should it continue to be
>  opt-in? Then the packags will still be checked, but only reported by
>  other, non intrusive ways, e.g. via a website. 
I would prefer the system to be opt-out. For completely new maintainers
or anyone maintaining more than a few packages, it certainly is very
useful to get notification via bugzilla about new upstream releases.

I would also like to have a webpage where I can go to check the Fedora
vs upstream release status across all maintained branches including
Rawhide. So the information needs to be gathered for all upstream releases.

There are some cases where the website moves or fall off the face of the
earth or where upstream is completely confused about proper versioning
but that is the exception and not the norm. Can be dealt with on a case
by case basis.

Rahul

[Jef Spaleta]

On Thu, Aug 6, 2009 at 10:11 PM, Rahul
Sundaram<sundaram(a)fedoraproject.org> wrote:
>  I would prefer the system to be opt-out. For completely new maintainers
>  or anyone maintaining more than a few packages, it certainly is very
>  useful to get notification via bugzilla about new upstream releases. 
Err, uhm...I'd rather not see bugzilla overloaded with this sort of
notification. But I would LOVE to see this integrated as notification
information into the Fedora Community portal concept.

I know a lot of us rely on bugzilla as the mainstay to a lot of our
workflow...everything is a nail when all you have is a hammer.
Everything is a bug when all you have is a bug tracker...But I think
the maintainer portal concept introduced with the debut of Community
is something we should start driving enhanced functionality at.

-jef

[Rahul Sundaram]

On 08/07/2009 11:51 AM, Jeff Spaleta wrote:
>  On Thu, Aug 6, 2009 at 10:11 PM, Rahul
>  Sundaram<sundaram(a)fedoraproject.org> wrote:
> >
> > I would prefer the system to be opt-out. For completely new maintainers
> > or anyone maintaining more than a few packages, it certainly is very
> > useful to get notification via bugzilla about new upstream releases.
>  
>  Err, uhm...I'd rather not see bugzilla overloaded with this sort of
>  notification. But I would LOVE to see this integrated as notification
>  information into the Fedora Community portal concept.
>  
>  I know a lot of us rely on bugzilla as the mainstay to a lot of our
>  workflow...everything is a nail when all you have is a hammer.
>  Everything is a bug when all you have is a bug tracker...But I think
>  the maintainer portal concept introduced with the debut of Community
>  is something we should start driving enhanced functionality at. 
If you make maintainers go to a portal, you have lost. Bugzilla gets you
email notifications and that is what I need. If a portal sends me that
notification, that's fine. I don't care where it comes from.

Rahul

[Till Maas]

On Thu, Aug 06, 2009 at 10:21:20PM -0800, Jeff Spaleta wrote:
>  On Thu, Aug 6, 2009 at 10:11 PM, Rahul
>  Sundaram<sundaram(a)fedoraproject.org> wrote:
>  >
>  > I would prefer the system to be opt-out. For completely new maintainers
>  > or anyone maintaining more than a few packages, it certainly is very
>  > useful to get notification via bugzilla about new upstream releases.
>  
>  Err, uhm...I'd rather not see bugzilla overloaded with this sort of
>  notification. But I would LOVE to see this integrated as notification
>  information into the Fedora Community portal concept. 
Fedora Community portal integration would be a good thing, but bugs may
still be needed, e.g. if a package update depends on something else:
Recently there was some latex breakage iirc that prevented a an update
of some package to happen. Nowadays this is solved with blocking on the
other bug report. For this to work with the portal, it probably also
needs advanced bugzilla skills and it would be nice to have portal
support in bugzilla.

Is there something like python-fedora to create notifications within the
portal?

Regards
Till

[Jesse Keating]

On Fri, 2009-08-07 at 11:29 +0200, Till Maas wrote:
>  
>  Is there something like python-fedora to create notifications within the
>  portal? 
I don't have an answer to the above question, but I do have an answer
about the future.

The eventual goal is to use a AMQP message bus to pass this kind of
information around.  We'd be able to run your service in the
infrastructure, and it would just announce on the bus what info it
finds.  Consumers of the bus would do various things like A) file bugs
in bugzilla, B) update information in fedora-hosted, C) whatever else
somebody comes up with.

-- 
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating

[Till Maas]

On Thu, Aug 06, 2009 at 09:33:06PM +0200, Till Maas wrote:

>  Would it be ok, to do this and allow maintainers to add there package
> to
>  a black list, so that no bugs will be filed or should it continue to be
>  opt-in? Then the packags will still be checked, but only reported by
>  other, non intrusive ways, e.g. via a website. 
It was decided on todays FeSCO meeting, that the service will stay to be
opt-in. The full discussion is available at:
http://meetbot.fedoraproject.org/fedora-meeting/2009-08-07/fedora-meeting...

Eventually, it will become possible to opt-in as a packager and not only
with some package. Then for every package that the service can monitor,
you will receive notifications.

Regards
Till