Re: [MirageOS-devel] Updating TROVE or maintaining a remote

[Thomas Leonard <talex5@xxxxxxxxx>]

On 10 August 2015 at 10:29, Thomas Gazagnaire <thomas@xxxxxxxxxxxxxx> wrote:
> Hey,
>
>> - an OPAM remote that we maintain with all the unreleased packages (like the 
>> ongoing ones for networking by Mindy, Jitsu by Magnus, autoscaling by 
>> Mort/Masoud and so on).  This would only be used for metadata purposes.
>
> Well, we already have that one: that's https://github.com/mirage/mirage-dev
>
> unfortunately it mixes new mirage packages (currently jitsu, mirage-nat) and 
> third-party patched libraries (currently, dolog, type-conv and zlib). So we 
> need to use the tags here as well. It is also missing few other libs, so 
> people should add their projects in there.
>
> I'm still unclear if we want to use branches here or not to stage releases...
>>
>> - Build a dashboard view of issues, commits and so on from the aggregation 
>> of this. Christophe is currently working on this, and I'm keen to add issue 
>> tracking to make releases and standardised labelling of issues in GitHub 
>> easier.  Once David Sheets finishes up the next iteration of Codoc, we can 
>> also generate cross-referenced documentation.
>
> yes we definitely need an high-level views on top of our repositories. Random 
> list of needed features:
>
> - the main one is (as already mentioned) the ability to see lagged release 
> (ie. repo with commits but without a release). And maybe a one-click release 
> button using scripts my hackish opam-release[4].
> - highlight high-level/multi-repo tracking issues (such as error handling[1], 
> irmin/mirage integration[2], API updates[3]).
> - lint release: check that all tags on a repo have a non-empty GitHb release, 
> check that there's a CHANGES{.md} file, check that we have some tests.

Can we provide the "changes" information automatically somehow? It
seems that it just duplicates the release notes and/or the Git
history, and causes unnecessary merge conflicts.

e.g. if you go to
https://github.com/talex5/mirage-trace-viewer/releases you'll see a
list of changes for each release, but I don't maintain a separate
changes file and I don't feel I'm losing anything by doing this.

> - ideally, we should start to have "gatekeepers" for all of our projects. If 
> you are a gatekeeper, having a view for all issues/PR for these projects 
> would be useful.
>
> Thomas
>
> [1]:  https://github.com/mirage/mirage/issues/381
> [2]: https://github.com/mirage/irmin/issues/107
> [3]: https://github.com/mirage/mirage/issues/203
> [4]: https://github.com/samoht/opam-release
>
>
>>
>> Any thoughts on this?  Christophe is working on this infrastructure right 
>> now, and we're keen to get something up and running in August.  I'm 
>> particularly interested in missing workflow features that would make your 
>> life easier as MirageOS developers and users.
>>
>> [1] https://github.com/ocaml/opam-repository/pull/4625
>> [2] https://github.com/mirage/mirage-www/blob/master/TROVE
>>
>> thanks
>> Anil
>> _______________________________________________
>> MirageOS-devel mailing list
>> MirageOS-devel@xxxxxxxxxxxxxxxxxxxx
>> http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel
>
>
> _______________________________________________
> MirageOS-devel mailing list
> MirageOS-devel@xxxxxxxxxxxxxxxxxxxx
> http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel



-- 
Dr Thomas Leonard        http://roscidus.com/blog/
GPG: DA98 25AE CAD0 8975 7CDA  BD8E 0713 3F96 CA74 D8BA

_______________________________________________
MirageOS-devel mailing list
MirageOS-devel@xxxxxxxxxxxxxxxxxxxx
http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel