| 65 | | === History === |
| | 64 | == Building == |
| | 65 | |
| | 66 | Building the source is currently rather a pain, |
| | 67 | which is something to improve urgently. With appropriate development |
| | 68 | packages installed—they need documenting—it should build on GNU/Linux |
| | 69 | with something like |
| | 70 | {{{ |
| | 71 | cd source |
| | 72 | ./aimk -only-depend && scripts/zerodepend && ./aimk depend && |
| | 73 | ./aimk -system-libs -no-gui-inst |
| | 74 | }}} |
| | 75 | |
| | 76 | == Bug reporting, patches, and mail lists == |
| | 77 | |
| | 78 | There aren't currently any accessible mail lists associated with the |
| | 79 | project, but should be soon, and unfortunately you can't currently reply to |
| | 80 | any mail from the tracker, such as notifications of tickets. You can create an account |
| | 81 | to put tickets in the [ticket: issue tracker], or use the `tourist` |
| | 82 | account with `sge` as the password. If you do use tourist, it may be useful |
| | 83 | to put a mail address in the report in case of queries. (It will eventually be |
| | 84 | possible to make bug reports by mail.) |
| | 85 | |
| | 86 | The best way to send patches is to record them in your local darcs |
| | 87 | repository and use `darcs send`. Until arrangements are made for |
| | 88 | direct contributions, they will be pushed into the main repository by |
| | 89 | hand if they look reasonable. You could also just mail (see |
| | 90 | [#contact Contact]) normal patches, maybe even against the 6.2u5 |
| | 91 | source, if you have any already, or attach them to a ticket. |
| | 92 | |
| | 93 | If you record changes with darcs, make the patch name a useful short |
| | 94 | summary of the patch, and include the number of any ticket it fixes in |
| | 95 | the form {{{fix #}}}//N//, where //N// is the ticket number. If it |
| | 96 | also refers to an item //N// in the sunsource Issuezilla system, it's |
| | 97 | useful to include that also in the form IZ//N// even though the |
| | 98 | imported tickets have that reference. |
| | 99 | |
| | 100 | == History == |
| 95 | | |
| 96 | | == Building == |
| 97 | | |
| 98 | | Building the source is currently a pain, |
| 99 | | which is something to improve urgently. With appropriate development |
| 100 | | packages installed—they need documenting—it should build on GNU/Linux |
| 101 | | with something like |
| 102 | | {{{ |
| 103 | | cd source |
| 104 | | ./aimk -only-depend && scripts/zerodepend && ./aimk depend && |
| 105 | | ./aimk -system-libs -no-gui-inst |
| 106 | | }}} |
| 107 | | |
| 108 | | == Bug reporting, patches, and mail lists == |
| 109 | | |
| 110 | | There aren't currently any accessible mail lists associated with the |
| 111 | | project, but should be soon. Note that you can't currently reply to |
| 112 | | any mail, such as notifications of tickets. You can create an account |
| 113 | | to put tickets in the [ticket: issue tracker], or use the `tourist` |
| 114 | | account with `sge` as the password. (It will eventually be possible |
| 115 | | to make bug reports by mail.) |
| 116 | | |
| 117 | | The best way to send patches is to record them in your local darcs |
| 118 | | repository and use `darcs send`. Until arrangements can be made for |
| 119 | | direct contributions, they will be pushed into the main repository by |
| 120 | | hand if they look reasonable. You could also just mail (see |
| 121 | | [#contact Contact]) normal patches, maybe even against the 6.2u5 |
| 122 | | source, if you have any already, or attach them to a ticket. |
| 123 | | |
| 124 | | If you record changes with darcs, make the patch name a useful short |
| 125 | | summary of the patch, and include the number of any ticket it fixes in |
| 126 | | the form {{{fix #}}}//N//, where //N// is the ticket number. If it |
| 127 | | also refers to an item //N// in the sunsource Issuezilla system, it's |
| 128 | | useful to include that also in the form IZ//N// even though the |
| 129 | | imported tickets have that reference. |
| 130 | | |
| 131 | | When reviewing tickets imported from Issuezilla, note that any |
| 132 | | hyperlinks appearing in the main description are bogus unless they are |
| 133 | | normal URLs, and some of the tickets have the summary messed up due to |
| 134 | | the way they were imported, which is probably not worth fixing now. |
