| 1 |
On 25/02/16 08:59, Kent Fredric wrote: |
| 2 |
> On 25 February 2016 at 21:02, Consus <consus@×××.com> wrote: |
| 3 |
>> Well, we do have one |
| 4 |
>> |
| 5 |
>> https://gitweb.gentoo.org/repo/gentoo.git/log/dev-lang/perl |
| 6 |
>> |
| 7 |
>> I bet folks want to check out what's new in their local copy of |
| 8 |
>> Portage tree. |
| 9 |
> |
| 10 |
> |
| 11 |
> With a custom, portage oriented, on-demand log generator you could |
| 12 |
> produce a lot more detail ( and in a text format that doesn't |
| 13 |
> require a web browser to view ) , and potentially use |
| 14 |
> understanding of portage conventions to generate change data |
| 15 |
> outside those explicitly stated. |
| 16 |
> |
| 17 |
> Though that would be a "later feature" you could potentially bolt |
| 18 |
> on after the main logic was sorted out. |
| 19 |
> |
| 20 |
> The idea being you could request a changelog for a package with a |
| 21 |
> list of "interest aspects" and have the log reduced to changes |
| 22 |
> that affect those interests. |
| 23 |
> |
| 24 |
> For instance, you could do : |
| 25 |
> |
| 26 |
> curl http://thing.gentoo.org/changes/dev-lang/perl?arch=~x86 |
| 27 |
> |
| 28 |
> And with a bit of effort, you could generate a changelog that is |
| 29 |
> only relevant for somebody who is on ~x86, eliding changes that |
| 30 |
> x86 didn't get yet. |
| 31 |
> |
| 32 |
> For instance, an ~x86 filter would elide stabilizations for ~x86, |
| 33 |
> because you don't care about stabilizations if you're assuming |
| 34 |
> ~arch. ( And it would elide changes that were only visible for |
| 35 |
> other arches ) |
| 36 |
> |
| 37 |
> And this filter wouldn't necessarily be implemented in "grep for |
| 38 |
> keywords in the commit message", but *analyse the change in the |
| 39 |
> directory* based, which would give the ability to do things that |
| 40 |
> would otherwise only be possible with a git clone. |
| 41 |
> |
| 42 |
> |
| 43 |
> |
| 44 |
This idea is quite neat - you could do either some basic User-Agent |
| 45 |
check and either render a web page for viewing online for changes, or |
| 46 |
even have a specifier that gave you some other output options .. eg. |
| 47 |
ChangeLog (rev. chron) or basic web or XML or JSON which you could |
| 48 |
then post-process if you desired. |
| 49 |
|
| 50 |
I know this is kind of bloating the idea, but the flexibility and such |
| 51 |
would make it Really Useful .. I think, anyhow ... |
| 52 |
|
| 53 |
MJE |
Archives