community-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Franco Perruna <francoperrun...@gmail.com>
Subject Re: Can't reporter.a.o automatically detect version number and release datenschutzrechtlichen?
Date Fri, 26 Jun 2015 17:32:59 GMT
Am 26.06.2015 19:30 schrieb "Franco Perruna" <francoperruna83@gmail.com>:
>
> Am 26.06.2015 19:01 schrieb "Franco Perruna" <francoperruna83@gmail.com>:
>>
>> Francoperruna83
>>
>> Am 26.06.2015 18:52 schrieb "sebb" <sebbaz@gmail.com>:
>>>
>>> Or just include the URL that triggered the e-mail?
>>> Surely that would give sufficient clue to the project?
>>>
>>> By the way, I received e-mails from the reporter service when I
>>> *deleted* some old release files.
>>>
>>> Surely such mails could/should be suppressed?
>>>
>>> On 26 June 2015 at 09:04, Branko Čibej <brane@apache.org> wrote:
>>> > On 25.06.2015 17:40, Martijn Dashorst wrote:
>>> >> And there is no rule (yet) that there is only one format to rule them
>>> >> all. A transformation rule specified at project level in the reporter
>>> >> tool could do the trick as well.
>>> >
>>> >
>>> > Yah ... have each project define a (set of) regular expressions and
use
>>> > the contents of \1.
>>> >
>>> >
>>> > -- Brane
>>> >
>>> >
>>> >>
>>> >> On Thu, Jun 25, 2015 at 5:17 PM, Niclas Hedhman <niclas@hedhman.org>
wrote:
>>> >>> Alex,
>>> >>> I think you made an assumption that "format" meant naming schemes
of
>>> >>> releases, but it didn't. Simple "a defined way" to make that
available for
>>> >>> reporter to pick it up with relative ease.
>>> >>> Your suggestion of a doap-based solution is equally a "format".
The
>>> >>> important part, I think, is that "whatever way is chosen", that
it
is
>>> >>> documented and notified to PMCs, with optionality to use it.
>>> >>>
>>> >>> For me; DOAP is as good as anything, although there are probably
a
great
>>> >>> demand for linking that with Maven publishing "somehow". Since our
Gradle
>>> >>> build is generating all kinds of meta data output anyway, one more
wouldn't
>>> >>> hurt much.
>>> >>>
>>> >>> Cheers
>>> >>>
>>> >>> On Thu, Jun 25, 2015 at 10:31 PM, Alex Harui <aharui@adobe.com>
wrote:
>>> >>>
>>> >>>>
>>> >>>> On 6/25/15, 7:18 AM, "hedhman@gmail.com on behalf of Niclas
Hedhman"
>>> >>>> <hedhman@gmail.com on behalf of niclas@hedhman.org> wrote:
>>> >>>>
>>> >>>>> If the "format" is published, and the "reward" of following
it
would be
>>> >>>>> that the reporter picks it up automatically, it could lead
to
swift
>>> >>>>> adoption ;-)
>>> >>>> You might get push back about having to change naming schemes.
>>> >>>>
>>> >>>> I’m interested in a list of all current and past releases
for my
project.
>>> >>>> I was trying to figure out how to mine archive.a.o or the svn
log
for it.
>>> >>>> I’d be willing to maintain an xml file like in DOAP or elsewhere
of not
>>> >>>> just the last, but all releases and links to their downloads
with
>>> >>>> “friendly” names for the releases.  Then reporter.a.o could
grab
from that.
>>> >>>>
>>> >>>> -Alex
>>> >>>>
>>> >>>>> On Thu, Jun 25, 2015 at 9:26 PM, Daniel Gruno <
humbedooh@apache.org>
>>> >>>>> wrote:
>>> >>>>>
>>> >>>>>> It has been tried, and it did not work.
>>> >>>>>> People are too inconsistent across projects in how they
name
their
>>> >>>>>> release
>>> >>>>>> files, grabbing the version is nigh impossible.
>>> >>>>>> If we had some form of agreement on how to name files,
then it
would be
>>> >>>>>> possible.
>>> >>>>>>
>>> >>>>>> With regards,
>>> >>>>>> Daniel.
>>> >>>>>>
>>> >>>>>>
>>> >>>>>> On 2015-06-25 15:11, Martijn Dashorst wrote:
>>> >>>>>>
>>> >>>>>>> Is there a reason why the reporter.a.o can send
a message to a
release
>>> >>>>>>> manager that it detected a new release, but is incapable
of
>>> >>>>>>> determining a version number and release date?
>>> >>>>>>>
>>> >>>>>>> Martijn
>>> >>>>>>>
>>> >>>>>>
>>> >>>>>
>>> >>>>> --
>>> >>>>> Niclas Hedhman, Software Developer
>>> >>>>> http://zest.apache.org - New Energy for Java
>>> >>>>
>>> >>>
>>> >>> --
>>> >>> Niclas Hedhman, Software Developer
>>> >>> http://zest.apache.org - New Energy for Java
>>> >>
>>> >>
>>> >

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message